InProcessForkExecutor

[andreafioraldi]

ATM these two Executors are missing:

• ForkserverExecutor must be an AFL-like forkserver executor, I guess we can borrow code from Angora
• InProcessForkExecutor is a version of InProcessExecutor that forks before calling the harness. In this case, LibAFL must be still embedded into the target and we avoid to control the target via pipe, but then we still need an harness and cannot fuzz binaries compile with afl-cc

[tokatoka]

Are we gonna go with injecting fork-server assembly code into instrumented PUT?
(https://github.com/google/AFL/blob/master/afl-as.h#L252)
, or do we prefer to use #[ctor] to spin up a forkserver before main() (it seems Angora is doing in this way).
The latter way seems much simpler, though.

[andreafioraldi]

For ForkserverExecutor this is an implementation detail of the instrumentation backend, has nothing to do with the lib.
For InProcessForkExecutor, it is simply an InProcessExecutor-like executor that instead of calling the harness function forks, call the harness in the child and waitpid in the parent

[andreafioraldi]

The immediate goal of ForkserverExecutor is btw to execute AFL++ binaries compiled with afl-clang-fast

[domenukk]

Basically this:
https://github.com/AFLplusplus/LibAFL-legacy/blob/53e339a38e27bcf5decf892928df459904442498/src/aflpp.c#L98

Or the "real" afl++ version, that also add sharedmem input, here:
https://github.com/AFLplusplus/AFLplusplus/blob/stable/src/afl-forkserver.c

(it doesn't have to fork itself but can use a rust std::process::Command to execute the target)

/edit:
The Angora forkserver is here (but won't work 1:1 as it uses Unix sockets instead of pipes):
https://github.com/AngoraFuzzer/Angora/blob/3cedcac8e65595cd2cdd950b60f654c93cf8cc2e/fuzzer/src/executor/forksrv.rs#L29

[tokatoka]

I've pushed a piece of very WIP code to the forkserver branch.
We'll also need to take care of the shared memory (and make a observer (ShmemObserver) to monitor the shared map), right?

[domenukk]

Yes, I assume we can use a normal map observer, with the map pointing to an ShMem.
Sharedmap input would eventually also be nice to have, as it's a lot quicker than (ab)using the file system

/edit: looking at your code, it might be a good idea to implement Drop for the Pipe struct so that they out close when going out of scope :)

[tokatoka]

I'll use the Pipe struct you've pushed to the launcher branch

[domenukk]

@tokatoka want to create a PR for the current state, so we can finish it up together?

[tokatoka]

Yes, I was kind of waiting for the launcher's Pipe class to be merged into the main branch.
The one last thing left to do for ForkserverExecutor is to check the execution result. (check if the fuzzed program has crashed or not)

[andreafioraldi]

Good job