chore: remove repetitive word in comment (#11976)

Signed-off-by: claudecodering <[email protected]>

Update criterion to 0.6.0 (#11202)

No urgent need for this, just keeping up-to-date with major version
tracks.

Remove "unaligned" memory from fuzzing (#11147)

This commit removes the configuration knob used during fuzzing to use a
custom host memory which is always unaligned on the host. The original
intenti

Remove "unaligned" memory from fuzzing (#11147)

This commit removes the configuration knob used during fuzzing to use a
custom host memory which is always unaligned on the host. The original
intention for this was to help catch issues related to alignment in the
x64 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 UB
for other parts of Wasmtime that assume the heap addresses are always
aligned. For example Wasmtime will create safe references in to a GC
heap and GC heaps are also allocated with this same allocator, meaning
that Rust-safe references are unaligned (which is UB).

In practice I'm not aware of any actual issues this configuration option
has ever discovered, and we've otherwise discovered alignment issues via
normal fuzzing as well. Given that I think it's best to just jettison
this entirely and stop trying to support it and/or tweak configuration
to only use it when supported or similar.

show more ...

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

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with

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

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with
reproducing fuzz test cases outside of the fuzzing harness. Mapping
options the fuzzer is using though to CLI flags, for example, is a bit
of an art though and not obvious. Just today we've got a fuzz bug and I
couldn't figure out how to reproduce on the CLI and it turns out the
issue was that I was forgetting a flag that was being configured in
response to another flag. I got a bit fed up with constantly trying to
map 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-construction
infrastructure of all our flags making it a relatively low one-time-cost
to implement this. Each option value now implements not only parsing but
printing 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 with
to emit all configuration options in a form that can be easily
copy/pasted to the CLI to reproduce.

Overall after doing this I was able to quickly reproduce the bug in
question (yay!). The CLI flag logging is pretty verbose right now since
the fuzzing infrastructure sets many settings redundantly to their
defaults, but reducing flags to a minimum is expected to be relatively
easy 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 to
conditionally compile `wasmtime-cli-flags`

* Frob some crate features some more

* Fix specification of `wasmtime_linkopt_force_jump_veneer` option

show more ...

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

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 will
silence a lint but will itself cause a lint if it doesn't actually
silence anything. This is quite useful to ensure that annotations don't
get stale over time.

Another feature is the ability to use a `reason` directive on the
attribute with a string explaining why the attribute is there. This
string is then rendered in compiler messages if a warning or error
happens.

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 fires
but is expected. The `#[allow(..., reason = "...")]` lint should be used
for conditionally firing lints, primarily in macro-related code.
The `allow_attributes_without_reason = 'warn'` level is intended to be
permanent but the transitionary
`#[expect(clippy::allow_attributes_without_reason)]` crate annotations
to go away over time.

* Fix adapter build

prtest:full

* Fix one-core build of icache coherence

* Use `allow` for missing_docs

Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't
fixed for our MSRV at this time.

* More MSRV compat

show more ...

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` betwee

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 trait
impls on shared memories, removes the need for `dyn Any`, and removes
the possibility of wrapping a shared memory as a shared memory. This is
additionally intended to make it a bit easier to see what's nested where
and reduce some layers of indirection.

* Start implementing a `LocalMemory` abstraction

This is intended to be a non-shared implementation of a linear memory
with various bits and pieces tracking state. The end goal is to simplify
the `RuntimeLinearMemory` trait to its bare bones necessary to
faithfully implement wasm linear memory.

* Move `vmmemory` to `LocalMemory`

* Move CoW/max limits into `LocalMemory`

Further simplify `RuntimeLinearMemory` by moving these responsibilities
up 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 possible
to only have it handled in `LocalMemory` and other pieces don't have to
worry about it.

* Move `wasm_accessible` into `LocalMemory`

Further simplify custom traits and mmap/static memory by moving more
responsibility 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.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

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 ended
up no

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 ended
up not not handling cases such as 4GiB exactly which is 1 larger than
the 32-bit range. Additionally 33+-bit numbers were never tested. This
intends to expand our fuzz coverage here by most of the time using the
default settings of `Config` and then otherwise selecting amongst an
"interesting" set of numbers such as 0, powers of two, etc.

show more ...

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

* Remove static/dynamic memories from public docs

This commit removes the terminology of "static" and "dynamic" memories
from the public-faci

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

* Remove static/dynamic memories from public docs

This commit removes the terminology of "static" and "dynamic" memories
from the public-facing documentation of Wasmtime, notably on the
`Config` structure and its various configuration settings. The goal of
this commit is in the same vein as #9543 which is to simplify the memory
settings of Wasmtime for users in this case.

This change doesn't actually have any code changes beyond renames (and
handling now-deprecated CLI options). The goal of this commit is to
basically rewrite how we document the effect of various settings of
Wasmtime. 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 to
take into account the removal of "dynamic" and "static" terminology.
Additionally more words have been written about the various effects of
each setting and how things related to wasm features such as index type
sizes and custom page sizes.

The rewritten documentation is intended to basically already match what
Wasmtime does today. I believe that all of these settings are useful in
one form or another so none have been dropped but the updated
documentation is intended to help simplify the mental model for how
they're processed internally and how they affect allocations and such.

* Fix how the setting is flipped

* Review comments

show more ...

Merge static/dynamic guard size options (#9528)

* Merge static/dynamic guard size options

This commit is the first of what will likely be a few to refactor the
memory-related configuration options

Merge static/dynamic guard size options (#9528)

* Merge static/dynamic guard size options

This commit is the first of what will likely be a few to refactor the
memory-related configuration options in Wasmtime. The end goal of these
refactorings is to fix some preexisting issues and additionally make the
configuration easier to understand for both users and implementors
alike. First on the chopping block here is to merge the
`dynamic_memory_guard_size` and `static_memory_guard_size` options into
one option. AFAIK there's not a strong reason to have separate
configuration options for these so it's hopefully simpler to have a
single `memory_guard_size` option which applies to all linear memories
equally.

I'll note that the old CLI options are preserved but are documented as
deprecated. We don't currently warn on using "deprecated options" so for
now the old options are just documented as deprecated and are otherwise
silently accepted.

* Fix compilation of C API

* Fix build of fuzzers

show more ...

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

* Wasmtime: Implement the custom-page-sizes proposal

This commit adds support for the custom-page-sizes proposal to Wasmtime:
https://gith

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

* Wasmtime: Implement the custom-page-sizes proposal

This commit adds support for the custom-page-sizes proposal to Wasmtime:
https://github.com/WebAssembly/custom-page-sizes

I've migrated, fixed some bugs within, and extended the `*.wast` tests for this
proposal from the `wasm-tools` repository. I intend to upstream them into the
proposal shortly.

There is a new `wasmtime::Config::wasm_custom_page_sizes_proposal` method to
enable or disable the proposal. It is disabled by default.

Our fuzzing config has been updated to turn this feature on/off as dictated by
the 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 another
constructor.

In general, we store the `log2(page_size)` rather than the page size
directly. This helps cut down on invalid states and properties we need to
assert.

I've also intentionally written this code such that supporting any power of two
page size (rather than just the exact values `1` and `65536` that are currently
valid) will essentially just involve updating `wasmparser`'s validation and
removing 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 size

Propagate errors instead of returning a value that is not actually a rounded up
version of the input.

Delay rounding up various config sizes until runtime instead of eagerly doing it
at config time (which isn't even guaranteed to work, so we already had to have a
backup plan to round up at runtime, since we might be cross-compiling wasm or
not 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` test

The point of the test is to ensure that we hit the limiter, so just cancel the
allocation from the limiter, and otherwise avoid MIRI attempting to allocate a
bunch 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 memory

It 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

show more ...

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

We have slightly different bounds checks for when Spectre mitigations are
enabled or disabled, so add a knob to our fuzzing m

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

We have slightly different bounds checks for when Spectre mitigations are
enabled or disabled, so add a knob to our fuzzing machinery to exercise all
cases.

show more ...

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

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

* Validate faulting addresses are valid to fault on

This commit adds a defense-in-depth measure to Wasmtime which is
intended to mitigate t

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

* Validate faulting addresses are valid to fault on

This commit adds a defense-in-depth measure to Wasmtime which is
intended to mitigate the impact of CVEs such as GHSA-ff4p-7xrq-q5r8.
Currently Wasmtime will catch `SIGSEGV` signals for WebAssembly code so
long 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 bug
to access memory outside of its sandbox. If the access was successful
there's no real way to detect that, but if the access was unsuccessful
then Wasmtime would happily swallow the `SIGSEGV` and report a nominal
trap. To embedders, this might look like nothing is going awry.

The new strategy implemented here in this commit is to attempt to be
more robust towards these sorts of failures. When a `SIGSEGV` is raised
the faulting pc is recorded but additionally the address of the
inaccessible location is also record. After the WebAssembly stack is
unwound and control returns to Wasmtime which has access to a `Store`
Wasmtime will now use this inaccessible faulting address to translate it
to a wasm address. This process should be guaranteed to succeed as
WebAssembly should only be able to access a well-defined region of
memory 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. The
purpose of this is to catch these sorts of bugs, make them very loud
errors, and hopefully mitigate impact. This would continue to not
mitigate the impact of a guest successfully loading data outside of its
sandbox, but if a guest was doing a sort of probing strategy trying to
find valid addresses then any invalid access would turn into a process
crash 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 the
address that was being accessed in addition to the bland "access out of
bounds" error. While this is still somewhat bland in the context of a
high level source language it's hopefully at least a little bit more
actionable for some. I'll note though that this isn't a guaranteed
contextual message since only the default configuration for Wasmtime
generates `SIGSEGV` on out-of-bounds memory accesses. Dynamically
bounds-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, I
can confirm that during development the crashing messages works just
fine as it took awhile on macOS to figure out where the faulting address
was recorded in the exception information which meant I had lots of
instances 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 s390x

s390x rounds faulting addresses to 4k boundaries.

show more ...

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 togethe

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.

show more ...