Support non-persistent mode for AFL++ targets

[jonathanmetzman]

This will have numerous benefits, including:

1. Opening up OSS-Fuzz to projects that are too stateful or hard to harness to be used effectively with libFuzzer style fuzzing.
2. Allowing more thorough fuzzing by complementing libFuzzer style fuzzing. libFuzzer style fuzzing has gaps that can be filled by fuzzing the entire binary rather than a harness. An example of this was https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html where nss was in OSS-Fuzz but the target was not written in a way that the bug could be found, even though the bug could be found when fuzzing a binary directly.

To support this, we need to do the following:

• [ ] Support AFL++ on ClusterFuzz without libFuzzer. In particular, we need to do testcase and corpus merging with AFL when libFuzzer is absent.
• [ ] Teach OSS-Fuzz and ClusterFuzz to fuzz non-afl_driver binaries. Their commandline invocation will be different than afl_driver binaries, which accept the number of persistent executions as the only argument.
• [ ] Teach OSS-Fuzz and ClusterFuzz how to identify AFL target binaries that are not afl_driver based.
• [ ] (optional) Coverage reports for projects without libFuzzer. I think this probably complicates

Some thoughts on teaching ClusterFuzz to invoke non-afl_driver binaries properly: @AdamKorcz and @DavidKorczynski mentioned that we need to pass @@ instead of this number to the binary. But I actually think it will be more complicated than this. Some of the binaries we fuzz will not simply read from the file named by @@ (e.g. it may need to be invoked like this example --file @@, or read from stdin). We can handle this in two ways: 1. Force every binary to obey an API where they read from the file passed in the first argument. 2. Use .options files to allow users to specify how the binary should be invoked. I think 2 is the better option, it's much more user-friendly and will allow OSS-Fuzz to fuzz unmodified projects. It can also come in handy if users want to have "two" fuzz targets that are really the same binary but invoked in different ways.

Some thoughts on coverage reports. I think this will complicate our lives quite a bit and it should definitely wait until there is serious demand for it.

CC @vanhauser-thc

[vanhauser-thc]

either there is an options file on what options to pass to a non-persistent target, or the readelf variant with old_main is being used. I think an options file would be less overall work? but up to the person who wants to implement that IMHO :)

note that you can also use honggfuzz with non-persistent targets, afl++ is not the only option.

[DavidKorczynski]

note that you can also use honggfuzz with non-persistent targets, afl++ is not the only option.

I think we should go for this too then

[Phasip]

If you (like me) find this googling for afl, OSS-fuzz and persistence; a workaround is through the env AFL_FUZZER_LOOPCOUNT=1