cranelift

rust jit wasm webassembly runtime wasi cranelift sandbox wasmtime

Alex Crichton 42f8ab1493 Improve longevity for fuzzing corpus of wasm modules (#6322 ) * Improve longevity for fuzzing corpus of wasm modules This commit is an improvement to the longevity of Wasmtime's corpus of fuzz inputs to the `instantiate` fuzzer. Currently the input to this fuzzers is arbitrary binary data which is a "DNA" of sorts of what to do. This DNA changes over time as we update the fuzzer and add configuration options, for example. When this happens though the meaning of all existing inputs in the corpus changes because they all have slightly different meanings now. The goal of this commit is to improve the usefulness of a historical corpus, with respect to the WebAssembly modules generated, across changes to the DNA. A custom mutator is now provided for the `instantiate` fuzzer. This mutator will not only perform libfuzzer's default mutation for the input but will additionally place an "envelope" around the fuzz input. Namely, the fuzz input is encoded as a valid WebAssembly module where the actual input to the fuzzer is a trailing custom section. When the fuzzer runs over this input it will read the custom section, perform any configuration generation necessary, and then use the envelope module as the actual input to the fuzzer instead of whatever was generated from the fuzz input. This means that when a future update is made to the DNA of a module the interpretation of the fuzz input section will change but the module in question will not change. This means that any interesting shapes of modules with respect to instructions should be preserved over time in theory. Some consequences of this strategy, however, are: * If the DNA changes then it's difficult to produce minor mutations of the original module. This is because mutations generate a module based on the new DNA which is likely much different than the preexisting module. This mainly just means that libFuzzer will have to rediscover how to mutate up into interesting shapes on DNA changes but it'll still be able to retain all the existing interesting modules. Additionally this can be mitigate with the integration of `wasm-mutate` perhaps into these fuzzers as well. * Protection is necessary against libFuzzer itself with respect to the module. The existing fuzzers only expect valid modules to be created, but libFuzzer can now create mutations which leave the trailing section in place, meaning the module is no longer valid. One option is to record a cryptographic hash in the fuzz input section of the previous module, only using the module if the hashes match. This approach will not work over time in the face of binary format changes, however. For example the multi-memory proposal changed binary encodings a year or so ago meaning that any previous fuzz-generated cases would no longer be guaranteed to be valid. The strategy settled by this PR is to pass a flag to the execution function indicating if the module is "known valid" and gracefully handle error if it isn't (for example if it's a prior test case). I'll note that this new strategy of fuzzing is not applied to the `differential` fuzzer. This could theoretically use the same strategy but it relies much more strictly on being able to produce a module with properties like NaN canonicalization, resource limits, fuel to limit execution, etc. While it may be possible to integrate this with `differential` in the future I figured it'd be better to start with the `instantiate` fuzzer and go from there. * Fix doc build		2 years ago
..
fuzz_targets	Upgrade wasm-tools crates, namely the component model (#4715)	2 years ago
.gitignore	Implement variant translation in fused adapters (#4534)	2 years ago
Cargo.toml	Improve longevity for fuzzing corpus of wasm modules (#6322)	2 years ago