[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"
|
|
|
|
|
#include "src/isolate.h"
|
|
|
|
|
#include "src/objects-inl.h"
|
|
|
|
|
#include "src/objects.h"
|
|
|
|
|
#include "src/ostreams.h"
|
|
|
|
|
#include "src/wasm/wasm-interpreter.h"
|
|
|
|
|
#include "src/wasm/wasm-module-builder.h"
|
|
|
|
|
#include "src/wasm/wasm-module.h"
|
|
|
|
|
#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
|
|
|
|
|
|
|
|
typedef uint8_t byte;
|
|
|
|
|
|
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 {
|
|
|
|
|
|
|
|
|
|
class DataRange {
|
|
|
|
|
const uint8_t* data_;
|
|
|
|
|
size_t size_;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
DataRange(const uint8_t* data, size_t size) : data_(data), size_(size) {}
|
|
|
|
|
|
|
|
|
|
size_t size() const { return size_; }
|
|
|
|
|
|
|
|
|
|
std::pair<DataRange, DataRange> split(uint32_t index) const {
|
|
|
|
|
return std::make_pair(DataRange(data_, index),
|
|
|
|
|
DataRange(data_ + index, size() - index));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::pair<DataRange, DataRange> split() {
|
|
|
|
|
uint16_t index = get<uint16_t>();
|
|
|
|
|
if (size() > 0) {
|
|
|
|
|
index = index % size();
|
|
|
|
|
} else {
|
|
|
|
|
index = 0;
|
|
|
|
|
}
|
|
|
|
|
return split(index);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
|
T get() {
|
|
|
|
|
if (size() == 0) {
|
|
|
|
|
return T();
|
|
|
|
|
} else {
|
2017-03-01 16:50:04 +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.
|
[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
|
|
|
const size_t num_bytes = std::min(sizeof(T), size());
|
2017-03-01 16:50:04 +00:00
|
|
|
T result = T();
|
2017-02-20 11:06:50 +00:00
|
|
|
memcpy(&result, data_, num_bytes);
|
[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
|
|
|
data_ += num_bytes;
|
|
|
|
|
size_ -= num_bytes;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class WasmGenerator {
|
|
|
|
|
template <WasmOpcode Op, ValueType... Args>
|
2017-11-06 15:48:17 +00:00
|
|
|
void op(DataRange data) {
|
|
|
|
|
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);
|
|
|
|
|
gen->builder_->EmitWithU8(block_type,
|
|
|
|
|
WasmOpcodes::ValueTypeCodeFor(result_type));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
~BlockScope() {
|
|
|
|
|
gen_->builder_->Emit(kExprEnd);
|
|
|
|
|
gen_->blocks_.pop_back();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
WasmGenerator* const 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
|
|
|
template <ValueType T>
|
2017-11-06 15:48:17 +00:00
|
|
|
void block(DataRange data) {
|
2017-11-15 11:51:15 +00:00
|
|
|
BlockScope block_scope(this, kExprBlock, T, 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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <ValueType T>
|
2017-11-15 11:51:15 +00:00
|
|
|
void loop(DataRange data) {
|
|
|
|
|
// When breaking to a loop header, don't provide any input value (hence
|
|
|
|
|
// kWasmStmt).
|
|
|
|
|
BlockScope block_scope(this, kExprLoop, T, kWasmStmt);
|
|
|
|
|
Generate<T>(data);
|
|
|
|
|
}
|
2017-11-06 15:48:17 +00:00
|
|
|
|
2017-11-15 11:51:15 +00:00
|
|
|
void br(DataRange data) {
|
|
|
|
|
// There is always at least the block representing the function body.
|
|
|
|
|
DCHECK(!blocks_.empty());
|
2017-11-06 15:48:17 +00:00
|
|
|
const uint32_t target_block = data.get<uint32_t>() % blocks_.size();
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
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) {
|
|
|
|
|
case kExprI64LoadMem:
|
|
|
|
|
case kExprF64LoadMem:
|
|
|
|
|
case kExprI64StoreMem:
|
|
|
|
|
case kExprF64StoreMem:
|
|
|
|
|
return 3;
|
|
|
|
|
case kExprI32LoadMem:
|
|
|
|
|
case kExprI64LoadMem32S:
|
|
|
|
|
case kExprI64LoadMem32U:
|
|
|
|
|
case kExprF32LoadMem:
|
|
|
|
|
case kExprI32StoreMem:
|
|
|
|
|
case kExprI64StoreMem32:
|
|
|
|
|
case kExprF32StoreMem:
|
|
|
|
|
return 2;
|
|
|
|
|
case kExprI32LoadMem16S:
|
|
|
|
|
case kExprI32LoadMem16U:
|
|
|
|
|
case kExprI64LoadMem16S:
|
|
|
|
|
case kExprI64LoadMem16U:
|
|
|
|
|
case kExprI32StoreMem16:
|
|
|
|
|
case kExprI64StoreMem16:
|
|
|
|
|
return 1;
|
|
|
|
|
case kExprI32LoadMem8S:
|
|
|
|
|
case kExprI32LoadMem8U:
|
|
|
|
|
case kExprI64LoadMem8S:
|
|
|
|
|
case kExprI64LoadMem8U:
|
|
|
|
|
case kExprI32StoreMem8:
|
|
|
|
|
case kExprI64StoreMem8:
|
|
|
|
|
return 0;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-08 10:25:14 +00:00
|
|
|
template <WasmOpcode memory_op, ValueType... arg_types>
|
2017-11-06 15:48:17 +00:00
|
|
|
void memop(DataRange data) {
|
2017-11-08 21:03:20 +00:00
|
|
|
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.
|
|
|
|
|
Generate<kWasmI32, arg_types...>(data);
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
builder_->Emit(memory_op);
|
|
|
|
|
builder_->EmitU32V(align);
|
|
|
|
|
builder_->EmitU32V(offset);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <ValueType T1, ValueType T2>
|
|
|
|
|
void sequence(DataRange data) {
|
2017-11-08 10:25:14 +00:00
|
|
|
Generate<T1, T2>(data);
|
2017-11-06 15:48:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void current_memory(DataRange data) {
|
|
|
|
|
builder_->EmitWithU8(kExprMemorySize, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-07 17:38:57 +00:00
|
|
|
void grow_memory(DataRange data);
|
|
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
using generate_fn = void (WasmGenerator::*const)(DataRange);
|
|
|
|
|
|
|
|
|
|
template <size_t N>
|
|
|
|
|
void GenerateOneOf(generate_fn (&alternates)[N], DataRange data) {
|
|
|
|
|
static_assert(N < std::numeric_limits<uint8_t>::max(),
|
|
|
|
|
"Too many alternates. Replace with a bigger type if needed.");
|
|
|
|
|
const auto which = data.get<uint8_t>();
|
|
|
|
|
|
|
|
|
|
generate_fn alternate = alternates[which % N];
|
|
|
|
|
(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:
|
2017-11-15 11:51:15 +00:00
|
|
|
explicit WasmGenerator(WasmFunctionBuilder* fn) : builder_(fn) {
|
|
|
|
|
DCHECK_EQ(1, fn->signature()->return_count());
|
|
|
|
|
blocks_.push_back(fn->signature()->GetReturn(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
|
|
|
|
|
|
|
|
void Generate(ValueType type, DataRange data);
|
|
|
|
|
|
|
|
|
|
template <ValueType T>
|
|
|
|
|
void Generate(DataRange data);
|
|
|
|
|
|
|
|
|
|
template <ValueType T1, ValueType T2, ValueType... Ts>
|
|
|
|
|
void Generate(DataRange data) {
|
|
|
|
|
const auto parts = data.split();
|
|
|
|
|
Generate<T1>(parts.first);
|
|
|
|
|
Generate<T2, Ts...>(parts.second);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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-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 <>
|
|
|
|
|
void WasmGenerator::Generate<kWasmStmt>(DataRange data) {
|
|
|
|
|
GeneratorRecursionScope rec_scope(this);
|
2017-11-06 15:48:17 +00:00
|
|
|
if (recursion_limit_reached() || data.size() == 0) return;
|
|
|
|
|
|
|
|
|
|
constexpr generate_fn alternates[] = {
|
|
|
|
|
&WasmGenerator::block<kWasmStmt>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::loop<kWasmStmt>,
|
|
|
|
|
&WasmGenerator::br,
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem, kWasmI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem8, kWasmI32>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32StoreMem16, kWasmI32>,
|
2017-11-08 23:03:41 +00:00
|
|
|
&WasmGenerator::memop<kExprI64StoreMem, kWasmI64>,
|
2017-11-06 15:48:17 +00:00
|
|
|
&WasmGenerator::memop<kExprI64StoreMem8, kWasmI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem16, kWasmI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64StoreMem32, kWasmI64>,
|
|
|
|
|
&WasmGenerator::memop<kExprF32StoreMem, kWasmF32>,
|
|
|
|
|
&WasmGenerator::memop<kExprF64StoreMem, kWasmF64>,
|
|
|
|
|
};
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
GenerateOneOf(alternates, 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 <>
|
|
|
|
|
void WasmGenerator::Generate<kWasmI32>(DataRange data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
|
|
|
|
if (recursion_limit_reached() || data.size() <= sizeof(uint32_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
|
|
|
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
|
|
|
|
|
|
|
|
constexpr generate_fn alternates[] = {
|
|
|
|
|
&WasmGenerator::sequence<kWasmStmt, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Eqz, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Eq, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ne, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32LtS, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32LtU, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32GeS, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32GeU, kWasmI32, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Eqz, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Eq, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ne, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64LtS, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64LtU, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64GeS, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64GeU, kWasmI64, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF32Eq, kWasmF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Ne, kWasmF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Lt, kWasmF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Ge, kWasmF32, kWasmF32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprF64Eq, kWasmF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Ne, kWasmF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Lt, kWasmF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Ge, kWasmF64, kWasmF64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Add, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Sub, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Mul, kWasmI32, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32DivS, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32DivU, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32RemS, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32RemU, kWasmI32, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32And, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ior, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Xor, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Shl, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ShrU, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ShrS, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ror, kWasmI32, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Rol, kWasmI32, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32Clz, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Ctz, kWasmI32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32Popcnt, kWasmI32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI32ConvertI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32SConvertF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32UConvertF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprI32SConvertF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32UConvertF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprI32ReinterpretF32, kWasmF32>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<kWasmI32>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::loop<kWasmI32>,
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem8S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem8U>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem16S>,
|
|
|
|
|
&WasmGenerator::memop<kExprI32LoadMem16U>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::current_memory,
|
2017-11-07 17:38:57 +00:00
|
|
|
&WasmGenerator::grow_memory};
|
2017-11-06 15:48:17 +00:00
|
|
|
|
|
|
|
|
GenerateOneOf(alternates, 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 <>
|
|
|
|
|
void WasmGenerator::Generate<kWasmI64>(DataRange data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
|
|
|
|
if (recursion_limit_reached() || data.size() <= sizeof(uint64_t)) {
|
2017-04-25 10:45:46 +00:00
|
|
|
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
|
|
|
|
|
|
|
|
constexpr generate_fn alternates[] = {
|
|
|
|
|
&WasmGenerator::sequence<kWasmStmt, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Add, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Sub, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Mul, kWasmI64, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64DivS, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64DivU, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64RemS, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64RemU, kWasmI64, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64And, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ior, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Xor, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Shl, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64ShrU, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64ShrS, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ror, kWasmI64, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Rol, kWasmI64, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::op<kExprI64Clz, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Ctz, kWasmI64>,
|
|
|
|
|
&WasmGenerator::op<kExprI64Popcnt, kWasmI64>,
|
|
|
|
|
|
|
|
|
|
&WasmGenerator::block<kWasmI64>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::loop<kWasmI64>,
|
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>,
|
|
|
|
|
&WasmGenerator::memop<kExprI64LoadMem32U>};
|
|
|
|
|
|
|
|
|
|
GenerateOneOf(alternates, 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 <>
|
|
|
|
|
void WasmGenerator::Generate<kWasmF32>(DataRange data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
|
|
|
|
if (recursion_limit_reached() || data.size() <= sizeof(float)) {
|
2017-04-25 10:45:46 +00:00
|
|
|
builder_->EmitF32Const(data.get<float>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
constexpr generate_fn alternates[] = {
|
|
|
|
|
&WasmGenerator::sequence<kWasmStmt, kWasmF32>,
|
[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
|
|
|
&WasmGenerator::op<kExprF32Add, kWasmF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Sub, kWasmF32, kWasmF32>,
|
|
|
|
|
&WasmGenerator::op<kExprF32Mul, kWasmF32, kWasmF32>,
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
&WasmGenerator::block<kWasmF32>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::loop<kWasmF32>,
|
[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
|
|
|
&WasmGenerator::memop<kExprF32LoadMem>};
|
[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
|
|
|
GenerateOneOf(alternates, 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 <>
|
|
|
|
|
void WasmGenerator::Generate<kWasmF64>(DataRange data) {
|
2017-11-03 16:43:29 +00:00
|
|
|
GeneratorRecursionScope rec_scope(this);
|
|
|
|
|
if (recursion_limit_reached() || data.size() <= sizeof(double)) {
|
2017-04-25 10:45:46 +00:00
|
|
|
builder_->EmitF64Const(data.get<double>());
|
2017-11-06 15:48:17 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
constexpr generate_fn alternates[] = {
|
|
|
|
|
&WasmGenerator::sequence<kWasmStmt, kWasmF64>,
|
[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
|
|
|
&WasmGenerator::op<kExprF64Add, kWasmF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Sub, kWasmF64, kWasmF64>,
|
|
|
|
|
&WasmGenerator::op<kExprF64Mul, kWasmF64, kWasmF64>,
|
2017-11-06 15:07:14 +00:00
|
|
|
|
2017-11-06 15:48:17 +00:00
|
|
|
&WasmGenerator::block<kWasmF64>,
|
2017-11-15 11:51:15 +00:00
|
|
|
&WasmGenerator::loop<kWasmF64>,
|
[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
|
|
|
&WasmGenerator::memop<kExprF64LoadMem>};
|
[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
|
|
|
GenerateOneOf(alternates, 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-07 17:38:57 +00:00
|
|
|
void WasmGenerator::grow_memory(DataRange data) {
|
|
|
|
|
Generate<kWasmI32>(data);
|
|
|
|
|
builder_->EmitWithU8(kExprGrowMemory, 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
|
|
|
void WasmGenerator::Generate(ValueType type, DataRange data) {
|
|
|
|
|
switch (type) {
|
2017-11-06 15:07:14 +00:00
|
|
|
case kWasmStmt:
|
|
|
|
|
return Generate<kWasmStmt>(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
|
|
|
case kWasmI32:
|
|
|
|
|
return Generate<kWasmI32>(data);
|
|
|
|
|
case kWasmI64:
|
|
|
|
|
return Generate<kWasmI64>(data);
|
|
|
|
|
case kWasmF32:
|
|
|
|
|
return Generate<kWasmF32>(data);
|
|
|
|
|
case kWasmF64:
|
|
|
|
|
return Generate<kWasmF64>(data);
|
|
|
|
|
default:
|
|
|
|
|
UNREACHABLE();
|
|
|
|
|
}
|
|
|
|
|
}
|
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(
|
2017-05-08 09:22:54 +00:00
|
|
|
Isolate* isolate, Zone* zone, const uint8_t* data, size_t size,
|
|
|
|
|
ZoneBuffer& buffer, int32_t& num_args,
|
2017-07-14 13:49:01 +00:00
|
|
|
std::unique_ptr<WasmValue[]>& interpreter_args,
|
2017-05-08 09:22:54 +00:00
|
|
|
std::unique_ptr<Handle<Object>[]>& compiler_args) override {
|
|
|
|
|
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
|
|
|
|
2017-09-01 13:20:46 +00:00
|
|
|
WasmFunctionBuilder* f = builder.AddFunction(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-05-08 09:22:54 +00:00
|
|
|
WasmGenerator gen(f);
|
|
|
|
|
gen.Generate<kWasmI32>(DataRange(data, static_cast<uint32_t>(size)));
|
[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
|
|
|
f->Emit(kExprEnd);
|
2017-09-01 13:20:46 +00:00
|
|
|
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);
|
2017-05-08 09:22:54 +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
|
|
|
|
2017-05-08 09:22:54 +00:00
|
|
|
num_args = 3;
|
2017-07-14 13:49:01 +00:00
|
|
|
interpreter_args.reset(
|
|
|
|
|
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
|
|
|
|
2017-05-08 09:22:54 +00:00
|
|
|
compiler_args.reset(new Handle<Object>[3]{
|
|
|
|
|
handle(Smi::FromInt(1), isolate), handle(Smi::FromInt(1), isolate),
|
|
|
|
|
handle(Smi::FromInt(1), isolate)});
|
|
|
|
|
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;
|
|
|
|
|
return WasmCompileFuzzer().FuzzWasmModule(data, size, require_valid);
|
[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
|
