Stream: git-wasmtime

Topic: wasmtime / PR #3038 Cranelift fuzzer POC

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:34):

afonso360 opened PR #3038 from fuzz-gen to main:

Hey!

Here's an initial version of the cranelift fuzzer.

We generate a random cranelift function based on input bytes from the fuzzer. Currently we can generate 7 instructions, but it is already enough to get us into trouble.

There is also a gen_testcase util that grabs fuzzer artifacts and converts them into clif files for easier testing.

In order for the fuzzer to be useful in testing DivByZero traps we need to disable overflow checks:

 RUSTFLAGS="-C overflow-checks=off" cargo fuzz run fuzzgen

Otherwise, the interpreter crashes immediately with overflows (We also need to fix this).

I've based my design a lot on @fitzgen 's blog post about wasm-smith. Its what made me start thinking about building this for cranelift in the first place. Thanks!

• Organization
  * I've created a new cargo-fuzz package for cranelift, should I merge the fuzzer with wasmtime's fuzzers?
  * Is there a way to keep track which cranelift features we are covering / not? It would be useful to keep track of this, so that we don't accidentally miss any feature.

• Design questions:
  * How do we deal with arbitrary memory accesses?
  * @cfallin suggested we run on the interpreter first and check for invalid memory accesses.
  * @abrown mentioned that we still need some work on the interpreter before being able to do this
  * How do we deal with traps?
  * This first version is also a POC for this, the idea being that the fuzzer will generate a div by zero or overflow.
  * We should be able to catch this in the interpreter
  * If the program traps, it would be useful to run it on the host and check for the same Trap. Can we do this?
  * How do we deal with infinite loops?
  * My idea here is to allow a fixed number of steps on the interpreter, and if we exceed those, we just ignore this program.
  * Is there any other bad behavior that we need to handle specially?

  * Should we distinguish between pointer types and i64's in the generator? We can just use any i64 and the program will crash until it does a valid thing, This might not be great in terms of fuzzing efficiency but it might generate more interesting programs.

CC: @cfallin, @andrewbrown, @fitzgen, @bjorn3 from the earlier fuzzer discussion

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:47):

afonso360 updated PR #3038 from fuzz-gen to main.

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

use libfuzzer_sys::fuzz_target;

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 submitted PR review.

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

This probably needs to be changed.

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

use cranelift:codegen::ir::Function;

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

cranelift = { path = "../umbrella" }
cranelift-filetests = { path = "../filetests" }
cranelift-interpreter = { path = "../interpreter" }
cranelift-fuzzgen = { path = "../fuzzgen" }

Wasmtime GitHub notifications bot (Jun 27 2021 at 16:52):

bjorn3 created PR review comment:

Can you please move the doc comments above the attributes?

Wasmtime GitHub notifications bot (Jun 27 2021 at 17:09):

afonso360 updated PR #3038 from fuzz-gen to main.

Last updated: Nov 22 2024 at 17:03 UTC