en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#93d22fcd Migrate fuzzing to `wasmtime::error` (#12263)* Migrate fuzzing to `wasmtime::error`* fix List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Wed, 07 Jan 2026 21:51:23 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#43ebcb89 Remove usage of `gen` as an identifier (#9958)This commit is a start to some preparation for the Rust 2024 edition forWasmtime and this workspace. The `rust-2024-compatibility` lint group inrustc, currently off-by-default, is intended to assist with migratingcode to prepare for the 2024 edition. Some of those lints though are, inmy opinion, far too noisy to be turned on so this PR doesn't turn on thewhole group. Instead though I plan on enabling individual lints overtime in our `Cargo.toml` before the 2024 edition is enabled. This shouldhopefully provide a relatively smooth and less churn-y path to enablingthe 2024 edition in the future.The first lint enabled here in this commit is the `keyword_idents_2024`lint which warns against usage of identifiers that will become keywordsin the 2024 edition. The only one affecting Wasmtime is the `gen`identifier (soon to be keyword) and we had quite a few instances of it.Where possible I've renamed to `generator` or `generate` or `generated`but when used as methods from upstream crate traits (e.g.`RngCore::gen`) we're forced to use `r#gen`. The `rand` crate will beupdated in 0.9.0 to avoid this keyword so this shouldn't be permanent. List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Thu, 09 Jan 2025 16:47:51 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#6844ed1a Update wasm-tools crates (#9336)* Update wasm-tools crates* WIT `float32` and `float64` are now hard errors (renamed to `f32` and `f64`)* Stack switching has been implemented in wasm-tools, but not Wasmtime.* New shared-everything-threads component model intrinsics are not implemented"Holes" for these new features in wasmparser are now present in Wasmtimeand panics shouldn't be hit because the new proposals aren't enabled inthe validator at this time.* Fix fuzzer build* Fix fuzzer tests List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Mon, 30 Sep 2024 19:35:24 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#04c03b31 Update the wasm-tools family of crates (#7921)* Update the wasm-tools family of cratesPulling in some updates to improve how WIT is managed in thisrepository. No changes just yet, however, just pulling in the updatesfirst.* Fix tests* Fix fuzzer build List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Mon, 12 Feb 2024 23:22:16 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#b0be673a Update core dump generation in the cli to use wasm-encoder (#6306)* Update coredump generation in the cli to use wasm_encoder* Add deny.toml exception for wasm-encoder 0.25.0* add missing newline* update custom section in fuzzing crate List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Wed, 10 May 2023 20:53:45 +0000 Rainy Sinclair <844493+itsrainy@users.noreply.github.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs#42f8ab14 Improve longevity for fuzzing corpus of wasm modules (#6322)* Improve longevity for fuzzing corpus of wasm modulesThis commit is an improvement to the longevity of Wasmtime's corpus offuzz inputs to the `instantiate` fuzzer. Currently the input to thisfuzzers is arbitrary binary data which is a "DNA" of sorts of what todo. This DNA changes over time as we update the fuzzer and addconfiguration options, for example. When this happens though themeaning of all existing inputs in the corpus changes because they allhave slightly different meanings now. The goal of this commit is toimprove the usefulness of a historical corpus, with respect to theWebAssembly modules generated, across changes to the DNA.A custom mutator is now provided for the `instantiate` fuzzer. Thismutator will not only perform libfuzzer's default mutation for the inputbut will additionally place an "envelope" around the fuzz input. Namely,the fuzz input is encoded as a valid WebAssembly module where the actualinput to the fuzzer is a trailing custom section. When the fuzzer runsover this input it will read the custom section, perform anyconfiguration generation necessary, and then use the envelope module asthe actual input to the fuzzer instead of whatever was generated fromthe fuzz input. This means that when a future update is made to the DNAof a module the interpretation of the fuzz input section will change butthe module in question will not change. This means that any interestingshapes of modules with respect to instructions should be preserved overtime 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 strategybut it relies much more strictly on being able to produce a module withproperties like NaN canonicalization, resource limits, fuel to limitexecution, 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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/single_module_fuzzer.rs Tue, 02 May 2023 19:24:03 +0000 Alex Crichton <alex@alexcrichton.com>