7a9078d9cc
* cranelift: Change test runner order Changes the ordering of runtests to run per target and then per function. This change doesn't do a lot by itself, but helps future refactorings of runtests. * cranelift: Rename SingleFunctionCompiler to TestCaseCompiler * cranelift: Skip runtests per target instead of per run * cranelift: Deduplicate test names With the upcoming changes to the runtest infrastructure we require unique ExtNames for all tests. Note that for test names we have a 16 character limit on test names, and must be unique within those 16 characters. * cranelift: Add TestFileCompiler to runtests TestFileCompiler allows us to compile the entire file once, and then call the trampolines for each test. The previous code was compiling the function for each invocation of a test. * cranelift: Deduplicate ExtName for avg_round tests * cranelift: Rename functions as they are defined. The JIT internally only deals with User functions, and cannot link test name funcs. This also caches trampolines by signature. * cranelift: Preserve original name when reporting errors. * cranelift: Rename aarch64 test functions * cranelift: Add `call` and `call_indirect` tests! * cranelift: Add pauth runtests for aarch64 * cranelift: Rename duplicate s390x tests * cranelift: Delete `i128_bricmp_of` function from i128-bricmp It looks like we forgot to delete it when it was moved to `i128-bricmp-overflow`, and since it didn't have a run invocation it was never compiled. However, s390x does not support this, and panics when lowering. * cranelift: Add `colocated` call tests * cranelift: Rename *more* `s390x` tests * cranelift: Add pauth + sign_return_address call tests * cranelift: Undeduplicate test names With the latest main changes we now support *unlimited* length test names. This commit reverts: 52274676ff631c630f9879dd32e756566d3e700f 7989edc172493547cdf63e180bb58365e8a43a42 25c8a8395527d98976be6a34baa3b0b214776739 792e8cfa8f748077f9d80fe7ee5e958b7124e83b * cranelift: Add LibCall tests * cranelift: Revert more test names These weren't auto reverted by the previous revert. * cranelift: Disable libcall tests for aarch64 * cranelift: Runtest fibonacci tests * cranelift: Misc cleanup
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, evaluate each exported function with random inputs, and check that Wasmtime returns the same results as a choice of another engine: the Wasm spec interpreter (see thewasm-spec-interpretercrate), thewasmiinterpreter, V8 (through thev8crate), or Wasmtime itself run with a different configuration.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).