Extending benchmarks to Rust targets
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 302
- PR merge metrics
- No merged PRs in 30d
Description
As discussed in FUZZING'23, we want to extend Fuzzbench to allow for Rust targets. Not all fuzzers will be compatible, but we would like to define a standard interface for those which are. We suggest the following and ask for input so that future fuzzers may also support Rust benchmarks.
### Rust harnesses
Most Rust fuzz harnesses built with cargo-fuzz should be straightforward to modify such that they emit `staticlib` build units instead of executable binaries. In recent versions of `libfuzzer-sys`, the common crate for providing libfuzzer bindings to cargo-fuzz targets, [you can choose to not link libfuzzer and instead only use the function names](https://github.com/rust-fuzz/libfuzzer/pull/106). This turns a Rust harness into a classical `LLVMFuzzerTestOneInput`-style harness. We propose to build Rust benchmarks in this way and link against the static libraries like existing benchmarks.
### Build flags and compilers
Rust fuzzers may use a specialised `rustc` [by exporting the `CARGO_BUILD_RUSTC` environmental variable](https://doc.rust-lang.org/cargo/reference/config.html#buildrustc). In addition, fuzzers using default `rustc` [may export specific build flags with the `RUSTFLAGS` environmental variable](https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags). The latter is [done by `cargo-fuzz`](https://github.com/rust-fuzz/cargo-fuzz/blob/main/src/project.rs#L166-L235).
### Detecting Rust compatibility
If a fuzzer does not set the `RUSTFLAGS` or `CARGO_BUILD_RUSTC` variable before performing the build, we should assume that it does not support Rust (no instrumentation passes would be executed). Alternatively, we should export a `fuzzer.compatible_languages()` function in each fuzzer, which may future-proof in the case of e.g. JavaScript/Java-specific fuzzers.
Contributor guide
Assessment
This issue has not been assessed yet.