syz-fuzzer: fold fuzzer into manager process on host?

[dvyukov]

Currently we run syz-fuzzer process inside of the target VM. The original motivation for this was performance and scalability: generation/mutation of programs happens locally and is distributed (manager is not a bottleneck).

This issue is to consider changing the current scheme to the following:

• fuzzer is folded into manager and runs on the host
• the only binary that runs on target is executor

This has a number of advantages:

• We won't require target Go toolchain (Akaros and Fuchsia don't have them and use HostFuzzer mode, which is a hacky approximation of this proposal)
• This will reduce resource consumption in the VM, fuzzer is a beefy Go process that holds whole corpus. Consequently currently we have N copies of the corpus, in the new scheme we will have just one copy on host.
• Presumably it will simplify lots of things: multiple fuzzers won't need to exchange inputs, etc. Manager will be in total control of the corpus.
• This may increase fuzzing efficiency because manager will be able to do more optimal global decisions.

We may also consider how/if we can support VMM/user-space library testing in this mode. For these things there is even no "target machine", so it's reasonable to have corpus on host in 1 copy.

The overall idea is that executor will need a bit of fuzzer functionality: mandate fork server, probably do first step of coverage processing for performance (otherwise we would always need to send all coverage back to host for each program). Manager will send serialized programs to executors, receive results back and do the rest of processing.

The main question is performance of this scheme. It's just different, hard to say if it will be worse, or maybe significantly better. Currently we send each program before execution to manager in text form (in the log); in the new scheme we will need to send each program in binary form to the machine (back we don't need to log it back b/c manager will already know what programs VM is running). We could use some buffering: send up to N programs to executor and then wait for results. Program triage may get slower because we will need to do lots of round-trips and send coverage back most of the time.

We will also need to re-implement all of pkg/host in executor in C. But as a good side-effect it will fix pkg/host for akaros/fuchsia and will also allow to properly account for sandboxing restrictions. E.g. "is a file accessible under a particular sandbox?", currently we can also guess or approximate. If we have this in executor, we just do the checks under the actual sandbox.

Another potential application is UEFI fuzzing (#3132).

Another potential use case that can be incorporated is support for deterministic VMs/emulators that fork for each test case.

[oswalpalash]

This is an interesting problem. This could likely eliminate the need of having an RPC server and the fuzzer could be a thread on the program. The bulkiness of VM images would go down, and it might have a positive effect on vm start up time.

[RaduNichita]

Hi.

Do you know how difficult would be to do this in the future? What would be the advantages and disadvantages of having this approach?

[dvyukov]

I would assume it will be quite difficult to this since, since it a major architecture redesign. The advantages and disadvantages listed in the issue descirption.

[RaduNichita]

What would be the estimated effort to decouple sys-fuzzer from syz-executor?

[dvyukov]

Hard to say w/o doing it :) Will also depend a lot on who will do it (syzkaller/Go knowledge) and also on exact scope (remove all Go code from target, only move corpus/fuzzing to host, keep/remove pkg/host, etc).

[a-nogikh]

For the record:

After https://github.com/google/syzkaller/pull/4579, the transition of the fuzzing engine to the host has been completed. Almost all of the aforementioned use cases should be unblocked now.

The only remaining limitation is that we still need to be able to run some Go code inside the fuzzed VM. For the fuzzing of non-typical syzkaller targets one now needs to write the code similar to syz-manager/rpc.go that would invoke fuzzer.NextInput() to get new inputs and report the results to fuzzer.Done() -- it's already a much much smaller amount of necesary changes.