57dca934ad
* Upgrade wasm-tools crates, namely the component model This commit pulls in the latest versions of all of the `wasm-tools` family of crates. There were two major changes that happened in `wasm-tools` in the meantime: * bytecodealliance/wasm-tools#697 - this commit introduced a new API for more efficiently reading binary operators from a wasm binary. The old `Operator`-based reading was left in place, however, and continues to be what Wasmtime uses. I hope to update Wasmtime in a future PR to use this new API, but for now the biggest change is... * bytecodealliance/wasm-tools#703 - this commit was a major update to the component model AST. This commit almost entirely deals with the fallout of this change. The changes made to the component model were: 1. The `unit` type no longer exists. This was generally a simple change where the `Unit` case in a few different locations were all removed. 2. The `expected` type was renamed to `result`. This similarly was relatively lightweight and mostly just a renaming on the surface. I took this opportunity to rename `val::Result` to `val::ResultVal` and `types::Result` to `types::ResultType` to avoid clashing with the standard library types. The `Option`-based types were handled with this as well. 3. The payload type of `variant` and `result` types are now optional. This affected many locations that calculate flat type representations, ABI information, etc. The `#[derive(ComponentType)]` macro now specifically handles Rust-defined `enum` types which have no payload to the equivalent in the component model. 4. Functions can now return multiple parameters. This changed the signature of invoking component functions because the return value is now bound by `ComponentNamedList` (renamed from `ComponentParams`). This had a large effect in the tests, fuzz test case generation, etc. 5. Function types with 2-or-more parameters/results must uniquely name all parameters/results. This mostly affected the text format used throughout the tests. I haven't added specifically new tests for multi-return but I changed a number of tests to use it. Additionally I've updated the fuzzers to all exercise multi-return as well so I think we should get some good coverage with that. * Update version numbers * Use crates.io
cargo fuzz Targets for Wasmtime
This crate defines various libFuzzer
fuzzing targets for Wasmtime, which can be run via cargo fuzz.
These fuzz targets just glue together pre-defined test case generators with
oracles and pass libFuzzer-provided inputs to them. The test case generators and
oracles themselves are independent from the fuzzing engine that is driving the
fuzzing process and are defined in wasmtime/crates/fuzzing.
Example
To start fuzzing run the following command, where $MY_FUZZ_TARGET is one of
the available fuzz targets:
cargo fuzz run $MY_FUZZ_TARGET
Available Fuzz Targets
At the time of writing, we have the following fuzz targets:
api_calls: stress the Wasmtime API by executing sequences of API calls; only the subset of the API is currently supported.compile: Attempt to compile libFuzzer's raw input bytes with Wasmtime.compile-maybe-invalid: Attempt to compile a wasm-smith-generated Wasm module with code sequences that may be invalid.cranelift-fuzzgen: Generate a Cranelift function and check that it returns the same results when compiled to the host and when using the Cranelift interpreter; only a subset of Cranelift IR is currently supported.cranelift-icache: Generate a Cranelift function A, applies a small mutation to its source, yielding a function A', and checks that A compiled + incremental compilation generates the same machine code as if A' was compiled from scratch.differential: Generate a Wasm module and check that Wasmtime returns the same results when run with two different configurations.differential_spec: Generate a Wasm module and check that Wasmtime returns the same results as the Wasm spec interpreter (see thewasm-spec-interpretercrate).differential_v8: Generate a Wasm module and check that Wasmtime returns the same results as V8.differential_wasmi: Generate a Wasm module and check that Wasmtime returns the same results as thewasmiinterpreter.instantiate: Generate a Wasm module and Wasmtime configuration and attempt to compile and instantiate with them.instantiate-many: Generate many Wasm modules and attempt to compile and instantiate them concurrently.spectests: Pick a random spec test and run it with a generated configuration.table_ops: Generate a sequence ofexternreftable operations and run them in a GC environment.
The canonical list of fuzz targets is the .rs files in the fuzz_targets
directory:
ls wasmtime/fuzz/fuzz_targets/
Corpora
While you can start from scratch, libFuzzer will work better if it is given a corpus of seed inputs to kick start the fuzzing process. We maintain a corpus for each of these fuzz targets in a dedicated repo on github.
You can use our corpora by cloning it and placing it at wasmtime/fuzz/corpus:
git clone \
https://github.com/bytecodealliance/wasmtime-libfuzzer-corpus.git \
wasmtime/fuzz/corpus
Reproducing a Fuzz Bug
When investigating a fuzz bug (especially one found by OSS-Fuzz), use the following steps to reproduce it locally:
- Download the test case (either the "Minimized Testcase" or "Unminimized Testcase" from OSS-Fuzz will do).
- Run the test case in the correct fuzz target:
If all goes well, the bug should reproduce and libFuzzer will dump the failure stack trace to stdout
cargo +nightly fuzz run <target> <test case> - For more debugging information, run the command above with
RUST_LOG=debugto print the configuration and WebAssembly input used by the test case (see uses oflog_wasmin thewasmtime-fuzzingcrate).