Shared state in multi-process fuzzing

[momvart]

I'm relatively a beginner with fuzzing and LibAFL. To utilize the machine I want to perform multi-processed fuzzing using Launcher. I initially thought that the clients communicate with each other to share the state between themselves and try to avoid running the same input and grow the corpus together. However, it looks like that Launcher spawns multiple instances in parallel and they all start from scratch and work independently. This is based on my observation while fuzzing a target set up based on examples like libfuzzer_libpng_launcher.

I was wondering:

• Is it really how Launcher is intended to work or am I missing something?
• How do we achieve such fuzzing in LibAFL?
• What is the difference between Launcher and CenteralizedLauncher?

[domenukk]

Is it really how Launcher is intended to work or am I missing something?

Yes, this works as intended! Nodes do exchange Testcases between each other through lock-free message passing, however they otherwise work independently of each other and have their own internal state for optimal scaling.

Tightly coupling fuzzers using a shared state would have multiple downsides:

• Accessing the shared state is (relatively) very costly due to the synchronization overhead. Scaling to cores would suffer a lot.
• Nodes should run somewhat independently of each other in order to explore the target in different ways (it's all randomic, anyway)
• In any case we do not "block" inputs that have already been executed or try to create 100% unique inputs: the occasional (but rare) re-execution is, for most targets, still a lot faster than the additional overhead for such algorithms.

The only thing you can change is to use load_initial_inputs_multicore instead of load_initial_inputs - this will divide the initial corpus elements between the nodes evenly.

How do we achieve such fuzzing in LibAFL?

It's already optimal :)

What is the difference between Launcher and CenteralizedLauncher?

CenteralizedLauncher adds a node that filters Testcases (i.e., checks for global novelty) before forwarding them to other nodes. This means not all nodes will re-execute them, giving it a slight performance edge on systems with a lot of cores.

Hope this answers your questions, thanks for asking!

[momvart]

Thanks a lot for your complete answer.

The only thing you can change is to use load_initial_inputs_multicore instead of load_initial_inputs - this will divide the initial corpus elements between the nodes evenly.

Didn't know about its behavior!