Stream: git-wasmtime

Topic: wasmtime / PR #3264 Add differential fuzzing against V8

Wasmtime GitHub notifications bot (Aug 30 2021 at 14:52):

alexcrichton opened PR #3264 from fuzz-v8 to main:

This commit adds a differential fuzzing target to Wasmtime along the
lines of the wasmi and spec interpreters we already have, but with V8
instead. The intention here is that wasmi is unlikely to receive updates
over time (e.g. for SIMD), and the spec interpreter is not suitable for
fuzzing against in general due to its performance characteristics. The
hope is that V8 is indeed appropriate to fuzz against because it's
naturally receiving updates and it also is expected to have good
performance.

Here the rusty_v8 crate is used which provides bindings to V8 as well
as precompiled binaries by default. This matches exactly the use case we
need and at least for now I think the rusty_v8 crate will be
maintained by the Deno folks as they continue to develop it. If it
becomes an issue though maintaining we can evaluate other options to
have differential fuzzing against.

For now this commit enables the SIMD and bulk-memory feature of
fuzz-target-generation which should enable them to get
differentially-fuzzed with V8 in addition to the compilation fuzzing
we're already getting.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:09):

abrown submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:09):

abrown created PR review comment:

Shouldn't we be comparing v128 here and above?

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:20):

alexcrichton updated PR #3264 from fuzz-v8 to main.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:22):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:22):

alexcrichton created PR review comment:

Node doesn't, at this time, support v128 values, so if you have a function that returns v128, for example, you get:

TypeError: type incompatibility when transforming from/to JS

Above this though there's a check with:

    // not supported yet in V8
    if ty.params().chain(ty.results()).any(|t| t == ValType::V128) {
        log::trace!("exported function uses v128, skipping");
        return None;
    }

to avoid hitting this case by just skipping that fuzzing candidate.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:50):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:50):

alexcrichton created PR review comment:

er I should say that it doesn't support v128-in-JS, it only supports v128-in-wasm, so because we can only interact to wasm through JS that's where the limitation comes from

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:53):

abrown submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 16:53):

abrown created PR review comment:

Ah, I see.

Wasmtime GitHub notifications bot (Aug 30 2021 at 17:01):

alexcrichton updated PR #3264 from fuzz-v8 to main.

Wasmtime GitHub notifications bot (Aug 30 2021 at 17:08):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 17:08):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Aug 30 2021 at 17:08):

fitzgen created PR review comment:

Can you add a comment here that it is the caller's responsibility to ensure that the given wasm won't infinitely loop, since we have no way of adding fuel/timeouts to v8, afaik? Alternatively, in the past I've tried to encode that in the type system by making the oracle a tiny bit less reusable and taking a wasm_smith::Module (or wasm-opt -ttf module in the before times) rather than a raw byte slice.

Wasmtime GitHub notifications bot (Aug 31 2021 at 13:56):

alexcrichton updated PR #3264 from fuzz-v8 to main.

Wasmtime GitHub notifications bot (Aug 31 2021 at 14:34):

alexcrichton merged PR #3264.

Last updated: Oct 23 2024 at 20:03 UTC