Parallel fuzzing

[senier]

Utilize multiple CPU cores for fuzzing.

Parallel fuzzing requires refactoring of coverage collection. Right now, coverage is collected in the child process and the new coverage is sent over a pipe shared between parent and child. The parent then compares the new coverage with the coverage previously stored (by the parent) and in case it increased, stores the binary returned by the child process.

The current approach has a number of limitations:

• Coverage is recorded in the child process only. In case of multiple child processes, a sample may be considered to lead to new paths, while it just lead to a new path in a specific child process.
• Binaries are needlessly sent back from child to parent, while the parent needs to keep the sample anyways to handle cases where the child process hangs or times out
• The information returned is either a number (the current coverage) or the text of an exception. Ideally, the format should be more structured (e.g. a JSON document).

Design:

Child processes

The tracer is changed such that it can be reset.

• Read the next job from the job queue
• Reset the tracer
• Put a status message into the result queue before execution the target
• Run the target
• If the target ran successfully, put report message into result queue
• If the target crashed, put an error reported into the result queue

Status report

class Status:
    worker: int
    job: int

Coverage report

class Report:
    worker: int
    job: int
    covered: list[tuple[str, str, int]]

Error report

class Error:
    worker: int
    job: int
    message: str

Parent process

• The parent spawns and starts a configurable number of child processes and passes their worker ID, a command queue and a result queue
• An object for each child process contains:
  • child process
• In a loop, the parent
  • generates a new binary and associate it with a unique job ID
  • puts it into the job database under that id with status submitted and no worker id
  • submit it to the shared job queue
  • checks for response in the response queue
    • if response is an error: retrieve binary with corresponding job ID and store it into crash folder
    • if response is a status: update job with worker and timestamp in database
    • if response is a report: if provided coverage information increases total coverage store binary in samples
    • delete job from database
  • Check time stamps in job database
    • if timestamp of a submitted job is older than timeout, kill and restart the corresponding worker

Job

class Job:
   id: int
   data: bytes