AFLplusplus / AFLplusplus/LibAFL

make the fuzzer to have multiple executors

Open
#3,362 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Rust
Stars
2.6k
Forks
481
Avg merge
2d 30m
Merged PRs (30d)
16

Description

**Is your feature request related to a problem? Please describe.**
I'm currently fuzzing the Linux kernel in a Syzkaller-like setup, where an executor agent (similar to syz-executor) runs inside a QEMU VM. This agent executes seeds on behalf of the LibAFL executor and communicates with it via a TCP connection. In my design, the LibAFL executor is a lightweight wrapper around the QEMU VM harness, responsible for dispatching commands and seeds to the executor agent inside the VM.

**Describe the solution you'd like**
I would like LibAFL to support multiple executors within a single fuzzer instance. In this setup, the fuzzer could:

1. Assign seeds to idle executors within the same fuzzer instance.
2. Asynchronously monitor all executors for completed tasks.
3. Evaluate the execution results as they are returned.

This would allow me to run multiple executor agents inside a single VM, significantly reducing the memory usage of running multiple VMs while maintaining the ability to fuzz concurrently.

**Describe alternatives you've considered**
- **Multiple fuzzer instances**: I considered running multiple fuzzer instances, each with its own VM. However, this approach is inefficient in my use case due to the high memory overhead of running multiple VMs.
- **Custom executor management**: I could implement custom logic outside of LibAFL to manage multiple executor agents within a single VM. However, this would require significant effort and would duplicate functionality that could be integrated into LibAFL itself.

**Additional context**
In my use case, the host-side LibAFL executor is a lightweight wrapper of my custom harness that communicates with the VM-side executor agent via TCP to dispatch commands and seeds. Supporting multiple executors within a single fuzzer instance would allow me to leverage this design more effectively, enabling concurrent fuzzing without the need for multiple VMs.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.