Changes in memory.rs

23cbbdd4 - chore: remove repetitive word in comment (#11976)

Fri, 07 Nov 2025 10:44:32 +0000

chore: remove repetitive word in comment (#11976)Signed-off-by: claudecodering List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

2951394f - Update criterion to 0.6.0 (#11202)

Tue, 08 Jul 2025 22:09:49 +0000

Update criterion to 0.6.0 (#11202)No urgent need for this, just keeping up-to-date with major versiontracks. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

7878c7cc - Remove "unaligned" memory from fuzzing (#11147)

Fri, 27 Jun 2025 16:45:54 +0000

Remove "unaligned" memory from fuzzing (#11147)This commit removes the configuration knob used during fuzzing to use acustom host memory which is always unaligned on the host. The originalintention for this was to help catch issues related to alignment in thex64 backend about, for example, performing unaligned SSE loads correctly(as opposed to accidentally faulting on unaligned addresses).As shown in the test failures of #11142, however, this is technically UBfor other parts of Wasmtime that assume the heap addresses are alwaysaligned. For example Wasmtime will create safe references in to a GCheap and GC heaps are also allocated with this same allocator, meaningthat Rust-safe references are unaligned (which is UB).In practice I'm not aware of any actual issues this configuration optionhas ever discovered, and we've otherwise discovered alignment issues vianormal fuzzing as well. Given that I think it's best to just jettisonthis entirely and stop trying to support it and/or tweak configurationto only use it when supported or similar. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

ba4e22bc - Make it easier to reuse fuzzing configuration on the CLI (#10123)

Mon, 27 Jan 2025 21:34:55 +0000

Make it easier to reuse fuzzing configuration on the CLI (#10123)* Make it easier to reuse fuzzing configuration on the CLIDuring fuzzing we emit a debug log of configured options to assist withreproducing fuzz test cases outside of the fuzzing harness. Mappingoptions the fuzzer is using though to CLI flags, for example, is a bitof an art though and not obvious. Just today we've got a fuzz bug and Icouldn't figure out how to reproduce on the CLI and it turns out theissue was that I was forgetting a flag that was being configured inresponse to another flag. I got a bit fed up with constantly trying tomap one to the other, so I've decided to fix things.This commit adds a `Display for CommonOptions` implementation to the`wasmtime-cli-flags` crate. This is built on the same macro-constructioninfrastructure of all our flags making it a relatively low one-time-costto implement this. Each option value now implements not only parsing butprinting as well.Next the `wasmtime-fuzzing` crate was updated to create a`CommonOptions` first which is then in turn used to create a`wasmtime::Config`. This provides a layer to insert a log statement withto emit all configuration options in a form that can be easilycopy/pasted to the CLI to reproduce.Overall after doing this I was able to quickly reproduce the bug inquestion (yay!). The CLI flag logging is pretty verbose right now sincethe fuzzing infrastructure sets many settings redundantly to theirdefaults, but reducing flags to a minimum is expected to be relativelyeasy compared to otherwise trying to extract the options.* Fix build and dependencies from wasmtime-fuzzing* Always provide `wasmtime::MpkEnabled`It's an otherwise very small `enum` which makes it easier toconditionally compile `wasmtime-cli-flags`* Frob some crate features some more* Fix specification of `wasmtime_linkopt_force_jump_veneer` option List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

f50d8d93 - Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)

Thu, 07 Nov 2024 19:02:58 +0000

Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)* Refactor internals of `vm::Memory`Instead of storing just a trait object store instead an `enum` between"local" memory and shared memory. This helps remove redundant traitimpls on shared memories, removes the need for `dyn Any`, and removesthe possibility of wrapping a shared memory as a shared memory. This isadditionally intended to make it a bit easier to see what's nested whereand reduce some layers of indirection.* Start implementing a `LocalMemory` abstractionThis is intended to be a non-shared implementation of a linear memorywith various bits and pieces tracking state. The end goal is to simplifythe `RuntimeLinearMemory` trait to its bare bones necessary tofaithfully implement wasm linear memory.* Move `vmmemory` to `LocalMemory`* Move CoW/max limits into `LocalMemory`Further simplify `RuntimeLinearMemory` by moving these responsibilitiesup a layer into the `LocalMemory` structure.* Simplify `memory_may_move` handling in `LocalMemory`No need to plumb it through all the traits any more. Now it's possibleto only have it handled in `LocalMemory` and other pieces don't have toworry about it.* Move `wasm_accessible` into `LocalMemory`Further simplify custom traits and mmap/static memory by moving moreresponsibility into `LocalMemory`.* Improve documentation of memories* Fix some CI failures* Handle more CI failures* More fixes for CI* Update crates/wasmtime/src/runtime/vm/memory.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

cc6cf635 - Update memory configuration during fuzzing (#9567)

Tue, 05 Nov 2024 22:27:18 +0000

Update memory configuration during fuzzing (#9567)This commit updates how the `NormalMemoryConfig` works during fuzzing.Previously this was either 0 or an arbitrary 32-bit number. This endedup not not handling cases such as 4GiB exactly which is 1 larger thanthe 32-bit range. Additionally 33+-bit numbers were never tested. Thisintends to expand our fuzz coverage here by most of the time using thedefault settings of `Config` and then otherwise selecting amongst an"interesting" set of numbers such as 0, powers of two, etc. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

7a28a5b9 - Remove static/dynamic memories from public docs (#9545)

Tue, 05 Nov 2024 01:05:58 +0000

Remove static/dynamic memories from public docs (#9545)* Remove static/dynamic memories from public docsThis commit removes the terminology of "static" and "dynamic" memoriesfrom the public-facing documentation of Wasmtime, notably on the`Config` structure and its various configuration settings. The goal ofthis commit is in the same vein as #9543 which is to simplify the memorysettings of Wasmtime for users in this case.This change doesn't actually have any code changes beyond renames (andhandling now-deprecated CLI options). The goal of this commit is tobasically rewrite how we document the effect of various settings ofWasmtime. Notably:* `Config::static_memory_maximum_size` is now `memory_reservation`.* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.* `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`.Documentation for all of these options has been rewritten and updated totake into account the removal of "dynamic" and "static" terminology.Additionally more words have been written about the various effects ofeach setting and how things related to wasm features such as index typesizes and custom page sizes.The rewritten documentation is intended to basically already match whatWasmtime does today. I believe that all of these settings are useful inone form or another so none have been dropped but the updateddocumentation is intended to help simplify the mental model for howthey're processed internally and how they affect allocations and such.* Fix how the setting is flipped* Review comments List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

48d5338b - Merge static/dynamic guard size options (#9528)

Fri, 01 Nov 2024 17:21:11 +0000

Merge static/dynamic guard size options (#9528)* Merge static/dynamic guard size optionsThis commit is the first of what will likely be a few to refactor thememory-related configuration options in Wasmtime. The end goal of theserefactorings is to fix some preexisting issues and additionally make theconfiguration easier to understand for both users and implementorsalike. First on the chopping block here is to merge the`dynamic_memory_guard_size` and `static_memory_guard_size` options intoone option. AFAIK there's not a strong reason to have separateconfiguration options for these so it's hopefully simpler to have asingle `memory_guard_size` option which applies to all linear memoriesequally.I'll note that the old CLI options are preserved but are documented asdeprecated. We don't currently warn on using "deprecated options" so fornow the old options are just documented as deprecated and are otherwisesilently accepted.* Fix compilation of C API* Fix build of fuzzers List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

bdd78422 - Wasmtime: Implement the custom-page-sizes proposal (#8763)

Wed, 12 Jun 2024 21:46:42 +0000

Wasmtime: Implement the custom-page-sizes proposal (#8763)* Wasmtime: Implement the custom-page-sizes proposalThis commit adds support for the custom-page-sizes proposal to Wasmtime:https://github.com/WebAssembly/custom-page-sizesI've migrated, fixed some bugs within, and extended the `*.wast` tests for thisproposal from the `wasm-tools` repository. I intend to upstream them into theproposal shortly.There is a new `wasmtime::Config::wasm_custom_page_sizes_proposal` method toenable or disable the proposal. It is disabled by default.Our fuzzing config has been updated to turn this feature on/off as dictated bythe arbitrary input given to us from the fuzzer.Additionally, there were getting to be so many constructors for`wasmtime::MemoryType` that I added a builder rather than add yet anotherconstructor.In general, we store the `log2(page_size)` rather than the page sizedirectly. This helps cut down on invalid states and properties we need toassert.I've also intentionally written this code such that supporting any power of twopage size (rather than just the exact values `1` and `65536` that are currentlyvalid) will essentially just involve updating `wasmparser`'s validation andremoving some debug asserts in Wasmtime.* Update error string expectation* Remove debug logging* Use a right shift instead of a division* fix error message expectation again* remove page size from VMMemoryDefinition* fix size of VMMemoryDefinition again* Only dynamically check for `-1` sentinel for 1-byte page sizes* Import functions that are used a few times* Better handle overflows when rounding up to the host page sizePropagate errors instead of returning a value that is not actually a rounded upversion of the input.Delay rounding up various config sizes until runtime instead of eagerly doing itat config time (which isn't even guaranteed to work, so we already had to have abackup plan to round up at runtime, since we might be cross-compiling wasm ornot have the runtime feature enabled).* Fix some anyhow and nostd errors* Add missing rounding up to host page size at runtime* Add validate feature to wasmparser dep* Add some new rounding in a few places, due to no longer rounding in config methods* Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` testThe point of the test is to ensure that we hit the limiter, so just cancel theallocation from the limiter, and otherwise avoid MIRI attempting to allocate abunch of memory after we hit the limiter.* prtest:full* Revert "Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` test"This reverts commit ccfa34a78dd3d53e49a6158ca03077d42ce8bcd7.* miri: don't attempt to allocate more than 4GiB of memoryIt seems that rather than returning a null pointer from `std::alloc::alloc`,miri will sometimes choose to simply crash the whole program.* remove duplicate prelude import after rebasing List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

bd4cfd7e - Dynamically configure Spectre heap mitigations on/off in fuzzing (#8775)

Tue, 11 Jun 2024 19:09:21 +0000

Dynamically configure Spectre heap mitigations on/off in fuzzing (#8775)We have slightly different bounds checks for when Spectre mitigations areenabled or disabled, so add a knob to our fuzzing machinery to exercise allcases. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

7a37e313 - Add a fuzz target for exercising bounds checks with various memory configs (#8742)

Thu, 06 Jun 2024 13:47:19 +0000

Add a fuzz target for exercising bounds checks with various memory configs (#8742) List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

28371bfd - Validate faulting addresses are valid to fault on (#6028)

Fri, 17 Mar 2023 14:52:54 +0000

Validate faulting addresses are valid to fault on (#6028)* Validate faulting addresses are valid to fault onThis commit adds a defense-in-depth measure to Wasmtime which isintended to mitigate the impact of CVEs such as GHSA-ff4p-7xrq-q5r8.Currently Wasmtime will catch `SIGSEGV` signals for WebAssembly code solong as the instruction which faulted is an allow-listed instruction(aka has a trap code listed for it). With the recent security issue,however, the problem was that a wasm guest could exploit a compiler bugto access memory outside of its sandbox. If the access was successfulthere's no real way to detect that, but if the access was unsuccessfulthen Wasmtime would happily swallow the `SIGSEGV` and report a nominaltrap. To embedders, this might look like nothing is going awry.The new strategy implemented here in this commit is to attempt to bemore robust towards these sorts of failures. When a `SIGSEGV` is raisedthe faulting pc is recorded but additionally the address of theinaccessible location is also record. After the WebAssembly stack isunwound and control returns to Wasmtime which has access to a `Store`Wasmtime will now use this inaccessible faulting address to translate itto a wasm address. This process should be guaranteed to succeed asWebAssembly should only be able to access a well-defined region ofmemory for all linear memories in a `Store`.If no linear memory in a `Store` could contain the faulting address,then Wasmtime now prints a scary message and aborts the process. Thepurpose of this is to catch these sorts of bugs, make them very louderrors, and hopefully mitigate impact. This would continue to notmitigate the impact of a guest successfully loading data outside of itssandbox, but if a guest was doing a sort of probing strategy trying tofind valid addresses then any invalid access would turn into a processcrash which would immediately be noticed by embedders.While I was here I went ahead and additionally took a stab at #3120.Traps due to `SIGSEGV` will now report the size of linear memory and theaddress that was being accessed in addition to the bland "access out ofbounds" error. While this is still somewhat bland in the context of ahigh level source language it's hopefully at least a little bit moreactionable for some. I'll note though that this isn't a guaranteedcontextual message since only the default configuration for Wasmtimegenerates `SIGSEGV` on out-of-bounds memory accesses. Dynamicallybounds-checked configurations, for example, don't do this.Testing-wise I unfortunately am not aware of a great way to test this.The closet equivalent would be something like an `unsafe` method`Config::allow_wasm_sandbox_escape`. In lieu of adding tests, though, Ican confirm that during development the crashing messages works justfine as it took awhile on macOS to figure out where the faulting addresswas recorded in the exception information which meant I had lots ofinstances of recording an address of a trap not accessible from wasm.* Fix tests* Review comments* Fix compile after refactor* Fix compile on macOS* Fix trap test for s390xs390x rounds faulting addresses to 4k boundaries. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs

c227063f - fuzz: refactor fuzz generators (#4404)

Thu, 07 Jul 2022 18:44:27 +0000

fuzz: refactor fuzz generators (#4404)Previously, much of the logic for generating the various objects needed for fuzzing was concentrated primarily in `generators.rs`. In trying to piece together what code does what, the size of the file and the light documentation make it hard to discern what each part does. Since several generator structures had been split out as separate modules in the `generators/` directory, this change takes that refactoring further by moving the structures in `generators.rs` to their own modules. No logic changes were made, only the addition of documentation in a few places. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/memory.rs