Files

Alex Crichton b73b831892 Replace binaryen -ttf based fuzzing with wasm-smith (#2336 )

This commit removes the binaryen support for fuzzing from wasmtime,
instead switching over to `wasm-smith`. In general it's great to have
what fuzzing we can, but our binaryen support suffers from a few issues:

* The Rust crate, binaryen-sys, seems largely unmaintained at this
  point. While we could likely take ownership and/or send PRs to update
  the crate it seems like the maintenance is largely on us at this point.

* Currently the binaryen-sys crate doesn't support fuzzing anything
  beyond MVP wasm, but we're interested at least in features like bulk
  memory and reference types. Additionally we'll also be interested in
  features like module-linking. New features would require either
  implementation work in binaryen or the binaryen-sys crate to support.

* We have 4-5 fuzz-bugs right now related to timeouts simply in
  generating a module for wasmtime to fuzz. One investigation along
  these lines in the past revealed a bug in binaryen itself, and in any
  case these bugs would otherwise need to get investigated, reported,
  and possibly fixed ourselves in upstream binaryen.

Overall I'm not sure at this point if maintaining binaryen fuzzing is
worth it with the advent of `wasm-smith` which has similar goals for
wasm module generation, but is much more readily maintainable on our
end.

Additonally in this commit I've added a fuzzer for wasm-smith's
`SwarmConfig`-based fuzzer which should expand the coverage of tested
modules.

Closes #2163

2020-10-29 10:02:59 -05:00

src

Replace binaryen -ttf based fuzzing with wasm-smith (#2336 )

2020-10-29 10:02:59 -05:00

build.rs

Make spectest fuzzing more deterministic

2020-08-06 08:08:20 -07:00

Cargo.toml

Replace binaryen -ttf based fuzzing with wasm-smith (#2336 )

2020-10-29 10:02:59 -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.