Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)

* Exceptions: add exception-specific (command-sequence) fuzzer.

This fuzzer uses a description of a set of "scenarios", arbitr

Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)

* Exceptions: add exception-specific (command-sequence) fuzzer.

This fuzzer uses a description of a set of "scenarios", arbitrarily
generated, to produce a specific kind of module that tests throw/catch
behavior. The module contains a chain of functions that invoke each
other; one will throw, and the rest may have catch clauses that do or
do not catch.

* Review feedback.

show more ...

Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)

* Polyfill `ToWasmtimeResult` and add eventually-necessary call sites

This commit polyfills `wasmtime_internal_error::To

Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)

* Polyfill `ToWasmtimeResult` and add eventually-necessary call sites

This commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in
`wasmtime_environ`, adds the cargo feature plumbing that will eventually connect
to the `"wasmtime_internal_error/anyhow"` cargo feature but for now just
configures this polyfill, and adds uses of the polyfill at all the sites that
will be necessary once we swap out `anyhow` for
`wasmtime_internal_error`. Currently, the polyfill is just an identity function,
because `wasmtime::Result`/`wasmtime_environ::error::Result` is just another
name for `anyhow::Result`. Once we do move away from `anyhow`, however, that
will no longer be the case, and these uses will do the necessary conversion.

My goal with landing this as an incremental commit is to make it so that the
actual commit that does the error crate swap out can be as close to _just_ the
`Cargo.toml` dependency change, without any other code changes as much as
possible. This, in turn, means that swap out should be super easy to revert, if
necessary.

* Add a couple more `.to_wasmtime_result()` invocations in fuzz code

* Revert "Add a couple more `.to_wasmtime_result()` invocations in fuzz code"

This reverts commit b33696e5f63f7eed731ca9dad10fec5e55a550d3.

* Move cranelift fuzz targets back to anyhow

* Fix cargo feature enablement for explorer

show more ...

Migrate fuzzing to `wasmtime::error` (#12269)

Split modules (#11993)

* Split GC to different modules and rename table_ops to gc_ops

* Remove table_ops from fuzz_targets. Renamed to gc_ops

* Address formatting failures

Add fuzzer integration for gc/mutatis (#11290)

* Add fuzzer integration for gc/mutatis

* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments

* Update Cargo.lock after r

Add fuzzer integration for gc/mutatis (#11290)

* Add fuzzer integration for gc/mutatis

* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments

* Update Cargo.lock after rebase

* Update rng.gen to rng.fill to avoid deprecation failure

* Remove table_ops from misc. Update fuzz_target. Keep Arbitrary impl it gives some dependecy error. Will be addressed later

* Update Cargo.lock to match upstream/main

* Regenerate Cargo.lock after rebase and dependency changes

* Reset Cargo.lock to upstream/main to preserve cargo-deny compatibility

* Update dependencies

---------

Co-authored-by: Khagan Karimov <[email protected]>

show more ...

Consolidate "util" crates for testing (#10423)

* Consolidate "util" crates for testing

This commit consolidates all of the existing crates we have for testing
into a smaller set of crates. Specific

Consolidate "util" crates for testing (#10423)

* Consolidate "util" crates for testing

This commit consolidates all of the existing crates we have for testing
into a smaller set of crates. Specifically:

* `crates/misc/component-fuzz-util` => `wasmtime-test-util` + `component-fuzz`
feature
* `crates/misc/component-test-util` => `wasmtime-test-util` + `component`
feature
* `crates/wast-util` => `wasmtime-test-util` + `wast` feature
* `crates/misc/component-macro-test` => `wasmtime-test-macros`

The goal is to have one location we put various test helpers/macros
rather than our current organically-grown many locations. This is
inspired by the test failure on #10405 where I'd like to refactor more
infrastructure to a "test util" location but it wasn't clear where to
put it so I wanted to do this refactoring first.

* Remove unused file

show more ...

asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)

As discussed previously, this change adds fuzzing for the x64 assembler
to the melting pot target, `misc`, in order to get at least so

asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)

As discussed previously, this change adds fuzzing for the x64 assembler
to the melting pot target, `misc`, in order to get at least some fuzzing
cycles on OSS-Fuzz.

show more ...

Consolidate some fuzzers into one (#10385)

This commit consolidates a number of fuzzers that we have in Wasmtime
into a single fuzzer. This follows the pattern of [wasm-tools's `run`
fuzzer][tools]

Consolidate some fuzzers into one (#10385)

This commit consolidates a number of fuzzers that we have in Wasmtime
into a single fuzzer. This follows the pattern of [wasm-tools's `run`
fuzzer][tools] where the first byte in the fuzz input says which fuzzer
to run and then the rest of the input is the input to the fuzzer. This
is intended to improve our time-slicing on OSS-Fuzz where less important
fuzzers don't hog time from the "important fuzzers" such as
`differential`. Some minor-ish fuzzers have been folded in to this new
fuzzer, but we can also always move things around as needed

[tools]: https://github.com/bytecodealliance/wasm-tools/blob/main/fuzz/fuzz_targets/run.rs

show more ...

Compute dominator tree using semi-NCA algorithm (#9603)

* Add dominator tree computed using semi-NCA algorithm.

* Add dominator tree fuzz target

* Move previous version of dominator tree to a sepa

Compute dominator tree using semi-NCA algorithm (#9603)

* Add dominator tree computed using semi-NCA algorithm.

* Add dominator tree fuzz target

* Move previous version of dominator tree to a separate file

* Improve comments.

* Use the new dominator tree in verifier.

* Remove unused `iterators` module.

show more ...

Leverage Rust 1.79, 1.80 (#9498)

This commit is a follow-up to #9496 to leverage various APIs that the
workspace now has access to. For example most dependencies on the
`once_cell` crate are now rem

Leverage Rust 1.79, 1.80 (#9498)

This commit is a follow-up to #9496 to leverage various APIs that the
workspace now has access to. For example most dependencies on the
`once_cell` crate are now removed in favor of the types stabilized in
the standard library: `LazyLock` and `LazyCell`. One dependency remains
in the `wasmtime` crate due to the `get_or_try_init` not being stable
yet.

Some additional helper methods on raw pointer slices are also available
for removing a few minor `unsafe` blocks.

show more ...

Fix some fuzz issues from updating wasm-tools (#9345)

This commit fixes some fuzz-related issues from the update of the
`wasm-tools` family of crates in #9336:

* Fuzzing with wasmi disables the GC

Fix some fuzz issues from updating wasm-tools (#9345)

This commit fixes some fuzz-related issues from the update of the
`wasm-tools` family of crates in #9336:

* Fuzzing with wasmi disables the GC proposal
* The exceptions proposal is always disabled for Wasmtime
* Wasmtime conditionally enables the GC/reference-types proposal
* Fully disable the GC proposal for now in Wasmtime as its
implementation is not complete and fuzzing needs more support.
* Log wasm module config before generating to help debug issues like
bytecodealliance/wasm-tools#1834

show more ...

Fold `cranelift-wasm` crate into `wasmtime-cranelift` (#9313)

This commit removes the `cranelift-wasm` crate by folding it directly
into the `wasmtime-cranelift` crate. Maintaining a runtime-agnosti

Fold `cranelift-wasm` crate into `wasmtime-cranelift` (#9313)

This commit removes the `cranelift-wasm` crate by folding it directly
into the `wasmtime-cranelift` crate. Maintaining a runtime-agnostic
translation of WebAssembly to Cranelift has always been a bit of a
burden on us and at this time there are no known users of this crate
who are helping us to maintain this crate. There's a good number of
abstractions in the crate purely for supporting alternative runtimes and
the crate could be much simpler with far less boilerplate if it were
specialized to Wasmtime.

This commit purely moves the crate sources, deletes then-dead code, and
updates `use` paths to all point to the right place. Otherwise this does
not actually yet contain any refactoring to specialize the translation
phase to Wasmtime itself. It's expected that will come in follow-up
commits should we decide to merge this.

show more ...

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
s

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
selection of those using just Cranelift for example.

show more ...

Introduce the `pulley-interpreter` crate (#9008)

* Introduce the `pulley-interpreter` crate

This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35

This

Introduce the `pulley-interpreter` crate (#9008)

* Introduce the `pulley-interpreter` crate

This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35

This commit introduces the `pulley-interpreter` crate which contains the Pulley
bytecode definition, encoder, decoder, disassembler, and interpreter.

This is still very much a work in progress! It is expected that we will tweak
encodings and bytecode definitions, that we will overhaul the interpreter (to,
for example, optionally support the unstable Rust `explicit_tail_calls`
feature), and otherwise make large changes. This is just a starting point to get
the ball rolling.

Subsequent commits and pull requests will do things like add the Cranelift
backend to produce Pulley bytecode from Wasm as well as the runtime integration
to run the Pulley interpreter inside Wasmtime.

* remove stray fn main

* Add small tests for special x registers

* Remove now-unused import

* always generate 0 pc rel offsets in arbitrary

* Add doc_auto_cfg feature for docs.rs

* enable all optional features for docs.rs

* Consolidate `BytecodeStream::{advance,get1,get2,...}` into `BytecodeStream::read`

* fix fuzz targets build

* inherit workspace lints in pulley's fuzz crate

* Merge fuzz targets into one target; fix a couple small fuzz bugs

* Add Pulley to our cargo vet config

* Add pulley as a crate to publish

* Move Pulley fuzz target into top level fuzz directory

show more ...

Resolve aliases before inserting values into the live set (#8945)

* Refactor the internals of `FunctionBuilder::insert_safepoint_spills` into a few smaller methods

* Initialize a logger for the `cr

