Skip to content

Conversation

@alexcrichton
Copy link
Member

This commit adds a new fuzzer mode to the misc fuzzer of Wasmtime which is focused on async events and interleavings of components using the component-model-async proposal. This fuzzer works by having a precompiled guest program which serves as the component to run. This precompiled component has a custom fuzz.wit which is used to interface with the fuzzer itself. The fuzzer is then a fuzz-generated sequence of commands to send to the component which verifies that everything executes correctly, has no panics, etc.

This fuzzer intends to stress async communication and task infrastructure with component-model-async. Notably this does not stress lifting/lowering or arbitrary type signatures. This does, however, permute all of the following:

  • Guest/host interactions (also guest/guest, host/host, etc).
  • Async functions, both ready and pending.
  • Future operations: reads, writes, cancellation, transfers, etc.
  • Stream operations: reads, writes, cancellation, transfers, etc.

This is all throwing into a large "soup" and then asserted to work correctly. There's a few gotchas here and there for how this fuzzer is designed, such as some events requiring "yield N times to await this event happening". This is required because Wasmtime is allowed to non-deterministically select between a number of "ready events" and what to dispatch.

This is not intended to be a one-size-fits-all fuzzer for component-model-async. The recent enhancements to the component_api fuzzer are intended to complement this fuzzer in terms of what's stressed where internally.

@alexcrichton alexcrichton requested a review from dicej December 3, 2025 20:49
@alexcrichton
Copy link
Member Author

Currently leaving this in draft form while bytecodealliance/wit-bindgen#1446 is pending.

@github-project-automation github-project-automation bot moved this to Backlog in Ship WASIp3 Dec 3, 2025
@alexcrichton alexcrichton added the wasm-proposal:component-model-async Issues related to the WebAssembly Component Model async proposal label Dec 3, 2025
@alexcrichton
Copy link
Member Author

I'll also note that I understand this is a pretty meat and pretty dense fuzzer, so I'm happy to walk through it if @dicej you or anyone else is interested. I'm also happy to write up more docs anywhere as necessary. Current docs are primarily located at crates/test-programs/src/bin/fuzz_async.rs

@github-actions github-actions bot added fuzzing Issues related to our fuzzing infrastructure wasmtime:api Related to the API of the `wasmtime` crate itself labels Dec 3, 2025
@github-actions
Copy link

github-actions bot commented Dec 3, 2025

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "fuzzing", "wasm-proposal:component-model-async", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime
which is focused on async events and interleavings of components using
the component-model-async proposal. This fuzzer works by having a
precompiled guest program which serves as the component to run. This
precompiled component has a custom `fuzz.wit` which is used to interface
with the fuzzer itself. The fuzzer is then a fuzz-generated sequence of
commands to send to the component which verifies that everything
executes correctly, has no panics, etc.

This fuzzer intends to stress async communication and task
infrastructure with component-model-async. Notably this does not stress
lifting/lowering or arbitrary type signatures. This does, however,
permute all of the following:

* Guest/host interactions (also guest/guest, host/host, etc).
* Async functions, both ready and pending.
* Future operations: reads, writes, cancellation, transfers, etc.
* Stream operations: reads, writes, cancellation, transfers, etc.

This is all throwing into a large "soup" and then asserted to work
correctly. There's a few gotchas here and there for how this fuzzer is
designed, such as some events requiring "yield N times to await this
event happening". This is required because Wasmtime is allowed to
non-deterministically select between a number of "ready events" and what
to dispatch.

This is not intended to be a one-size-fits-all fuzzer for
component-model-async. The recent enhancements to the `component_api`
fuzzer are intended to complement this fuzzer in terms of what's
stressed where internally.
@alexcrichton alexcrichton marked this pull request as ready for review December 4, 2025 15:35
@alexcrichton alexcrichton requested review from a team as code owners December 4, 2025 15:35
@alexcrichton alexcrichton requested review from fitzgen and removed request for a team December 4, 2025 15:35
@alexcrichton alexcrichton moved this from Backlog to In progress in Ship WASIp3 Dec 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fuzzing Issues related to our fuzzing infrastructure wasm-proposal:component-model-async Issues related to the WebAssembly Component Model async proposal wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

1 participant