[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
// Copyright 2017 the V8 project authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
// found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
|
|
|
|
|
|
#include "include/v8.h"
|
2019-05-22 07:55:37 +00:00
|
|
|
#include "src/execution/isolate.h"
|
2019-05-23 08:51:46 +00:00
|
|
|
#include "src/objects/objects-inl.h"
|
|
|
|
|
#include "src/objects/objects.h"
|
2019-05-29 13:30:15 +00:00
|
|
|
#include "src/utils/ostreams.h"
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
#include "src/wasm/wasm-interpreter.h"
|
|
|
|
|
#include "src/wasm/wasm-module-builder.h"
|
|
|
|
|
#include "src/wasm/wasm-module.h"
|
2020-03-04 22:53:37 +00:00
|
|
|
#include "src/wasm/wasm-opcodes.h"
|
2019-05-29 13:30:15 +00:00
|
|
|
#include "test/common/wasm/flag-utils.h"
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
#include "test/common/wasm/test-signatures.h"
|
|
|
|
|
#include "test/common/wasm/wasm-module-runner.h"
|
|
|
|
|
#include "test/fuzzer/fuzzer-support.h"
|
2017-05-08 09:22:54 +00:00
|
|
|
#include "test/fuzzer/wasm-fuzzer-common.h"
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-09-01 13:20:46 +00:00
|
|
|
namespace v8 {
|
|
|
|
|
namespace internal {
|
|
|
|
|
namespace wasm {
|
|
|
|
|
namespace fuzzer {
|
2017-08-09 08:11:21 +00:00
|
|
|
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
namespace {
|
|
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
constexpr int kMaxFunctions = 4;
|
2018-01-29 16:45:59 +00:00
|
|
|
constexpr int kMaxGlobals = 64;
|
2017-12-21 14:31:42 +00:00
|
|
|
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
class DataRange {
|
2018-07-12 09:05:43 +00:00
|
|
|
Vector<const uint8_t> data_;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
|
|
|
|
public:
|
2018-07-12 09:05:43 +00:00
|
|
|
explicit DataRange(Vector<const uint8_t> data) : data_(data) {}
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-12-21 14:30:32 +00:00
|
|
|
// Don't accidentally pass DataRange by value. This will reuse bytes and might
|
|
|
|
|
// lead to OOM because the end might not be reached.
|
|
|
|
|
// Define move constructor and move assignment, disallow copy constructor and
|
|
|
|
|
// copy assignment (below).
|
2018-08-02 08:16:29 +00:00
|
|
|
DataRange(DataRange&& other) V8_NOEXCEPT : DataRange(other.data_) {
|
|
|
|
|
other.data_ = {};
|
|
|
|
|
}
|
|
|
|
|
DataRange& operator=(DataRange&& other) V8_NOEXCEPT {
|
2017-12-21 14:30:32 +00:00
|
|
|
data_ = other.data_;
|
2018-07-12 09:05:43 +00:00
|
|
|
other.data_ = {};
|
2017-12-21 14:30:32 +00:00
|
|
|
return *this;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2018-07-12 09:05:43 +00:00
|
|
|
size_t size() const { return data_.size(); }
|
2017-12-21 14:30:32 +00:00
|
|
|
|
|
|
|
|
DataRange split() {
|
2018-07-12 09:05:43 +00:00
|
|
|
uint16_t num_bytes = get<uint16_t>() % std::max(size_t{1}, data_.size());
|
|
|
|
|
DataRange split(data_.SubVector(0, num_bytes));
|
2017-12-21 14:30:32 +00:00
|
|
|
data_ += num_bytes;
|
|
|
|
|
return split;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2018-11-15 15:08:32 +00:00
|
|
|
template <typename T, size_t max_bytes = sizeof(T)>
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
T get() {
|
2018-11-15 15:08:32 +00:00
|
|
|
STATIC_ASSERT(max_bytes <= sizeof(T));
|
2017-12-21 14:31:42 +00:00
|
|
|
// We want to support the case where we have less than sizeof(T) bytes
|
|
|
|
|
// remaining in the slice. For example, if we emit an i32 constant, it's
|
|
|
|
|
// okay if we don't have a full four bytes available, we'll just use what
|
|
|
|
|
// we have. We aren't concerned about endianness because we are generating
|
|
|
|
|
// arbitrary expressions.
|
2018-11-15 15:08:32 +00:00
|
|
|
const size_t num_bytes = std::min(max_bytes, data_.size());
|
2017-12-21 14:31:42 +00:00
|
|
|
T result = T();
|
2019-04-29 11:06:49 +00:00
|
|
|
memcpy(&result, data_.begin(), num_bytes);
|
2017-12-21 14:31:42 +00:00
|
|
|
data_ += num_bytes;
|
|
|
|
|
return result;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
2017-12-21 14:30:32 +00:00
|
|
|
|
|
|
|
|
DISALLOW_COPY_AND_ASSIGN(DataRange);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
};
|
|
|
|
|
|
2020-04-25 13:03:14 +00:00
|
|
|
template <>
|
|
|
|
|
bool DataRange::get<bool>() {
|
|
|
|
|
// SPECIALIZATION FOR BOOL
|
|
|
|
|
// The -O3 on release will break the result. This creates a different
|
|
|
|
|
// observable side effect when invoking get<bool> between debug and release
|
|
|
|
|
// version, which eventually makes the code output different as well as
|
|
|
|
|
// raising various unrecoverable errors on runtime. It is caused by undefined
|
|
|
|
|
// behavior of assigning boolean via memcpy from randomized bytes.
|
|
|
|
|
return get<uint8_t>() % 2 == 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
ValueType GetValueType(DataRange* data) {
|
2020-02-06 18:26:29 +00:00
|
|
|
// TODO(v8:8460): We do not add kWasmS128 here yet because this method is used
|
|
|
|
|
// to generate globals, and since we do not have v128.const yet, there is no
|
|
|
|
|
// way to specify an initial value a global of this type.
|
2019-07-08 11:44:42 +00:00
|
|
|
switch (data->get<uint8_t>() % 4) {
|
2017-12-21 13:53:15 +00:00
|
|
|
case 0:
|
|
|
|
|
return kWasmI32;
|
|
|
|
|
case 1:
|
|
|
|
|
return kWasmI64;
|
|
|
|
|
case 2:
|
|
|
|
|
return kWasmF32;
|
|
|
|
|
case 3:
|
|
|
|
|
return kWasmF64;
|
|
|
|
|
}
|
|
|
|
|
UNREACHABLE();
|
|
|
|
|
}
|
|
|
|
|
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
class WasmGenerator {
|
2020-03-12 14:29:51 +00:00
|
|
|
template <WasmOpcode Op, ValueType::Kind... Args>
|
2019-07-08 11:44:42 +00:00
|
|
|
void op(DataRange* data) {
|
2017-11-06 15:48:17 +00:00
|
|
|
Generate<Args...>(data);
|
|
|
|
|
builder_->Emit(Op);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2017-11-15 11:51:15 +00:00
|
|
|
class BlockScope {
|
|
|
|
|
public:
|
|
|
|
|
BlockScope(WasmGenerator* gen, WasmOpcode block_type, ValueType result_type,
|
|
|
|
|
ValueType br_type)
|
|
|
|
|
: gen_(gen) {
|
|
|
|
|
gen->blocks_.push_back(br_type);
|
2020-03-12 14:29:51 +00:00
|
|
|
gen->builder_->EmitWithU8(block_type, result_type.value_type_code());
|
2017-11-15 11:51:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
~BlockScope() {
|
|
|
|
|
gen_->builder_->Emit(kExprEnd);
|
|
|
|
|
gen_->blocks_.pop_back();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
WasmGenerator* const gen_;
|
|
|
|
|
};
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind T>
|
2019-07-08 11:44:42 +00:00
|
|
|
void block(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
BlockScope block_scope(this, kExprBlock, ValueType(T), ValueType(T));
|
2017-11-06 15:48:17 +00:00
|
|
|
Generate<T>(data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind T>
|
2019-07-08 11:44:42 +00:00
|
|
|
void loop(DataRange* data) {
|
2017-11-15 11:51:15 +00:00
|
|
|
// When breaking to a loop header, don't provide any input value (hence
|
|
|
|
|
// kWasmStmt).
|
2020-03-12 14:29:51 +00:00
|
|
|
BlockScope block_scope(this, kExprLoop, ValueType(T), kWasmStmt);
|
2017-11-15 11:51:15 +00:00
|
|
|
Generate<T>(data);
|
|
|
|
|
}
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2018-01-30 11:38:01 +00:00
|
|
|
enum IfType { kIf, kIfElse };
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind T, IfType type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void if_(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
static_assert(T == ValueType::kStmt || type == kIfElse,
|
2018-01-30 11:38:01 +00:00
|
|
|
"if without else cannot produce a value");
|
2020-03-12 14:29:51 +00:00
|
|
|
Generate<ValueType::kI32>(data);
|
|
|
|
|
BlockScope block_scope(this, kExprIf, ValueType(T), ValueType(T));
|
2018-01-30 11:38:01 +00:00
|
|
|
Generate<T>(data);
|
|
|
|
|
if (type == kIfElse) {
|
|
|
|
|
builder_->Emit(kExprElse);
|
|
|
|
|
Generate<T>(data);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void br(DataRange* data) {
|
2017-11-15 11:51:15 +00:00
|
|
|
// There is always at least the block representing the function body.
|
|
|
|
|
DCHECK(!blocks_.empty());
|
2019-07-08 11:44:42 +00:00
|
|
|
const uint32_t target_block = data->get<uint32_t>() % blocks_.size();
|
2017-11-06 15:48:17 +00:00
|
|
|
const ValueType break_type = blocks_[target_block];
|
|
|
|
|
|
|
|
|
|
Generate(break_type, data);
|
2017-11-08 21:03:20 +00:00
|
|
|
builder_->EmitWithI32V(
|
|
|
|
|
kExprBr, static_cast<uint32_t>(blocks_.size()) - 1 - target_block);
|
2017-11-06 15:48:17 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void br_if(DataRange* data) {
|
2018-01-29 16:42:03 +00:00
|
|
|
// There is always at least the block representing the function body.
|
|
|
|
|
DCHECK(!blocks_.empty());
|
2019-07-08 11:44:42 +00:00
|
|
|
const uint32_t target_block = data->get<uint32_t>() % blocks_.size();
|
2018-01-29 16:42:03 +00:00
|
|
|
const ValueType break_type = blocks_[target_block];
|
|
|
|
|
|
|
|
|
|
Generate(break_type, data);
|
|
|
|
|
Generate(kWasmI32, data);
|
|
|
|
|
builder_->EmitWithI32V(
|
|
|
|
|
kExprBrIf, static_cast<uint32_t>(blocks_.size()) - 1 - target_block);
|
2020-03-12 14:29:51 +00:00
|
|
|
ConvertOrGenerate(break_type, ValueType(wanted_type), data);
|
2018-01-29 16:42:03 +00:00
|
|
|
}
|
|
|
|
|
|
2017-11-08 21:03:20 +00:00
|
|
|
// TODO(eholk): make this function constexpr once gcc supports it
|
|
|
|
|
static uint8_t max_alignment(WasmOpcode memop) {
|
|
|
|
|
switch (memop) {
|
2020-03-12 23:53:38 +00:00
|
|
|
case kExprS128LoadMem:
|
|
|
|
|
case kExprS128StoreMem:
|
|
|
|
|
return 4;
|
2017-11-08 21:03:20 +00:00
|
|
|
case kExprI64LoadMem:
|
|
|
|
|
case kExprF64LoadMem:
|
|
|
|
|
case kExprI64StoreMem:
|
|
|
|
|
case kExprF64StoreMem:
|
2020-01-14 18:17:34 +00:00
|
|
|
case kExprI64AtomicStore:
|
|
|
|
|
case kExprI64AtomicLoad:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI64AtomicAdd:
|
|
|
|
|
case kExprI64AtomicSub:
|
|
|
|
|
case kExprI64AtomicAnd:
|
|
|
|
|
case kExprI64AtomicOr:
|
|
|
|
|
case kExprI64AtomicXor:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI64AtomicExchange:
|
|
|
|
|
case kExprI64AtomicCompareExchange:
|
2017-11-08 21:03:20 +00:00
|
|
|
return 3;
|
|
|
|
|
case kExprI32LoadMem:
|
|
|
|
|
case kExprI64LoadMem32S:
|
|
|
|
|
case kExprI64LoadMem32U:
|
|
|
|
|
case kExprF32LoadMem:
|
|
|
|
|
case kExprI32StoreMem:
|
|
|
|
|
case kExprI64StoreMem32:
|
|
|
|
|
case kExprF32StoreMem:
|
2020-01-14 18:17:34 +00:00
|
|
|
case kExprI32AtomicStore:
|
|
|
|
|
case kExprI64AtomicStore32U:
|
|
|
|
|
case kExprI32AtomicLoad:
|
|
|
|
|
case kExprI64AtomicLoad32U:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI32AtomicAdd:
|
|
|
|
|
case kExprI32AtomicSub:
|
|
|
|
|
case kExprI32AtomicAnd:
|
|
|
|
|
case kExprI32AtomicOr:
|
|
|
|
|
case kExprI32AtomicXor:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI32AtomicExchange:
|
|
|
|
|
case kExprI32AtomicCompareExchange:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI64AtomicAdd32U:
|
|
|
|
|
case kExprI64AtomicSub32U:
|
|
|
|
|
case kExprI64AtomicAnd32U:
|
|
|
|
|
case kExprI64AtomicOr32U:
|
|
|
|
|
case kExprI64AtomicXor32U:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI64AtomicExchange32U:
|
|
|
|
|
case kExprI64AtomicCompareExchange32U:
|
2017-11-08 21:03:20 +00:00
|
|
|
return 2;
|
|
|
|
|
case kExprI32LoadMem16S:
|
|
|
|
|
case kExprI32LoadMem16U:
|
|
|
|
|
case kExprI64LoadMem16S:
|
|
|
|
|
case kExprI64LoadMem16U:
|
|
|
|
|
case kExprI32StoreMem16:
|
|
|
|
|
case kExprI64StoreMem16:
|
2020-01-14 18:17:34 +00:00
|
|
|
case kExprI32AtomicStore16U:
|
|
|
|
|
case kExprI64AtomicStore16U:
|
|
|
|
|
case kExprI32AtomicLoad16U:
|
|
|
|
|
case kExprI64AtomicLoad16U:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI32AtomicAdd16U:
|
|
|
|
|
case kExprI32AtomicSub16U:
|
|
|
|
|
case kExprI32AtomicAnd16U:
|
|
|
|
|
case kExprI32AtomicOr16U:
|
|
|
|
|
case kExprI32AtomicXor16U:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI32AtomicExchange16U:
|
|
|
|
|
case kExprI32AtomicCompareExchange16U:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI64AtomicAdd16U:
|
|
|
|
|
case kExprI64AtomicSub16U:
|
|
|
|
|
case kExprI64AtomicAnd16U:
|
|
|
|
|
case kExprI64AtomicOr16U:
|
|
|
|
|
case kExprI64AtomicXor16U:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI64AtomicExchange16U:
|
|
|
|
|
case kExprI64AtomicCompareExchange16U:
|
2017-11-08 21:03:20 +00:00
|
|
|
return 1;
|
|
|
|
|
case kExprI32LoadMem8S:
|
|
|
|
|
case kExprI32LoadMem8U:
|
|
|
|
|
case kExprI64LoadMem8S:
|
|
|
|
|
case kExprI64LoadMem8U:
|
|
|
|
|
case kExprI32StoreMem8:
|
|
|
|
|
case kExprI64StoreMem8:
|
2020-01-14 18:17:34 +00:00
|
|
|
case kExprI32AtomicStore8U:
|
|
|
|
|
case kExprI64AtomicStore8U:
|
|
|
|
|
case kExprI32AtomicLoad8U:
|
|
|
|
|
case kExprI64AtomicLoad8U:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI32AtomicAdd8U:
|
|
|
|
|
case kExprI32AtomicSub8U:
|
|
|
|
|
case kExprI32AtomicAnd8U:
|
|
|
|
|
case kExprI32AtomicOr8U:
|
|
|
|
|
case kExprI32AtomicXor8U:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI32AtomicExchange8U:
|
|
|
|
|
case kExprI32AtomicCompareExchange8U:
|
2020-01-21 14:43:23 +00:00
|
|
|
case kExprI64AtomicAdd8U:
|
|
|
|
|
case kExprI64AtomicSub8U:
|
|
|
|
|
case kExprI64AtomicAnd8U:
|
|
|
|
|
case kExprI64AtomicOr8U:
|
|
|
|
|
case kExprI64AtomicXor8U:
|
2020-01-30 14:34:16 +00:00
|
|
|
case kExprI64AtomicExchange8U:
|
|
|
|
|
case kExprI64AtomicCompareExchange8U:
|
2017-11-08 21:03:20 +00:00
|
|
|
return 0;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <WasmOpcode memory_op, ValueType::Kind... arg_types>
|
2019-07-08 11:44:42 +00:00
|
|
|
void memop(DataRange* data) {
|
|
|
|
|
const uint8_t align = data->get<uint8_t>() % (max_alignment(memory_op) + 1);
|
|
|
|
|
const uint32_t offset = data->get<uint32_t>();
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2017-11-08 10:25:14 +00:00
|
|
|
// Generate the index and the arguments, if any.
|
2020-03-12 14:29:51 +00:00
|
|
|
Generate<ValueType::kI32, arg_types...>(data);
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2020-03-09 20:52:40 +00:00
|
|
|
if (WasmOpcodes::IsPrefixOpcode(static_cast<WasmOpcode>(memory_op >> 8))) {
|
2020-03-04 22:53:37 +00:00
|
|
|
DCHECK(memory_op >> 8 == kAtomicPrefix || memory_op >> 8 == kSimdPrefix);
|
2020-01-14 18:17:34 +00:00
|
|
|
builder_->EmitWithPrefix(memory_op);
|
|
|
|
|
} else {
|
|
|
|
|
builder_->Emit(memory_op);
|
|
|
|
|
}
|
2017-11-06 15:48:17 +00:00
|
|
|
builder_->EmitU32V(align);
|
|
|
|
|
builder_->EmitU32V(offset);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <WasmOpcode Op, ValueType::Kind... Args>
|
2020-01-21 14:43:23 +00:00
|
|
|
void atomic_op(DataRange* data) {
|
|
|
|
|
const uint8_t align = data->get<uint8_t>() % (max_alignment(Op) + 1);
|
|
|
|
|
const uint32_t offset = data->get<uint32_t>();
|
|
|
|
|
|
|
|
|
|
Generate<Args...>(data);
|
|
|
|
|
builder_->EmitWithPrefix(Op);
|
|
|
|
|
|
|
|
|
|
builder_->EmitU32V(align);
|
|
|
|
|
builder_->EmitU32V(offset);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <WasmOpcode Op, ValueType::Kind... Args>
|
2020-02-06 18:26:29 +00:00
|
|
|
void simd_op(DataRange* data) {
|
|
|
|
|
Generate<Args...>(data);
|
|
|
|
|
builder_->EmitWithPrefix(Op);
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-03 23:56:53 +00:00
|
|
|
void simd_shuffle(DataRange* data) {
|
|
|
|
|
Generate<ValueType::kS128, ValueType::kS128>(data);
|
|
|
|
|
builder_->EmitWithPrefix(kExprS8x16Shuffle);
|
|
|
|
|
for (int i = 0; i < kSimd128Size; i++) {
|
|
|
|
|
builder_->EmitByte(static_cast<uint8_t>(data->get<byte>() % 32));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void drop(DataRange* data) {
|
2017-12-21 13:53:15 +00:00
|
|
|
Generate(GetValueType(data), data);
|
|
|
|
|
builder_->Emit(kExprDrop);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void call(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
call(data, ValueType(wanted_type));
|
2017-12-21 14:31:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Convert(ValueType src, ValueType dst) {
|
|
|
|
|
auto idx = [](ValueType t) -> int {
|
2020-03-12 14:29:51 +00:00
|
|
|
switch (t.kind()) {
|
|
|
|
|
case ValueType::kI32:
|
2017-12-21 14:31:42 +00:00
|
|
|
return 0;
|
2020-03-12 14:29:51 +00:00
|
|
|
case ValueType::kI64:
|
2017-12-21 14:31:42 +00:00
|
|
|
return 1;
|
2020-03-12 14:29:51 +00:00
|
|
|
case ValueType::kF32:
|
2017-12-21 14:31:42 +00:00
|
|
|
return 2;
|
2020-03-12 14:29:51 +00:00
|
|
|
case ValueType::kF64:
|
2017-12-21 14:31:42 +00:00
|
|
|
return 3;
|
|
|
|
|
default:
|
|
|
|
|
UNREACHABLE();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
static constexpr WasmOpcode kConvertOpcodes[] = {
|
|
|
|
|
// {i32, i64, f32, f64} -> i32
|
|
|
|
|
kExprNop, kExprI32ConvertI64, kExprI32SConvertF32, kExprI32SConvertF64,
|
|
|
|
|
// {i32, i64, f32, f64} -> i64
|
|
|
|
|
kExprI64SConvertI32, kExprNop, kExprI64SConvertF32, kExprI64SConvertF64,
|
|
|
|
|
// {i32, i64, f32, f64} -> f32
|
|
|
|
|
kExprF32SConvertI32, kExprF32SConvertI64, kExprNop, kExprF32ConvertF64,
|
|
|
|
|
// {i32, i64, f32, f64} -> f64
|
|
|
|
|
kExprF64SConvertI32, kExprF64SConvertI64, kExprF64ConvertF32, kExprNop};
|
|
|
|
|
int arr_idx = idx(dst) << 2 | idx(src);
|
|
|
|
|
builder_->Emit(kConvertOpcodes[arr_idx]);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void ConvertOrGenerate(ValueType src, ValueType dst, DataRange* data) {
|
2018-01-29 16:42:03 +00:00
|
|
|
if (src == dst) return;
|
|
|
|
|
if (src == kWasmStmt && dst != kWasmStmt) {
|
|
|
|
|
Generate(dst, data);
|
|
|
|
|
} else if (dst == kWasmStmt && src != kWasmStmt) {
|
|
|
|
|
builder_->Emit(kExprDrop);
|
|
|
|
|
} else {
|
|
|
|
|
Convert(src, dst);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void call(DataRange* data, ValueType wanted_type) {
|
|
|
|
|
int func_index = data->get<uint8_t>() % functions_.size();
|
2017-12-21 14:31:42 +00:00
|
|
|
FunctionSig* sig = functions_[func_index];
|
|
|
|
|
// Generate arguments.
|
|
|
|
|
for (size_t i = 0; i < sig->parameter_count(); ++i) {
|
|
|
|
|
Generate(sig->GetParam(i), data);
|
|
|
|
|
}
|
|
|
|
|
// Emit call.
|
|
|
|
|
builder_->EmitWithU32V(kExprCallFunction, func_index);
|
|
|
|
|
// Convert the return value to the wanted type.
|
|
|
|
|
ValueType return_type =
|
|
|
|
|
sig->return_count() == 0 ? kWasmStmt : sig->GetReturn(0);
|
|
|
|
|
if (return_type == kWasmStmt && wanted_type != kWasmStmt) {
|
|
|
|
|
// The call did not generate a value. Thus just generate it here.
|
|
|
|
|
Generate(wanted_type, data);
|
|
|
|
|
} else if (return_type != kWasmStmt && wanted_type == kWasmStmt) {
|
|
|
|
|
// The call did generate a value, but we did not want one.
|
|
|
|
|
builder_->Emit(kExprDrop);
|
|
|
|
|
} else if (return_type != wanted_type) {
|
|
|
|
|
// If the returned type does not match the wanted type, convert it.
|
|
|
|
|
Convert(return_type, wanted_type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-29 16:45:59 +00:00
|
|
|
struct Var {
|
2018-01-02 18:52:49 +00:00
|
|
|
uint32_t index;
|
|
|
|
|
ValueType type = kWasmStmt;
|
2018-01-29 16:45:59 +00:00
|
|
|
Var() = default;
|
|
|
|
|
Var(uint32_t index, ValueType type) : index(index), type(type) {}
|
2018-01-02 18:52:49 +00:00
|
|
|
bool is_valid() const { return type != kWasmStmt; }
|
|
|
|
|
};
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
Var GetRandomLocal(DataRange* data) {
|
2018-01-02 18:52:49 +00:00
|
|
|
uint32_t num_params =
|
|
|
|
|
static_cast<uint32_t>(builder_->signature()->parameter_count());
|
|
|
|
|
uint32_t num_locals = static_cast<uint32_t>(locals_.size());
|
|
|
|
|
if (num_params + num_locals == 0) return {};
|
2019-07-08 11:44:42 +00:00
|
|
|
uint32_t index = data->get<uint8_t>() % (num_params + num_locals);
|
2018-01-02 18:52:49 +00:00
|
|
|
ValueType type = index < num_params ? builder_->signature()->GetParam(index)
|
|
|
|
|
: locals_[index - num_params];
|
|
|
|
|
return {index, type};
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void local_op(DataRange* data, WasmOpcode opcode) {
|
2018-01-29 16:45:59 +00:00
|
|
|
Var local = GetRandomLocal(data);
|
2018-01-11 12:56:19 +00:00
|
|
|
// If there are no locals and no parameters, just generate any value (if a
|
|
|
|
|
// value is needed), or do nothing.
|
|
|
|
|
if (!local.is_valid()) {
|
2020-03-12 14:29:51 +00:00
|
|
|
if (wanted_type == ValueType::kStmt) return;
|
2018-01-11 12:56:19 +00:00
|
|
|
return Generate<wanted_type>(data);
|
|
|
|
|
}
|
2018-01-02 18:52:49 +00:00
|
|
|
|
2019-10-08 12:38:48 +00:00
|
|
|
if (opcode != kExprLocalGet) Generate(local.type, data);
|
2018-01-11 12:56:19 +00:00
|
|
|
builder_->EmitWithU32V(opcode, local.index);
|
2020-03-12 14:29:51 +00:00
|
|
|
if (wanted_type != ValueType::kStmt && local.type.kind() != wanted_type) {
|
|
|
|
|
Convert(local.type, ValueType(wanted_type));
|
2018-01-11 12:56:19 +00:00
|
|
|
}
|
2018-01-02 18:52:49 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void get_local(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
static_assert(wanted_type != ValueType::kStmt, "illegal type");
|
2019-10-08 12:38:48 +00:00
|
|
|
local_op<wanted_type>(data, kExprLocalGet);
|
2018-01-11 12:56:19 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
void set_local(DataRange* data) {
|
|
|
|
|
local_op<ValueType::kStmt>(data, kExprLocalSet);
|
|
|
|
|
}
|
2018-01-02 18:52:49 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void tee_local(DataRange* data) {
|
2019-10-08 12:38:48 +00:00
|
|
|
local_op<wanted_type>(data, kExprLocalTee);
|
2018-01-02 18:52:49 +00:00
|
|
|
}
|
|
|
|
|
|
2018-11-15 15:08:32 +00:00
|
|
|
template <size_t num_bytes>
|
2019-07-08 11:44:42 +00:00
|
|
|
void i32_const(DataRange* data) {
|
|
|
|
|
builder_->EmitI32Const(data->get<int32_t, num_bytes>());
|
2018-11-15 15:08:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <size_t num_bytes>
|
2019-07-08 11:44:42 +00:00
|
|
|
void i64_const(DataRange* data) {
|
|
|
|
|
builder_->EmitI64Const(data->get<int64_t, num_bytes>());
|
2018-11-15 15:08:32 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
Var GetRandomGlobal(DataRange* data, bool ensure_mutable) {
|
2018-01-29 16:45:59 +00:00
|
|
|
uint32_t index;
|
|
|
|
|
if (ensure_mutable) {
|
|
|
|
|
if (mutable_globals_.empty()) return {};
|
2019-07-08 11:44:42 +00:00
|
|
|
index = mutable_globals_[data->get<uint8_t>() % mutable_globals_.size()];
|
2018-01-29 16:45:59 +00:00
|
|
|
} else {
|
|
|
|
|
if (globals_.empty()) return {};
|
2019-07-08 11:44:42 +00:00
|
|
|
index = data->get<uint8_t>() % globals_.size();
|
2018-01-29 16:45:59 +00:00
|
|
|
}
|
|
|
|
|
ValueType type = globals_[index];
|
|
|
|
|
return {index, type};
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void global_op(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
constexpr bool is_set = wanted_type == ValueType::kStmt;
|
2018-01-29 16:45:59 +00:00
|
|
|
Var global = GetRandomGlobal(data, is_set);
|
|
|
|
|
// If there are no globals, just generate any value (if a value is needed),
|
|
|
|
|
// or do nothing.
|
|
|
|
|
if (!global.is_valid()) {
|
2020-03-12 14:29:51 +00:00
|
|
|
if (wanted_type == ValueType::kStmt) return;
|
2018-01-29 16:45:59 +00:00
|
|
|
return Generate<wanted_type>(data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_set) Generate(global.type, data);
|
2019-10-08 13:16:30 +00:00
|
|
|
builder_->EmitWithU32V(is_set ? kExprGlobalSet : kExprGlobalGet,
|
2018-01-29 16:45:59 +00:00
|
|
|
global.index);
|
2020-03-12 14:29:51 +00:00
|
|
|
if (!is_set && global.type.kind() != wanted_type) {
|
|
|
|
|
Convert(global.type, ValueType(wanted_type));
|
2018-01-29 16:45:59 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind wanted_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void get_global(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
static_assert(wanted_type != ValueType::kStmt, "illegal type");
|
2018-01-29 16:45:59 +00:00
|
|
|
global_op<wanted_type>(data);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind select_type>
|
2019-07-08 11:44:42 +00:00
|
|
|
void select_with_type(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
static_assert(select_type != ValueType::kStmt, "illegal type for select");
|
|
|
|
|
Generate<select_type, select_type, ValueType::kI32>(data);
|
2019-05-28 10:06:42 +00:00
|
|
|
// num_types is always 1.
|
|
|
|
|
uint8_t num_types = 1;
|
|
|
|
|
builder_->EmitWithU8U8(kExprSelectWithType, num_types,
|
2020-03-12 14:29:51 +00:00
|
|
|
ValueType(select_type).value_type_code());
|
2019-05-28 10:06:42 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
void set_global(DataRange* data) { global_op<ValueType::kStmt>(data); }
|
2018-01-29 16:45:59 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind... Types>
|
2019-07-08 11:44:42 +00:00
|
|
|
void sequence(DataRange* data) {
|
2018-08-01 15:14:06 +00:00
|
|
|
Generate<Types...>(data);
|
2017-11-06 15:48:17 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void current_memory(DataRange* data) {
|
2017-11-06 15:48:17 +00:00
|
|
|
builder_->EmitWithU8(kExprMemorySize, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void grow_memory(DataRange* data);
|
2017-11-07 17:38:57 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
using GenerateFn = void (WasmGenerator::*const)(DataRange*);
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
template <size_t N>
|
2019-10-17 08:46:01 +00:00
|
|
|
void GenerateOneOf(GenerateFn (&alternatives)[N], DataRange* data) {
|
2017-11-06 15:48:17 +00:00
|
|
|
static_assert(N < std::numeric_limits<uint8_t>::max(),
|
2019-10-17 08:46:01 +00:00
|
|
|
"Too many alternatives. Use a bigger type if needed.");
|
2019-07-08 11:44:42 +00:00
|
|
|
const auto which = data->get<uint8_t>();
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateFn alternate = alternatives[which % N];
|
2017-11-06 15:48:17 +00:00
|
|
|
(this->*alternate)(data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2017-11-03 16:43:29 +00:00
|
|
|
struct GeneratorRecursionScope {
|
|
|
|
|
explicit GeneratorRecursionScope(WasmGenerator* gen) : gen(gen) {
|
|
|
|
|
++gen->recursion_depth;
|
2017-11-06 15:48:17 +00:00
|
|
|
DCHECK_LE(gen->recursion_depth, kMaxRecursionDepth);
|
2017-11-03 16:43:29 +00:00
|
|
|
}
|
|
|
|
|
~GeneratorRecursionScope() {
|
|
|
|
|
DCHECK_GT(gen->recursion_depth, 0);
|
|
|
|
|
--gen->recursion_depth;
|
|
|
|
|
}
|
|
|
|
|
WasmGenerator* gen;
|
|
|
|
|
};
|
|
|
|
|
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
public:
|
2018-01-02 18:52:49 +00:00
|
|
|
WasmGenerator(WasmFunctionBuilder* fn,
|
2018-01-29 16:45:59 +00:00
|
|
|
const std::vector<FunctionSig*>& functions,
|
|
|
|
|
const std::vector<ValueType>& globals,
|
2019-07-08 11:44:42 +00:00
|
|
|
const std::vector<uint8_t>& mutable_globals, DataRange* data)
|
2018-01-29 16:45:59 +00:00
|
|
|
: builder_(fn),
|
|
|
|
|
functions_(functions),
|
|
|
|
|
globals_(globals),
|
|
|
|
|
mutable_globals_(mutable_globals) {
|
2017-12-21 14:31:42 +00:00
|
|
|
FunctionSig* sig = fn->signature();
|
|
|
|
|
DCHECK_GE(1, sig->return_count());
|
|
|
|
|
blocks_.push_back(sig->return_count() == 0 ? kWasmStmt : sig->GetReturn(0));
|
2018-01-02 18:52:49 +00:00
|
|
|
|
|
|
|
|
constexpr uint32_t kMaxLocals = 32;
|
2019-07-08 11:44:42 +00:00
|
|
|
locals_.resize(data->get<uint8_t>() % kMaxLocals);
|
2018-01-02 18:52:49 +00:00
|
|
|
for (ValueType& local : locals_) {
|
|
|
|
|
local = GetValueType(data);
|
|
|
|
|
fn->AddLocal(local);
|
|
|
|
|
}
|
2017-11-15 11:51:15 +00:00
|
|
|
}
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void Generate(ValueType type, DataRange* data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind T>
|
2019-07-08 11:44:42 +00:00
|
|
|
void Generate(DataRange* data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
template <ValueType::Kind T1, ValueType::Kind T2, ValueType::Kind... Ts>
|
2019-07-08 11:44:42 +00:00
|
|
|
void Generate(DataRange* data) {
|
2019-09-26 08:16:50 +00:00
|
|
|
// TODO(clemensb): Implement a more even split.
|
2019-07-08 11:44:42 +00:00
|
|
|
auto first_data = data->split();
|
|
|
|
|
Generate<T1>(&first_data);
|
2017-12-21 14:30:32 +00:00
|
|
|
Generate<T2, Ts...>(data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
2017-09-01 13:20:46 +00:00
|
|
|
WasmFunctionBuilder* builder_;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
std::vector<ValueType> blocks_;
|
2017-12-21 14:31:42 +00:00
|
|
|
const std::vector<FunctionSig*>& functions_;
|
2018-01-02 18:52:49 +00:00
|
|
|
std::vector<ValueType> locals_;
|
2018-01-29 16:45:59 +00:00
|
|
|
std::vector<ValueType> globals_;
|
|
|
|
|
std::vector<uint8_t> mutable_globals_; // indexes into {globals_}.
|
2017-11-03 16:43:29 +00:00
|
|
|
uint32_t recursion_depth = 0;
|
|
|
|
|
|
|
|
|
|
static constexpr uint32_t kMaxRecursionDepth = 64;
|
|
|
|
|
|
|
|
|
|
bool recursion_limit_reached() {
|
|
|
|
|
return recursion_depth >= kMaxRecursionDepth;
|
|
|
|
|
}
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
};
|
|
|
|
|
|
2017-11-06 15:07:14 +00:00
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kStmt>(DataRange* data) {
|
2017-11-06 15:07:14 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2019-07-08 11:44:42 +00:00
|
|
|
if (recursion_limit_reached() || data->size() == 0) return;
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
constexpr GenerateFn alternatives[] = {
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kStmt,
|
|
|
|
|
ValueType::kStmt, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kStmt,
|
|
|
|
|
ValueType::kStmt, ValueType::kStmt,
|
|
|
|
|
ValueType::kStmt, ValueType::kStmt,
|
|
|
|
|
ValueType::kStmt, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::block<ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::loop<ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kStmt, kIf>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kStmt, kIfElse>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::br,
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::br_if<ValueType::kStmt>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem8, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem16, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem8, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem16, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem32, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprF32StoreMem, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::memop<kExprF64StoreMem, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32AtomicStore, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32AtomicStore8U, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32AtomicStore16U, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicStore, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicStore8U, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicStore16U, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicStore32U, ValueType::kI64>,
|
2020-03-12 23:53:38 +00:00
|
|
|
&WasmGenerator::memop<kExprS128StoreMem, ValueType::kS128>,
|
2017-12-21 13:53:15 +00:00
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
&WasmGenerator::drop,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::call<ValueType::kStmt>,
|
2018-01-11 12:56:19 +00:00
|
|
|
|
2018-01-29 16:45:59 +00:00
|
|
|
&WasmGenerator::set_local,
|
|
|
|
|
&WasmGenerator::set_global};
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateOneOf(alternatives, data);
|
2017-11-06 15:07:14 +00:00
|
|
|
}
|
|
|
|
|
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kI32>(DataRange* data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2019-07-08 11:44:42 +00:00
|
|
|
if (recursion_limit_reached() || data->size() <= 1) {
|
|
|
|
|
builder_->EmitI32Const(data->get<uint32_t>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
constexpr GenerateFn alternatives[] = {
|
2018-11-15 15:08:32 +00:00
|
|
|
&WasmGenerator::i32_const<1>,
|
|
|
|
|
&WasmGenerator::i32_const<2>,
|
|
|
|
|
&WasmGenerator::i32_const<3>,
|
|
|
|
|
&WasmGenerator::i32_const<4>,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::sequence<ValueType::kI32, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kI32,
|
|
|
|
|
ValueType::kStmt>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Eqz, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Eq, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ne, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32LtS, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32LtU, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32GeS, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32GeU, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Eqz, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Eq, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ne, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64LtS, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64LtU, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64GeS, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64GeU, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF32Eq, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Ne, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Lt, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Ge, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF64Eq, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Ne, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Lt, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Ge, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Add, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Sub, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Mul, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32DivS, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32DivU, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32RemS, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32RemU, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32And, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ior, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Xor, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Shl, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ShrU, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ShrS, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ror, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Rol, ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Clz, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ctz, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Popcnt, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32ConvertI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32SConvertF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32UConvertF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32SConvertF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32UConvertF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ReinterpretF32, ValueType::kF32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::loop<ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kI32, kIfElse>,
|
|
|
|
|
&WasmGenerator::br_if<ValueType::kI32>,
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem8S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem8U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem16S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem16U>,
|
2020-01-14 18:17:34 +00:00
|
|
|
&WasmGenerator::memop<kExprI32AtomicLoad>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32AtomicLoad8U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32AtomicLoad16U>,
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAdd, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicSub, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAnd, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicOr, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicXor, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicExchange, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicCompareExchange, ValueType::kI32,
|
|
|
|
|
ValueType::kI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAdd8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicSub8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAnd8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicOr8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicXor8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicExchange8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicCompareExchange8U,
|
|
|
|
|
ValueType::kI32, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAdd16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicSub16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicAnd16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicOr16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicXor16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicExchange16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI32AtomicCompareExchange16U,
|
|
|
|
|
ValueType::kI32, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::simd_op<kExprS1x16AnyTrue, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprS1x8AnyTrue, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprS1x4AnyTrue, ValueType::kS128>,
|
2020-02-06 18:26:29 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
&WasmGenerator::current_memory,
|
2017-12-21 14:31:42 +00:00
|
|
|
&WasmGenerator::grow_memory,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::get_local<ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::tee_local<ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::get_global<ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprSelect, ValueType::kI32, ValueType::kI32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::select_with_type<ValueType::kI32>,
|
2018-01-02 18:52:49 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::call<ValueType::kI32>};
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateOneOf(alternatives, data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kI64>(DataRange* data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2019-07-08 11:44:42 +00:00
|
|
|
if (recursion_limit_reached() || data->size() <= 1) {
|
|
|
|
|
builder_->EmitI64Const(data->get<int64_t>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
constexpr GenerateFn alternatives[] = {
|
2018-11-15 15:08:32 +00:00
|
|
|
&WasmGenerator::i64_const<1>,
|
|
|
|
|
&WasmGenerator::i64_const<2>,
|
|
|
|
|
&WasmGenerator::i64_const<3>,
|
|
|
|
|
&WasmGenerator::i64_const<4>,
|
|
|
|
|
&WasmGenerator::i64_const<5>,
|
|
|
|
|
&WasmGenerator::i64_const<6>,
|
|
|
|
|
&WasmGenerator::i64_const<7>,
|
|
|
|
|
&WasmGenerator::i64_const<8>,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::sequence<ValueType::kI64, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kI64,
|
|
|
|
|
ValueType::kStmt>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Add, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Sub, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Mul, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64DivS, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64DivU, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64RemS, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64RemU, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64And, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ior, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Xor, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Shl, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64ShrU, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64ShrS, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ror, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Rol, ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Clz, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ctz, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Popcnt, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::loop<ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kI64, kIfElse>,
|
|
|
|
|
&WasmGenerator::br_if<ValueType::kI64>,
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem8S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem8U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem16S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem16U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem32S>,
|
2017-12-21 14:31:42 +00:00
|
|
|
&WasmGenerator::memop<kExprI64LoadMem32U>,
|
2020-01-14 18:17:34 +00:00
|
|
|
&WasmGenerator::memop<kExprI64AtomicLoad>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicLoad8U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicLoad16U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64AtomicLoad32U>,
|
2017-12-21 14:31:42 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAdd, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicSub, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAnd, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicOr, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicXor, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicExchange, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicCompareExchange, ValueType::kI32,
|
|
|
|
|
ValueType::kI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAdd8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicSub8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAnd8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicOr8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicXor8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicExchange8U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicCompareExchange8U,
|
|
|
|
|
ValueType::kI32, ValueType::kI64,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAdd16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicSub16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAnd16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicOr16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicXor16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicExchange16U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicCompareExchange16U,
|
|
|
|
|
ValueType::kI32, ValueType::kI64,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAdd32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicSub32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicAnd32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicOr32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicXor32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicExchange32U, ValueType::kI32,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::atomic_op<kExprI64AtomicCompareExchange32U,
|
|
|
|
|
ValueType::kI32, ValueType::kI64,
|
|
|
|
|
ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::get_local<ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::tee_local<ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::get_global<ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprSelect, ValueType::kI64, ValueType::kI64,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::select_with_type<ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::call<ValueType::kI64>};
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateOneOf(alternatives, data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kF32>(DataRange* data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2019-07-08 11:44:42 +00:00
|
|
|
if (recursion_limit_reached() || data->size() <= sizeof(float)) {
|
|
|
|
|
builder_->EmitF32Const(data->get<float>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
constexpr GenerateFn alternatives[] = {
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::sequence<ValueType::kF32, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kF32,
|
|
|
|
|
ValueType::kStmt>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF32Abs, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Neg, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Ceil, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Floor, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Trunc, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32NearestInt, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Sqrt, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Add, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Sub, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Mul, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Div, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Min, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Max, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32CopySign, ValueType::kF32, ValueType::kF32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF32SConvertI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32UConvertI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32SConvertI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprF32UConvertI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprF32ConvertF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF32ReinterpretI32, ValueType::kI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::loop<ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kF32, kIfElse>,
|
|
|
|
|
&WasmGenerator::br_if<ValueType::kF32>,
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
&WasmGenerator::memop<kExprF32LoadMem>,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::get_local<ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::tee_local<ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::get_global<ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprSelect, ValueType::kF32, ValueType::kF32,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::select_with_type<ValueType::kF32>,
|
2018-01-02 18:52:49 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::call<ValueType::kF32>};
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateOneOf(alternatives, data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kF64>(DataRange* data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2019-07-08 11:44:42 +00:00
|
|
|
if (recursion_limit_reached() || data->size() <= sizeof(double)) {
|
|
|
|
|
builder_->EmitF64Const(data->get<double>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
constexpr GenerateFn alternatives[] = {
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::sequence<ValueType::kF64, ValueType::kStmt>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::sequence<ValueType::kStmt, ValueType::kF64,
|
|
|
|
|
ValueType::kStmt>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF64Abs, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Neg, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Ceil, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Floor, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Trunc, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64NearestInt, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Sqrt, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Add, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Sub, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Mul, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Div, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Min, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Max, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64CopySign, ValueType::kF64, ValueType::kF64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF64SConvertI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprF64UConvertI32, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::op<kExprF64SConvertI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64UConvertI64, ValueType::kI64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64ConvertF32, ValueType::kF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF64ReinterpretI64, ValueType::kI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::loop<ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::if_<ValueType::kF64, kIfElse>,
|
|
|
|
|
&WasmGenerator::br_if<ValueType::kF64>,
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
&WasmGenerator::memop<kExprF64LoadMem>,
|
|
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::get_local<ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::tee_local<ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::get_global<ValueType::kF64>,
|
|
|
|
|
&WasmGenerator::op<kExprSelect, ValueType::kF64, ValueType::kF64,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::select_with_type<ValueType::kF64>,
|
2018-01-02 18:52:49 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::call<ValueType::kF64>};
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2019-10-17 08:46:01 +00:00
|
|
|
GenerateOneOf(alternatives, data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
|
|
|
|
|
2020-02-06 18:26:29 +00:00
|
|
|
template <>
|
2020-03-12 14:29:51 +00:00
|
|
|
void WasmGenerator::Generate<ValueType::kS128>(DataRange* data) {
|
2020-02-06 18:26:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
|
|
|
|
if (recursion_limit_reached() || data->size() <= sizeof(int32_t)) {
|
|
|
|
|
// TODO(v8:8460): v128.const is not implemented yet, and we need a way to
|
|
|
|
|
// "bottom-out", so use a splat to generate this.
|
|
|
|
|
builder_->EmitI32Const(data->get<int32_t>());
|
|
|
|
|
builder_->EmitWithPrefix(kExprI8x16Splat);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
constexpr GenerateFn alternatives[] = {
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI8x16Splat, ValueType::kI32>,
|
2020-03-13 03:44:29 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI8x16Eq, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16Ne, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16LtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16LtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16GtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16GtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16LeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16LeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16GeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16GeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-17 22:17:40 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI8x16Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16Shl, ValueType::kS128, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16ShrS, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16ShrU, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16AddSaturateS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16AddSaturateU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16SubSaturateS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16SubSaturateU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16MinS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16MinU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
// I8x16Mul is prototyped but not in the proposal, thus omitted here.
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16MaxS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16MaxU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-13 03:44:29 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI16x8Splat, ValueType::kI32>,
|
2020-03-13 03:44:29 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI16x8Eq, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8Ne, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8LtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8LtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8GtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8GtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8LeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8LeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8GeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8GeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-17 22:17:40 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI16x8Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8Shl, ValueType::kS128, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8ShrS, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8ShrU, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8AddSaturateS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8AddSaturateU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8SubSaturateS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8SubSaturateU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8Mul, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8MinS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8MinU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8MaxS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8MaxU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-13 03:44:29 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI32x4Splat, ValueType::kI32>,
|
2020-03-13 03:44:29 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI32x4Eq, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4Ne, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4LtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4LtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4GtS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4GtU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4LeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4LeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4GeS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4GeU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-04-29 00:35:26 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI32x4Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4Shl, ValueType::kS128, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4ShrS, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4ShrU, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4Mul, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4MinS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4MinU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4MaxS, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4MaxU, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-13 03:44:29 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI64x2Splat, ValueType::kI64>,
|
2020-05-06 00:48:23 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI64x2Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2Shl, ValueType::kS128, ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2ShrS, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2ShrU, ValueType::kS128,
|
|
|
|
|
ValueType::kI32>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI64x2Mul, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-04-27 22:22:23 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF32x4Splat, ValueType::kF32>,
|
2020-04-27 22:22:23 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF32x4Eq, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Ne, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Lt, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Gt, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Le, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Ge, ValueType::kS128, ValueType::kS128>,
|
2020-04-30 16:48:06 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF32x4Abs, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Sqrt, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Mul, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Div, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Min, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4Max, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-04-27 22:22:23 +00:00
|
|
|
|
2020-03-12 14:29:51 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF64x2Splat, ValueType::kF64>,
|
2020-04-27 22:22:23 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF64x2Eq, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Ne, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Lt, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Gt, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Le, ValueType::kS128, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Ge, ValueType::kS128, ValueType::kS128>,
|
2020-05-05 21:50:08 +00:00
|
|
|
&WasmGenerator::simd_op<kExprF64x2Abs, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Neg, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Sqrt, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Add, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Sub, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Mul, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Div, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Min, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF64x2Max, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-03-04 22:53:37 +00:00
|
|
|
|
2020-05-08 21:08:31 +00:00
|
|
|
&WasmGenerator::simd_op<kExprI32x4SConvertF32x4, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4UConvertF32x4, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4SConvertI32x4, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprF32x4UConvertI32x4, ValueType::kS128>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16SConvertI16x8, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI8x16UConvertI16x8, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8SConvertI32x4, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8UConvertI32x4, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8SConvertI8x16Low, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8SConvertI8x16High, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8UConvertI8x16Low, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI16x8UConvertI8x16High, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4SConvertI16x8Low, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4SConvertI16x8High, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4UConvertI16x8Low, ValueType::kS128>,
|
|
|
|
|
&WasmGenerator::simd_op<kExprI32x4UConvertI16x8High, ValueType::kS128>,
|
|
|
|
|
|
2020-04-03 23:56:53 +00:00
|
|
|
&WasmGenerator::simd_shuffle,
|
2020-05-08 21:08:31 +00:00
|
|
|
&WasmGenerator::simd_op<kExprS8x16Swizzle, ValueType::kS128,
|
|
|
|
|
ValueType::kS128>,
|
2020-04-03 23:56:53 +00:00
|
|
|
|
2020-03-12 23:53:38 +00:00
|
|
|
&WasmGenerator::memop<kExprS128LoadMem>};
|
2020-02-06 18:26:29 +00:00
|
|
|
|
|
|
|
|
GenerateOneOf(alternatives, data);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void WasmGenerator::grow_memory(DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
Generate<ValueType::kI32>(data);
|
2018-10-26 17:28:37 +00:00
|
|
|
builder_->EmitWithU8(kExprMemoryGrow, 0);
|
2017-11-07 17:38:57 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
void WasmGenerator::Generate(ValueType type, DataRange* data) {
|
2020-03-12 14:29:51 +00:00
|
|
|
switch (type.kind()) {
|
|
|
|
|
case ValueType::kStmt:
|
|
|
|
|
return Generate<ValueType::kStmt>(data);
|
|
|
|
|
case ValueType::kI32:
|
|
|
|
|
return Generate<ValueType::kI32>(data);
|
|
|
|
|
case ValueType::kI64:
|
|
|
|
|
return Generate<ValueType::kI64>(data);
|
|
|
|
|
case ValueType::kF32:
|
|
|
|
|
return Generate<ValueType::kF32>(data);
|
|
|
|
|
case ValueType::kF64:
|
|
|
|
|
return Generate<ValueType::kF64>(data);
|
|
|
|
|
case ValueType::kS128:
|
|
|
|
|
return Generate<ValueType::kS128>(data);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
default:
|
|
|
|
|
UNREACHABLE();
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-12-21 14:31:42 +00:00
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
FunctionSig* GenerateSig(Zone* zone, DataRange* data) {
|
2017-12-21 14:31:42 +00:00
|
|
|
// Generate enough parameters to spill some to the stack.
|
|
|
|
|
constexpr int kMaxParameters = 15;
|
2019-07-08 11:44:42 +00:00
|
|
|
int num_params = int{data->get<uint8_t>()} % (kMaxParameters + 1);
|
|
|
|
|
bool has_return = data->get<bool>();
|
2017-12-21 14:31:42 +00:00
|
|
|
|
|
|
|
|
FunctionSig::Builder builder(zone, has_return ? 1 : 0, num_params);
|
|
|
|
|
if (has_return) builder.AddReturn(GetValueType(data));
|
|
|
|
|
for (int i = 0; i < num_params; ++i) builder.AddParam(GetValueType(data));
|
|
|
|
|
return builder.Build();
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-04 10:05:10 +00:00
|
|
|
} // namespace
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-05-08 09:22:54 +00:00
|
|
|
class WasmCompileFuzzer : public WasmExecutionFuzzer {
|
2017-09-04 10:05:10 +00:00
|
|
|
bool GenerateModule(
|
2018-07-12 09:05:43 +00:00
|
|
|
Isolate* isolate, Zone* zone, Vector<const uint8_t> data,
|
2019-07-08 11:44:42 +00:00
|
|
|
ZoneBuffer* buffer, int32_t* num_args,
|
|
|
|
|
std::unique_ptr<WasmValue[]>* interpreter_args,
|
|
|
|
|
std::unique_ptr<Handle<Object>[]>* compiler_args) override {
|
2017-05-08 09:22:54 +00:00
|
|
|
TestSignatures sigs;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-05-08 09:22:54 +00:00
|
|
|
WasmModuleBuilder builder(zone);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2018-07-12 09:05:43 +00:00
|
|
|
DataRange range(data);
|
2017-12-21 14:31:42 +00:00
|
|
|
std::vector<FunctionSig*> function_signatures;
|
|
|
|
|
function_signatures.push_back(sigs.i_iii());
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
static_assert(kMaxFunctions >= 1, "need min. 1 function");
|
|
|
|
|
int num_functions = 1 + (range.get<uint8_t>() % kMaxFunctions);
|
|
|
|
|
|
|
|
|
|
for (int i = 1; i < num_functions; ++i) {
|
2019-07-08 11:44:42 +00:00
|
|
|
function_signatures.push_back(GenerateSig(zone, &range));
|
2017-12-21 14:31:42 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-29 16:45:59 +00:00
|
|
|
int num_globals = range.get<uint8_t>() % (kMaxGlobals + 1);
|
|
|
|
|
std::vector<ValueType> globals;
|
|
|
|
|
std::vector<uint8_t> mutable_globals;
|
|
|
|
|
globals.reserve(num_globals);
|
|
|
|
|
mutable_globals.reserve(num_globals);
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < num_globals; ++i) {
|
2019-07-08 11:44:42 +00:00
|
|
|
ValueType type = GetValueType(&range);
|
2018-01-29 16:45:59 +00:00
|
|
|
// 1/8 of globals are immutable.
|
|
|
|
|
const bool mutability = (range.get<uint8_t>() % 8) != 0;
|
2019-07-11 15:02:44 +00:00
|
|
|
builder.AddGlobal(type, mutability, WasmInitExpr());
|
2018-01-29 16:45:59 +00:00
|
|
|
globals.push_back(type);
|
|
|
|
|
if (mutability) mutable_globals.push_back(static_cast<uint8_t>(i));
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-21 14:31:42 +00:00
|
|
|
for (int i = 0; i < num_functions; ++i) {
|
|
|
|
|
DataRange function_range =
|
|
|
|
|
i == num_functions - 1 ? std::move(range) : range.split();
|
|
|
|
|
|
|
|
|
|
FunctionSig* sig = function_signatures[i];
|
|
|
|
|
WasmFunctionBuilder* f = builder.AddFunction(sig);
|
|
|
|
|
|
2018-01-29 16:45:59 +00:00
|
|
|
WasmGenerator gen(f, function_signatures, globals, mutable_globals,
|
2019-07-08 11:44:42 +00:00
|
|
|
&function_range);
|
2017-12-21 14:31:42 +00:00
|
|
|
ValueType return_type =
|
|
|
|
|
sig->return_count() == 0 ? kWasmStmt : sig->GetReturn(0);
|
2019-07-08 11:44:42 +00:00
|
|
|
gen.Generate(return_type, &function_range);
|
2017-12-21 14:31:42 +00:00
|
|
|
|
|
|
|
|
f->Emit(kExprEnd);
|
|
|
|
|
if (i == 0) builder.AddExport(CStrVector("main"), f);
|
|
|
|
|
}
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-08-29 08:47:47 +00:00
|
|
|
builder.SetMaxMemorySize(32);
|
2020-01-14 18:17:34 +00:00
|
|
|
// We enable shared memory to be able to test atomics.
|
|
|
|
|
builder.SetHasSharedMemory();
|
2019-07-08 11:44:42 +00:00
|
|
|
builder.WriteTo(buffer);
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
*num_args = 3;
|
|
|
|
|
interpreter_args->reset(
|
2017-07-14 13:49:01 +00:00
|
|
|
new WasmValue[3]{WasmValue(1), WasmValue(2), WasmValue(3)});
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2019-07-08 11:44:42 +00:00
|
|
|
compiler_args->reset(new Handle<Object>[3] {
|
|
|
|
|
handle(Smi::FromInt(1), isolate), handle(Smi::FromInt(2), isolate),
|
|
|
|
|
handle(Smi::FromInt(3), isolate)
|
|
|
|
|
});
|
2017-05-08 09:22:54 +00:00
|
|
|
return true;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
2017-05-08 09:22:54 +00:00
|
|
|
};
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
|
2017-05-08 09:22:54 +00:00
|
|
|
extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
|
2017-11-08 21:03:20 +00:00
|
|
|
constexpr bool require_valid = true;
|
2019-05-29 13:30:15 +00:00
|
|
|
EXPERIMENTAL_FLAG_SCOPE(anyref);
|
2018-11-20 14:41:36 +00:00
|
|
|
WasmCompileFuzzer().FuzzWasmModule({data, size}, require_valid);
|
|
|
|
|
return 0;
|
[wasm] Syntax- and Type-aware Fuzzer
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}
2017-02-17 17:06:29 +00:00
|
|
|
}
|
2017-09-01 13:20:46 +00:00
|
|
|
|
|
|
|
|
} // namespace fuzzer
|
|
|
|
|
} // namespace wasm
|
|
|
|
|
} // namespace internal
|
|
|
|
|
} // namespace v8
|
