gardatech/bugbane

fuzz tool: better control over fuzz instances

Closed this issue · 1 comments

Currently we just create and run tmux commands and then wait for stop conditions to come until the end of time.
Fuzzers may stop working due to many reasons (poorly made fuzz target, no available cores to bind to, ...), they may also print some helpful error messages. Currently we don't care about these, which may result uneasy troubleshooting of multi-core fuzzing jobs.

From #4: we should only stop the child processes of fuzzer and tested binaries.

Fixed:

  1. Now we run our separate tmux server and store its pid. Later we only terminate this process.
  2. From the tmux server pid we enumerate its child processes in which we find our fuzz-starting cmds. We then monitor these child processes' existence and restart the corresponding cmds.
  3. In the end we find fuzz-starting cmds again and terminate the corresponding processes.

So now we don't kill system-wide tmux and afl-fuzz processes.

This mechanism isn't perfect and will surely mess up fuzz stats, but the whole need to restart fuzzers is not normal and means user has to troubleshoot issues with their builds, memory limitations, disk size etc.