Add --use-libafl toggle

[Carbocarde]

I recently came across this issue from 2023: #330

Is there any interest in making libafl the default fuzzer for cargo fuzz? From what I can tell it’s faster/better than libfuzzer and is still being actively developed.

cc @Manishearth @fitzgen @addisoncrump @domenukk @frewsxcv

Stacked on #425.

[addisoncrump]

Heyo, maintainer of libafl_libfuzzer here. I would say that it's still something that should be opt-in rather than default. As much as I would like to outright replace libfuzzer, there are several situations in which e.g. linkage gets complicated fast. Additionally, we are super fragile to even minor changes in Rust ABI or symbol naming.

Our solution works, but because we are written in Rust and require different sanitizer flags, it is rather unstable as we need to do quite a bit that assumes things about compiler output. If we had better support from Rust in these features, I'd feel more comfortable with trying to make a "stable" replacement.

[fitzgen]

Adding an option seems fine by me.

I would be wary of changing the default, at least initially, and without knowing more about the project. It is very important that binaries built with cargo fuzz Just Work with OSS-Fuzz, for example. Not saying that they won't after this change, just that I haven't spent the time to verify that, nor has anyone else, AFAICT. And @addisoncrump's comment reinforces the idea that this should remain an optional, disabled-by-default feature for the foreseeable moment in my mind.

That said, without having actually looked at the changes yet, I'd expect the changes to be limited to Cargo.toml dependencies and/or libfuzzer-sys features enabled in the fuzz target crate, rather than changes in cargo fuzz. For example, you can use https://github.com/rust-fuzz/libfuzzer#linking-to-a-local-libfuzzer to link to a local libafl++ instead of libfuzzer. So it seems like the necessary infrastructure to do this without any cargo fuzz changes already exists?

[fitzgen]

Ah this is just for the project initialization. Sure, seems fine by me.

[addisoncrump]

It is very important that binaries built with cargo fuzz Just Work with OSS-Fuzz, for example.

Yeah that's one of our long-term goals, but we want to make linkage nice and friendly first... we don't/can't test a lot of targets, yet. It could be nice to dogfood (well, kinda) fuzzing for Rust at some point.