Files

Joel Dice ed8908efcf implement fuzzing for component types (#4537 )

This addresses #4307.

For the static API we generate 100 arbitrary test cases at build time, each of
which includes 0-5 parameter types, a result type, and a WAT fragment containing
an imported function and an exported function.  The exported function calls the
imported function, which is implemented by the host.  At runtime, the fuzz test
selects a test case at random and feeds it zero or more sets of arbitrary
parameters and results, checking that values which flow host-to-guest and
guest-to-host make the transition unchanged.

The fuzz test for the dynamic API follows a similar pattern, the only difference
being that test cases are generated at runtime.

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

2022-08-04 12:02:55 -05:00

src

implement fuzzing for component types (#4537 )

2022-08-04 12:02:55 -05:00

wasm-spec-interpreter

Add *.wast support for invoking components (#4526 )

2022-07-27 21:02:16 +00:00

build.rs

Actually make spectest fuzzing deterministic

2021-03-29 09:12:16 -07:00

Cargo.toml

implement fuzzing for component types (#4537 )

2022-08-04 12:02:55 -05:00

README.md

Create a new wasmtime-fuzzing crate

2019-11-21 14:51:07 -08:00

README.md

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.