Resolve aliases before inserting values into the live set (#8945)

* Refactor the internals of `FunctionBuilder::insert_safepoint_spills` into a few smaller methods

* Initialize a logger for the `cranelift-fuzzgen` fuzz target

* Resolve aliases before inserting values into the live set

This fixes a fuzz bug found in the development of
https://github.com/bytecodealliance/wasmtime/pull/8941

show more ...

Add a fuzz target for exercising bounds checks with various memory configs (#8742)

Add a fuzzer for async wasm (#8440)

* Add a fuzzer for async wasm

This commit revives a very old branch of mine to add a fuzzer for
Wasmtime in async mode. This work was originally blocked on
llvm/

Add a fuzzer for async wasm (#8440)

* Add a fuzzer for async wasm

This commit revives a very old branch of mine to add a fuzzer for
Wasmtime in async mode. This work was originally blocked on
llvm/llvm-project#53891 and while that's still an issue it now contains
a workaround for that issue. Support for async fuzzing required a good
deal of refactorings and changes, and the highlights are:

* The main part is that new intrinsics,
`__sanitizer_{start,finish}_fiber_switch` are now invoked around the
stack-switching routines of fibers. This only works on Unix and is set
to only compile when ASAN is enabled (otherwise everything is a noop).
This required refactoring of things to get it all in just the right
way for ASAN since it appears that these functions not only need to be
called but more-or-less need to be adjacent to each other in the code.
My guess is that while we're switching ASAN is in a "weird state" and
it's not ready to run arbitrary code.

* Stacks are a problem. The above issue in LLVM outlines how stacks
cannot be deallocated at this time because if the deallocated virtual
memory is later used for the heap then ASAN will have a false positive
about stack overflow. To handle this stacks are specially handled in
asan mode by using a special allocation path that never deallocates
stacks. This logic additionally applies to the pooling allocator which
uses a different stack allocation strategy with ASAN.

With all of the above a new fuzzer is added. This fuzzer generates an
arbitrary module, selects an arbitrary means of async (e.g.
epochs/fuel), and then tries to execute the exports of the module with
various values. In general the fuzzer is looking for crashes/panics as
opposed to correct answers as there's no oracle here. This is also
intended to stress the code used to switch on and off stacks.

* Fix non-async build

* Remove unused import

* Review comments

* Fix compile on MIRI

* Fix Windows build

show more ...

Run all `*.wast` tests in fuzzing (#8121)

* Run all `*.wast` tests in fuzzing

Currently we have a `spectest` fuzzer which uses fuzz input to generate
an arbitrary configuration for Wasmtime and the

Run all `*.wast` tests in fuzzing (#8121)

* Run all `*.wast` tests in fuzzing

Currently we have a `spectest` fuzzer which uses fuzz input to generate
an arbitrary configuration for Wasmtime and then executes the spec test.
This ensures that no matter the configuration Wasmtime can pass spec
tests. This commit expands this testing to include all `*.wast` tests we
have in this repository. While we don't have a ton we still have some
significant ones like in #8118 which will only reproduce when turning
knobs on CPU features.

* Fix CLI build

* Fix wast testing

show more ...

Update the wasm-tools family of crates (#7921)

* Update the wasm-tools family of crates

Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just

Update the wasm-tools family of crates (#7921)

* Update the wasm-tools family of crates

Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just pulling in the updates
first.

* Fix tests

* Fix fuzzer build

show more ...

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at th

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at the workspace level in Wasmtime rather than the crate level. This
uses a feature of Cargo first released with 1.74.0 (last week) of the
`[workspace.lints]` table. This should help create a more consistent set
of lints applied across all crates in our workspace in addition to
possibly running select clippy lints on CI as well.

* Move `unused_extern_crates` to the workspace level

This commit configures a `deny` lint level for the
`unused_extern_crates` lint to the workspace level rather than the
previous configuration at the individual crate level.

* Move `trivial_numeric_casts` to workspace level

* Change workspace lint levels to `warn`

CI will ensure that these don't get checked into the codebase and
otherwise provide fewer speed bumps for in-process development.

* Move `unstable_features` lint to workspace level

* Move `unused_import_braces` lint to workspace level

* Start running Clippy on CI

This commit configures our CI to run `cargo clippy --workspace` for all
merged PRs. Historically this hasn't been all the feasible due to the
amount of configuration required to control the number of warnings on
CI, but with Cargo's new `[lint]` table it's possible to have a
one-liner to silence all lints from Clippy by default. This commit by
default sets the `all` lint in Clippy to `allow` to by-default disable
warnings from Clippy. The goal of this PR is to enable selective access
to Clippy lints for Wasmtime on CI.

* Selectively enable `clippy::cast_sign_loss`

This would have fixed #7558 so try to head off future issues with that
by warning against this situation in a few crates. This lint is still
quite noisy though for Cranelift for example so it's not worthwhile at
this time to enable it for the whole workspace.

* Fix CI error

prtest:full

show more ...

Update `arbitrary` to 1.3.1 (#7236)

* Update to arbitrary 1.3.1

And use workspace dependencies for arbitrary.

* Prune cargo vet's supply-chain files

This is the mechanical changes made by running

Update `arbitrary` to 1.3.1 (#7236)

* Update to arbitrary 1.3.1

And use workspace dependencies for arbitrary.

* Prune cargo vet's supply-chain files

This is the mechanical changes made by running `cargo vet prune` which was
suggested to me when I ran `cargo vet`.

show more ...

winch(fuzz): Refactor Winch's fuzzing (#6432)

* winch(fuzz): Refactor Winch's fuzzing

This change is a follow-up to the discussion in
https://github.com/bytecodealliance/wasmtime/pull/6281.

The mo

winch(fuzz): Refactor Winch's fuzzing (#6432)

* winch(fuzz): Refactor Winch's fuzzing

This change is a follow-up to the discussion in
https://github.com/bytecodealliance/wasmtime/pull/6281.

The most notable characteristic of this change is that it enables
`winch` by default in the fuzzers. If compilation time is a big enough
concern I can add the cargo feature back. I opted to enable `winch` by
default for several reasons:

* It substantially reduces the `cfg` complexity -- at first I thought
I had covered all the places in which a `cfg` check would be needed,
but then I realized that I missed the Cranelift specific compiler
flags.

* It's the fastest route to enable winch by default in the fuzzers,
which we want to do eventually -- the only change we'd need at that
point would be to get rid of the winch-specific environment variable.

* We can get rid of the winch-specific checks in CI for fuzzing

* Implement Arbitraty for CompilerStrategy

Unconditionally return `Cranelift` for the `Arbitrary` implementation of
`CompilerStrategy`. This ensures that `Cranelift` is used as the
compiler for all the targets unless explicitly requested otherwise. As
of this change, only the differential target overrides the
`CompilerStrategy`

show more ...

Improve longevity for fuzzing corpus of wasm modules (#6322)

* Improve longevity for fuzzing corpus of wasm modules

This commit is an improvement to the longevity of Wasmtime's corpus of
fuzz input

Improve longevity for fuzzing corpus of wasm modules (#6322)

* Improve longevity for fuzzing corpus of wasm modules

This commit is an improvement to the longevity of Wasmtime's corpus of
fuzz inputs to the `instantiate` fuzzer. Currently the input to this
fuzzers is arbitrary binary data which is a "DNA" of sorts of what to
do. This DNA changes over time as we update the fuzzer and add
configuration options, for example. When this happens though the
meaning of all existing inputs in the corpus changes because they all
have slightly different meanings now. The goal of this commit is to
improve the usefulness of a historical corpus, with respect to the
WebAssembly modules generated, across changes to the DNA.

A custom mutator is now provided for the `instantiate` fuzzer. This
mutator will not only perform libfuzzer's default mutation for the input
but will additionally place an "envelope" around the fuzz input. Namely,
the fuzz input is encoded as a valid WebAssembly module where the actual
input to the fuzzer is a trailing custom section. When the fuzzer runs
over this input it will read the custom section, perform any
configuration generation necessary, and then use the envelope module as
the actual input to the fuzzer instead of whatever was generated from
the fuzz input. This means that when a future update is made to the DNA
of a module the interpretation of the fuzz input section will change but
the module in question will not change. This means that any interesting
shapes of modules with respect to instructions should be preserved over
time in theory.

Some consequences of this strategy, however, are:

* If the DNA changes then it's difficult to produce minor mutations of
the original module. This is because mutations generate a module based
on the new DNA which is likely much different than the preexisting
module. This mainly just means that libFuzzer will have to rediscover
how to mutate up into interesting shapes on DNA changes but it'll
still be able to retain all the existing interesting modules.
Additionally this can be mitigate with the integration of
`wasm-mutate` perhaps into these fuzzers as well.

* Protection is necessary against libFuzzer itself with respect to the
module. The existing fuzzers only expect valid modules to be created,
but libFuzzer can now create mutations which leave the trailing
section in place, meaning the module is no longer valid. One option is
to record a cryptographic hash in the fuzz input section of the
previous module, only using the module if the hashes match. This
approach will not work over time in the face of binary format changes,
however. For example the multi-memory proposal changed binary
encodings a year or so ago meaning that any previous fuzz-generated
cases would no longer be guaranteed to be valid. The strategy settled
by this PR is to pass a flag to the execution function indicating if
the module is "known valid" and gracefully handle error if it isn't
(for example if it's a prior test case).

I'll note that this new strategy of fuzzing is not applied to the
`differential` fuzzer. This could theoretically use the same strategy
but it relies much more strictly on being able to produce a module with
properties like NaN canonicalization, resource limits, fuel to limit
execution, etc. While it may be possible to integrate this with
`differential` in the future I figured it'd be better to start with the
`instantiate` fuzzer and go from there.

* Fix doc build

show more ...

winch(fuzz): Initial support for differential fuzzing (#6281)

* winch(fuzz): Initial support for differential fuzzing

This commit introduces initial support for differential fuzzing for Winch. In
o

winch(fuzz): Initial support for differential fuzzing (#6281)

* winch(fuzz): Initial support for differential fuzzing

This commit introduces initial support for differential fuzzing for Winch. In
order to fuzz winch, this change introduces the `winch` cargo feature. When the
`winch` cargo feature is enabled the differential fuzz target uses `wasmi` as
the differential engine and `wasm-smith` and `single-inst` as the module sources.

The intention behind this change is to have a *local* approach for fuzzing and
verifying programs generated by Winch and to have an initial implementation that
will allow us to eventually enable this change by default. Currently it's not
worth it to enable this change by default given all the filtering that needs to
happen to ensure that the generated modules are supported by Winch.

It's worth noting that the Wasm filtering code will be temporary, until Winch
reaches feature parity in terms of Wasm operators.

* Check build targets with the `winch` feature flag

* Rename fuzz target feature to `fuzz-winch`

show more ...

Chaos mode MVP: Skip branch optimization in MachBuffer (#6039)

* fuzz: Add chaos mode control plane

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Wa

Chaos mode MVP: Skip branch optimization in MachBuffer (#6039)

* fuzz: Add chaos mode control plane

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: Skip branch optimization with chaos mode

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: Rename chaos engine -> control plane

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* chaos mode: refactoring ControlPlane to be passed through the call stack by reference

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Remo Senekowitsch <[email protected]>

* fuzz: annotate chaos todos

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: cleanup control plane

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: remove control plane from compiler context

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: move control plane into emit state

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fuzz: fix remaining compiler errors

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* fix tests

* refactor emission state ctrl plane accessors

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* centralize conditional compilation of chaos mode

Also cleanup a few straggling dependencies on cranelift-control
that aren't needed anymore.

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* add cranelift-control to published crates

prtest:full

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

* add cranelift-control to public crates

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>

---------

Co-authored-by: Falk Zwimpfer <[email protected]>
Co-authored-by: Moritz Waser <[email protected]>
Co-authored-by: Remo Senekowitsch <[email protected]>

show more ...