5fa4d36b0d
* Add CLI flags for internal cranelift options This commit adds two flags to the `wasmtime` CLI: * `--enable-cranelift-debug-verifier` * `--enable-cranelift-nan-canonicalization` These previously weren't exposed from the command line but have been useful to me at least for reproducing slowdowns found during fuzzing on the CLI. * Disable Cranelift debug verifier when fuzzing This commit disables Cranelift's debug verifier for our fuzz targets. We've gotten a good number of timeouts on OSS-Fuzz and some I've recently had some discussion over at google/oss-fuzz#3944 about this issue and what we can do. The result of that discussion was that there are two primary ways we can speed up our fuzzers: * One is independent of Wasmtime, which is to tweak the flags used to compile code. The conclusion was that one flag was passed to LLVM which significantly increased runtime for very little benefit. This has now been disabled in rust-fuzz/cargo-fuzz#229. * The other way is to reduce the amount of debug checks we run while fuzzing wasmtime itself. To put this in perspective, a test case which took ~100ms to instantiate was taking 50 *seconds* to instantiate in the fuzz target. This 500x slowdown was caused by a ton of multiplicative factors, but two major contributors were NaN canonicalization and cranelift's debug verifier. I suspect the NaN canonicalization itself isn't too pricy but when paired with the debug verifier in float-heavy code it can create lots of IR to verify. This commit is specifically tackling this second point in an attempt to avoid slowing down our fuzzers too much. The intent here is that we'll disable the cranelift debug verifier for now but leave all other checks enabled. If the debug verifier gets a speed boost we can try re-enabling it, but otherwise it seems like for now it's otherwise not catching any bugs and creating lots of noise about timeouts that aren't relevant. It's not great that we have to turn off internal checks since that's what fuzzing is supposed to trigger, but given the timeout on OSS-Fuzz and the multiplicative effects of all the slowdowns we have when fuzzing, I'm not sure we can afford the massive slowdown of the debug verifier.
Fuzzing Infrastructure for Wasmtime
This crate provides test case generators and oracles for use with fuzzing.
These generators and oracles are generally independent of the fuzzing engine
that might be using them and driving the whole fuzzing process (e.g. libFuzzer
or AFL). As such, this crate does not contain any actual fuzz targets
itself. Those are generally just a couple lines of glue code that plug raw input
from (for example) libFuzzer into a generator, and then run one or more
oracles on the generated test case.
If you're looking for the actual fuzz target definitions we currently have, they
live in wasmtime/fuzz/fuzz_targets/* and are driven by cargo fuzz and
libFuzzer.