3e1db847b3
This is the beginning of a new fuzzer that generates
correct-by-construction Wasm modules. This should allow us to better
exercise the compiler and correctness aspects of fuzzing. It is based off
of ahaas' original Wasm fuzzer.
At the moment, it can generate expressions made up of most binops, and
also nested blocks with unconditional breaks. Future CLs will add
additional constructs, such as br_if, loops, memory access, etc.
The way the fuzzer works is that it starts with an array of arbitrary
data provided by libfuzzer. It uses the data to generate an expression.
Care is taken to make use of the entire string. Basically, the
generator has a bunch of grammar-like rules for how to construct an
expression of a given type. For example, an i32 can be made by adding
two other i32s, or by wrapping an i64. The process then continues
recursively until all the data is consumed.
We generate an expression from a slice of data as follows:
* If the slice is less than or equal to the size of the type (e.g. 4
bytes for i32), then it will emit the entire slice as a constant.
* Otherwise, it will consume the first 4 bytes of the slice and use
this to select which rule to apply. Each rule then consumes the
remainder of the slice in an appropriate way. For example:
* Unary ops use the remainder of the slice to generate the argument.
* Binary ops consume another four bytes and mod this with the length
of the remaining slice to split the slice into two parts. Each of
these subslices are then used to generate one of the arguments to
the binop.
* Blocks are basically like a unary op, but a stack of block types is
maintained to facilitate branches. For blocks that end in a break,
the first four bytes of a slice are used to select the break depth
and the stack determines what type of expression to generate.
The goal is that once this generator is complete, it will provide a one
to one mapping between binary strings and valid Wasm modules.
Review-Url: https://codereview.chromium.org/2658723006
Cr-Commit-Position: refs/heads/master@{#43289}
|
||
|---|---|---|
| .. | ||
| json | ||
| parser | ||
| regexp | ||
| wasm_call | ||
| wasm_code | ||
| wasm_compile | ||
| wasm_data_section | ||
| wasm_function_sigs_section | ||
| wasm_globals_section | ||
| wasm_imports_section | ||
| wasm_memory_section | ||
| wasm_names_section | ||
| wasm_types_section | ||
| DEPS | ||
| fuzzer-support.cc | ||
| fuzzer-support.h | ||
| fuzzer.cc | ||
| fuzzer.gyp | ||
| fuzzer.isolate | ||
| fuzzer.status | ||
| json.cc | ||
| parser.cc | ||
| README.md | ||
| regexp.cc | ||
| testcfg.py | ||
| wasm_asmjs.tar.gz.sha1 | ||
| wasm-asmjs.cc | ||
| wasm-call.cc | ||
| wasm-code.cc | ||
| wasm-compile.cc | ||
| wasm-data-section.cc | ||
| wasm-function-sigs-section.cc | ||
| wasm-globals-section.cc | ||
| wasm-imports-section.cc | ||
| wasm-memory-section.cc | ||
| wasm-names-section.cc | ||
| wasm-section-fuzzers.cc | ||
| wasm-section-fuzzers.h | ||
| wasm-types-section.cc | ||
| wasm.cc | ||
| wasm.tar.gz.sha1 | ||
How to make a libFuzzer fuzzer in V8
This document describes how to make a new libFuzzer fuzzer for V8. A general introduction to libFuzzer can be found here. In short, libFuzzer is an in-process coverage-driven evolutionary fuzzer. libFuzzer serves you with a sequence of byte arrays that you can use to test your code. libFuzzer tries to generate this sequence of byte arrays in a way that maximizes test coverage.
Warning: By itself libFuzzer typically does not generate valid JavaScript code.
Changes to V8
tldr: Do the same as https://codereview.chromium.org/2280623002 to introduce a new fuzzer to V8.
This is a step by step guide on how to make a new fuzzer in V8. In the example
the fuzzer is called foo.
-
Copy one of the existing fuzzer implementations in test/fuzzer/, e.g.
cp wasm.cc foo.cc- Copying an existing fuzzer is a good idea to get all the required setup, e.g. setting up the isolate
-
Create a directory called
fooin test/fuzzer/ which contains at least one file- The file is used by the trybots to check whether the fuzzer actually compiles and runs
-
Copy the build rules of an existing fuzzer in BUILD.gn, e.g. the build rules for the wasm.cc fuzzer are
v8_source_set("wasm_fuzzer")andv8_fuzzer("wasm_fuzzer"). Note that the name has to be the name of the directory created in Step 2 +_fuzzerso that the scripts on the trybots work -
Now you can already compile the fuzzer, e.g. with
ninja -j 1000 -C out/x64.debug/v8_simple_foo_fuzzer- Use this binary to reproduce issues found by cluster fuzz, e.g.
out/x64.debug/v8_simple_foo_fuzzer testcase.foo
- Use this binary to reproduce issues found by cluster fuzz, e.g.
-
Copy the build rules of an existing fuzzer in test/fuzzer/fuzzer.gyp, e.g. the build rules for the wasm.cc fuzzer are
v8_simple_wasm_fuzzerandwasm_fuzzer_lib- This build rule is needed to compile with gyp
-
Copy the binary name and the test directory name in test/fuzzer/fuzzer.isolate
-
Add the fuzzer to the FuzzerTestSuite in test/fuzzer/testcfg.py
- This step is needed to run the fuzzer with the files created in Step 2 on the trybots
-
Commit the changes described above to the V8 repository
Changes to Chromium
tldr: Do the same as https://codereview.chromium.org/2344823002 to add the new fuzzer to cluster fuzz.
-
Copy the build rules of an existing fuzzer in testing/libfuzzer/fuzzers/BUILD.gn, e.g. the build rule for the wasm.cc fuzzer is
v8_wasm_fuzzer. There is no need to set adictionary, or aseed_corpus. See chromium-fuzzing-getting-started for more information. -
Compile the fuzzer in chromium (for different configurations see: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md):
-
gn gen out/libfuzzer '--args=use_libfuzzer=true is_asan=true is_debug=false enable_nacl=false' -
ninja -j 1000 -C out/libfuzzer/ v8_foo_fuzzer
-
-
Run the fuzzer locally
mkdir /tmp/empty_corpus && out/libfuzzer/v8_foo_fuzzer /tmp/empty_corpus