Files

Andrew Brown c3f8415ac7 fuzz: improve the spec interpreter (#4881 )

* fuzz: improve the API of the `wasm-spec-interpreter` crate

This change addresses key parts of #4852 by improving the bindings to
the OCaml spec interpreter. The new API allows users to `instantiate` a
module, `interpret` named functions on that instance, and `export`
globals and memories from that instance. This currently leaves the
existing implementation ("instantiate and interpret the first function in
a module") present under a new name: `interpret_legacy`.

* fuzz: adapt the differential spec engine to the new API

This removes the legacy uses in the differential spec engine, replacing
them with the new `instantiate`-`interpret`-`export` API from the
`wasm-spec-interpreter` crate.

* fix: make instance access thread-safe

This changes the OCaml-side definition of the instance so that each
instance carries round a reference to a "global store" that's specific
to that instantiation. Because everything is updated by reference there
should be no visible behavioural change on the Rust side, apart from
everything suddenly being thread-safe (modulo the fact that access to
the OCaml runtime still needs to be locked). This fix will need to be
generalised slightly in future if we want to allow multiple modules to
be instantiated in the same store.

Co-authored-by: conrad-watt <cnrdwtt@gmail.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>

2022-09-12 14:23:03 -07:00

src

fuzz: improve the spec interpreter (#4881 )

2022-09-12 14:23:03 -07:00

wasm-spec-interpreter

fuzz: improve the spec interpreter (#4881 )

2022-09-12 14:23:03 -07:00

build.rs

Actually make spectest fuzzing deterministic

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

Cargo.toml

Upgrade wasm-tools crates, namely the component model (#4715 )

2022-08-17 16:17:34 +00: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.