github
/
cranelift
mirror of https://github.com/bytecodealliance/wasmtime.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
6791 Commits
49 Branches
140 Tags
128 MiB
Tree: 2c1d370465
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '2c1d370465'
${ noResults }
cranelift/fuzz/Cargo.toml

103 lines
2.1 KiB
Raw Normal View History

Start experimenting with cargo fuzz. This isn't very usable yet.
7 years ago
[package]
Make package names consistent with cranelift's.
6 years ago
name = "wasmtime-fuzz"
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
version = "0.0.0"
Update Cargo.toml authors fields.
6 years ago
authors = ["The Wasmtime Project Developers"]
Update to Rust 2018 Edition.
6 years ago
edition = "2018"
Start experimenting with cargo fuzz. This isn't very usable yet.
7 years ago
publish = false
[package.metadata]
cargo-fuzz = true
Make package names consistent with cranelift's.
6 years ago
[dependencies]
Merge cranelift/wasmtime fuzzing
5 years ago
cranelift-codegen = { path = "../cranelift/codegen" }
cranelift-reader = { path = "../cranelift/reader" }
cranelift-wasm = { path = "../cranelift/wasm" }
Update `arbitrary` and `libfuzzer` dependencies
5 years ago
libfuzzer-sys = "0.3.2"
Merge cranelift/wasmtime fuzzing
5 years ago
target-lexicon = "0.10"
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
peepmatic-fuzzing = { path = "../cranelift/peepmatic/crates/fuzzing", optional = true }
Move `crates/api` to `crates/wasmtime` (#1693) The `wasmtime` crate currently lives in `crates/api` for historical reasons, because we once called it `wasmtime-api` crate. This creates a stumbling block for new contributors. As discussed on Zulip, rename the directory to `crates/wasmtime`.
5 years ago
wasmtime = { path = "../crates/wasmtime" }
Merge cranelift/wasmtime fuzzing
5 years ago
wasmtime-fuzzing = { path = "../crates/fuzzing" }
Update to wasmparser 0.22.
6 years ago
Start experimenting with cargo fuzz. This isn't very usable yet.
7 years ago
[[bin]]
name = "compile"
path = "fuzz_targets/compile.rs"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
test = false
Tweak some API doc generation (#772) * Build docs with the nightly toolchain so [foo::bar] links work by default. This is a relatively new feature of rustdoc and I thought it was stabilized at this point but apparently it's not! * Tweak some API docs on `wasmtime::Strategy` * Use `--all` to build all local crate documentation instead of trying to list the number of local crates * Tweak some documentation configuration to avoid warnings generated by Cargo.
5 years ago
doc = false
Add fuzz targets for module instantiation.
6 years ago
[[bin]]
name = "instantiate"
path = "fuzz_targets/instantiate.rs"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
test = false
Tweak some API doc generation (#772) * Build docs with the nightly toolchain so [foo::bar] links work by default. This is a relatively new feature of rustdoc and I thought it was stabilized at this point but apparently it's not! * Tweak some API docs on `wasmtime::Strategy` * Use `--all` to build all local crate documentation instead of trying to list the number of local crates * Tweak some documentation configuration to avoid warnings generated by Cargo.
5 years ago
doc = false
Add fuzz targets for module instantiation.
6 years ago
[[bin]]
name = "instantiate_translated"
path = "fuzz_targets/instantiate_translated.rs"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
test = false
Tweak some API doc generation (#772) * Build docs with the nightly toolchain so [foo::bar] links work by default. This is a relatively new feature of rustdoc and I thought it was stabilized at this point but apparently it's not! * Tweak some API docs on `wasmtime::Strategy` * Use `--all` to build all local crate documentation instead of trying to list the number of local crates * Tweak some documentation configuration to avoid warnings generated by Cargo.
5 years ago
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["binaryen"]
fuzzing: Add initial API call fuzzer We only generate *valid* sequences of API calls. To do this, we keep track of what objects we've already created in earlier API calls via the `Scope` struct. To generate even-more-pathological sequences of API calls, we use [swarm testing]: > In swarm testing, the usual practice of potentially including all features > in every test case is abandoned. Rather, a large “swarm” of randomly > generated configurations, each of which omits some features, is used, with > configurations receiving equal resources. [swarm testing]: https://www.cs.utah.edu/~regehr/papers/swarm12.pdf There are more public APIs and instance introspection APIs that we have than this fuzzer exercises right now. We will need a better generator of valid Wasm than `wasm-opt -ttf` to really get the most out of those currently-unexercised APIs, since the Wasm modules generated by `wasm-opt -ttf` don't import and export a huge variety of things.
5 years ago
[[bin]]
name = "api_calls"
path = "fuzz_targets/api_calls.rs"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
test = false
Tweak some API doc generation (#772) * Build docs with the nightly toolchain so [foo::bar] links work by default. This is a relatively new feature of rustdoc and I thought it was stabilized at this point but apparently it's not! * Tweak some API docs on `wasmtime::Strategy` * Use `--all` to build all local crate documentation instead of trying to list the number of local crates * Tweak some documentation configuration to avoid warnings generated by Cargo.
5 years ago
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["binaryen"]
Add initial differential fuzzing Part of #611
5 years ago
[[bin]]
name = "differential"
path = "fuzz_targets/differential.rs"
fuzz: Don't run tests or docs for `differential` fuzz target
5 years ago
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["binaryen"]
Turn off binaryen in fuzzing by default ... but turn it back on in CI by default. The `binaryen-sys` crate builds binaryen from source, which is a drag on CI for a few reasons: * This is quite large and takes a good deal of time to build * The debug build directory for binaryen is 4GB large In an effort to both save time and disk space on the builders this commit adds a `binaryen` feature to the `wasmtime-fuzz` crate. This feature is enabled specifically when running the fuzzers on CI, but it is disabled during the typical `cargo test --all` command. This means that the test builders should save an extra 4G of space and be a bit speedier now that they don't build a giant wad of C++. We'll need to update the OSS-fuzz integration to enable the `binaryen` feature when executing `cargo fuzz build`, and I'll do that once this gets closer to landing.
5 years ago
Add a spec test fuzzer for Config (#1509) * Add a spec test fuzzer for Config This commit adds a new fuzzer which is intended to run on oss-fuzz. This fuzzer creates and arbitrary `Config` which *should* pass spec tests and then asserts that it does so. The goal here is to weed out any accidental bugs in global configuration which could cause non-spec-compliant behavior. * Move implementation to `fuzzing` crate
5 years ago
[[bin]]
name = "spectests"
path = "fuzz_targets/spectests.rs"
test = false
doc = false
fuzz: Add a fuzz target for `table.{get,set}` operations This new fuzz target exercises sequences of `table.get`s, `table.set`s, and GCs. It already found a couple bugs: * Some leaks due to ref count cycles between stores and host-defined functions closing over those stores. * If there are no live references for a PC, Cranelift can avoid emiting an associated stack map. This was running afoul of a debug assertion.
4 years ago
[[bin]]
name = "table_ops"
path = "fuzz_targets/table_ops.rs"
test = false
doc = false
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
[[bin]]
name = "peepmatic_simple_automata"
path = "fuzz_targets/peepmatic_simple_automata.rs"
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["peepmatic-fuzzing"]
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
[[bin]]
name = "peepmatic_fst_differential"
path = "fuzz_targets/peepmatic_fst_differential.rs"
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["peepmatic-fuzzing"]
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
[[bin]]
name = "peepmatic_parser"
path = "fuzz_targets/peepmatic_parser.rs"
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["peepmatic-fuzzing"]
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
[[bin]]
name = "peepmatic_compile"
path = "fuzz_targets/peepmatic_compile.rs"
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["peepmatic-fuzzing"]
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
[[bin]]
name = "peepmatic_interp"
path = "fuzz_targets/peepmatic_interp.rs"
test = false
doc = false
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
required-features = ["peepmatic-fuzzing"]
peepmatic: Define fuzz targets for various parts of `peepmatic`
5 years ago
Turn off binaryen in fuzzing by default ... but turn it back on in CI by default. The `binaryen-sys` crate builds binaryen from source, which is a drag on CI for a few reasons: * This is quite large and takes a good deal of time to build * The debug build directory for binaryen is 4GB large In an effort to both save time and disk space on the builders this commit adds a `binaryen` feature to the `wasmtime-fuzz` crate. This feature is enabled specifically when running the fuzzers on CI, but it is disabled during the typical `cargo test --all` command. This means that the test builders should save an extra 4G of space and be a bit speedier now that they don't build a giant wad of C++. We'll need to update the OSS-fuzz integration to enable the `binaryen` feature when executing `cargo fuzz build`, and I'll do that once this gets closer to landing.
5 years ago
[features]
Make the fuzzing CI job faster (#1727) * CI: Only build fuzz targets, don't run them over the corpora We've only ever caught a single potential regression by running the fuzz targets over a sample of their corpora. However, this is also our slowest CI job. Running the fuzz targets over their corpora simply isn't paying for itself. Instead, just ensure that we can build the fuzz targets with `cargo fuzz` and all of the libFuzzer and sanitizer instrumentation that it enables. This will ensure that we don't break the fuzz targets, and we leave finding regressions in the fuzz corpora to oss-fuzz. * fuzz: feature gate peepmatic's fuzz targets This makes it so that the CI's fuzz target-building job doesn't build peepmatic, and transitively Z3.
5 years ago
binaryen = ["wasmtime-fuzzing/binaryen"]