[44.0.0] Merged backports for security advisories (#13007)

* fix(environ): repair unsound StringPool::try_clone()

The 43.0 release introduced a soundness bug in StringPool::try_clone(): the
cloned

[44.0.0] Merged backports for security advisories (#13007)

* fix(environ): repair unsound StringPool::try_clone()

The 43.0 release introduced a soundness bug in StringPool::try_clone(): the
cloned map retains &'static str keys pointing into the original pool's
strings storage. Once the original Linker is dropped those keys dangle.

Cloning a Linker, then dropping the original one, leaves a linker whose
registered imports could no longer be found, causing instantiation to
fail with "unknown import".

Signed-off-by: Flavio Castelli <[email protected]>

* Fix pooling allocator predicate to reset VM permissions

This commit fixes a mistake that was introduced in #9583 where the logic
to reset a linear memory slot in the pooling allocator used the wrong
predicate. Specifically VM permissions must be reset if virtual memory
can be relied on at all, and the preexisting predicate of
`can_elide_bounds_check` was an inaccurate representation of this. The
correct predicate to check is `can_use_virtual_memory`.

* winch: Fix the type of the `table.size` output register

This commit corrects the tagged size of the output of the `table.size`
instruction. Previously this was hardcoded as a 32-bit integer instead
of consulting the table's index type to use the
index-type-sized-register instead.

* winch: Fix a host panic when executing `table.fill`

This commit fixes a possible panic when a Winch-compiled module executes
the `table.fill` instruction. Refactoring in #11254 updated Cranelift
but forgot to update Winch meaning that Winch's indices were still using
the module-level indices instead of the `DefinedTableIndex` space. This
adds some tests and updates Winch's translation to use preexisting
helpers.

* x64: Fix `f64x2.splat` without SSE3

Don't sink a load into `pshufd` which loads 16 bytes, instead force
`put_in_xmm` to ensure only 8 bytes are loaded.

* Properly verify alignment in string transcoding

This commit updates string transcoding between guest modules to properly
verify alignment. Previously alignment was only verified on the first
allocation, not reallocations, which is not spec-compliant. This
additionally fixes a possible host panic when dealing with unaligned
pointers.

* Fix type confusion in AArch64 amode RegScaled folding

* winch: Add add_uextend to perform explicit extension when needed.

This commit fixes an out-of-bounds access caused by the lack zero
extension in the code responsible for calculating the heap address for
loads/stores.

This issue manifests in aarch64 (unlike x64) given that no automatic
extension is performed, resulting in an out-of-bounds access.

An alternative approach is to emit an extend for the index, however
this approach is preferred given that it gives the MacroAssembler
layer better control of how to lower addition, e.g., in aarch64 we can
inline the desired extension in a single instruction.

* winch: Correctly type the result of table.grow

This commit fixes an out-of-bounds access caused by the lack of type
narrowing from the `table.grow` builtin. Without explicit narrowing,
the type is treated as 64-bit value, which could cause issues when
paired with loads/stores.

* Review comments

* Properly handle table index types

Only narrow when dealing with the 64-bit pointer/32-bit tables

* Fix panic with out-of-bounds flags in `Value`

This commit fixes a panic when a component model `Value` is lifted from
a flags value which specifies out-of-bounds bits as 1. This is specified
in the component model to ignore the out-of-bounds bits, which `flags!`
correctly did (and thus `bindgen!`), but `Value` treated out-of-bounds
bits as a panic due to indexing an array.

* Fix bounds checks in FACT's `string_to_compact` method

We need to bounds check the source byte length, not the number of code units.

* Add missing realloc validation in string transcoding

This commit adds a missing validation that a return value of `realloc`
is inbounds during string transcoding. This was accidentally missing on
the transcoding path from `utf8` to `latin1+utf16` which meant that a
nearly-raw pointer could get passed to the host to perform the
transcode.

* winch: Refine zero extension heuristic

This commit refines the zero extension heuristic such that it
unconditionally emits a zero extension when dealing with 32-bit
heaps. This eliminates any ambiguity related to the value of the
memory indices across ISAs.

* Fix failure on 32-bit

* Fix miri test

---------

Signed-off-by: Flavio Castelli <[email protected]>
Co-authored-by: Flavio Castelli <[email protected]>
Co-authored-by: Shun Kashiwa <[email protected]>
Co-authored-by: Saúl Cabrera <[email protected]>
Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Use `TryClone::clone_panic_on_oom` where it makes sense (#12681)

Handle OOM in `wasmtime_environ::types::WasmFuncType` (#12670)

* Handle OOM in `wasmtime_environ::types::WasmFuncType`

It should also not `#[derive(Clone)]` anymore, just `TryClone`, which
propagat

Handle OOM in `wasmtime_environ::types::WasmFuncType` (#12670)

* Handle OOM in `wasmtime_environ::types::WasmFuncType`

It should also not `#[derive(Clone)]` anymore, just `TryClone`, which
propagates out to a bunch of other types as well.

And while we are here:

* Rename its "returns" to "results" to match Wasmtime's public API and also the
Wasm text format.
* Store both its params and results in a single allocation.
* Shrink its size on 64-bit architectures by storing its param- and
result-GC-type counts as `u32`s rather than `usize`s.

* fix clippy

* fix winch unit tests

show more ...

Migrate winch-codegen to `wasmtime_environ::error` (#12297)

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and d

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and disriminant gap

* add module arg to `Module::new()` calls in tests

show more ...

Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)

* Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName`

`FuncKey`, which used to be call

Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)

* Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName`

`FuncKey`, which used to be called `CompileKey`, is now one-to-one with
`cranelift_codegen::ir::UserExternalName`, and is used for not just identifying
compilation objects but also relocations and call-graph edges. This allows us to
determine the `StaticModuleIndex` and `DefinedFuncIndex` pair for any
`cranelift_codegen::ir::FuncRef`, regardless of inlining depth, which fixes some
fuzz bugs on OSS-Fuzz.

This continues pushing on the idea that Wasmtime's compilation orchestration and
linking should be relatively agnostic to the kinds of things it is actually
compiling and linking, allowing us to tweak, add, and remove new kinds of
`FuncKey`s more easily. Adding a new `FuncKey` should not require modifying
relocation resolution, for example, just a little bit of code to run the
associated compilation and optionally some code to extract metadata into our
final artifacts for querying at runtime. Everything in between should Just
Continue Working. We still aren't all the way there yet, but this does bring us
a little bit closer.

Finally, in Cranelift's inlining pass, this adds a check that a block is
inserted in the layout before attempting to remove it from the layout, which
would otherwise cause panics. This was triggered by multi-level inlining and
now-unreachable blocks in the inner callees.

I'll note that this does update basically all of the disas tests, or at least
nearly all of them that make function calls. This is because the namespace/index
numbering pair changed slightly to align with `FuncKey`, but that should pretty
much be the only changes.

* remove debug info from panic message, it is only available in some `cfg`s

* fill out module doc comment

* Fix compilation without `component-model` feature

* Fix some more cfg compilations

* cargo fmt

* fix a wrong `&dyn Any` auto coercion; add helpful debug logging and assertions for this kind of thing

show more ...

Make `vm::Instance::get_defined_memory` safe (#11211)

This is a small step forward to making `vm::Instance` safe internally.
Notably the `get_defined_memory` helper now returns a safe mutable
refere

Make `vm::Instance::get_defined_memory` safe (#11211)

This is a small step forward to making `vm::Instance` safe internally.
Notably the `get_defined_memory` helper now returns a safe mutable
reference instead of a raw pointer. This is then additionally coupled
with the canonicalization of always working with memories as "instance
plus defined memory index" instead of "instance plus memory index". This
enables removing some unsafe `VMContext` to `Instance` conversion as
well. This change, however, required updating libcalls to special-case
when an imported memory is operated on to load the vmcontext/index in
the libcall itself.

This change notably does not update the `memory_init` libcall just yet
due to the fact that the `DataIndex` is relative to the owning instance
even if the memory is owned by a different instance (e.g. it's
imported). Otherwise this chips away at some of the `unsafe` related to
memory/table management in `vm::Instance`.

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Update wasm spec test suite, add exception feature flags (#10553)

* Update wasm spec test suite, add exception feature flags

This commit performs an update of the spec test suite submodule to the
n

Update wasm spec test suite, add exception feature flags (#10553)

* Update wasm spec test suite, add exception feature flags

This commit performs an update of the spec test suite submodule to the
next-to-latest commit. The latest commit will require updating the
`wast` dependency which isn't published yet.

This update brings in the `wasm-3.0` folder of tests since it's been
awhile since the last update. That update notably means that the
exception-handling proposal is mixed in with all the others with various
tests. Getting tests as flagged as passing or failing as a result was
unexpectedly difficult.

The solution I ended up settling on was to preemptively implement some
infrastructure for the exceptions proposal:

* `wasmtime::Config` methods
* `wasmtime` CLI flags
* integration with wast testing
* various updates to `should_fail`

It turns out we can run a few tests with the exception proposal, notably
due to tags being implemented for stack switching. That meant that this
couldn't blanket ignore the exceptions proposal and say it's expected to
fail. Instead the proposal is said "this passes!" and tests are
individually listed as "this is expected to fail".

This then required changing an `unsupported!` panic to plumbing errors
around to avoid actually implementing the exceptions proposal here.

* Review comments

show more ...

Rename `VMTableImport` to `VMTable` (#10506)

In #10499, I used the `struct VMTableImport` to hold the necessary
pointers for accessing a core WebAssembly table from a component. Since
`VMTableImport

Rename `VMTableImport` to `VMTable` (#10506)

In #10499, I used the `struct VMTableImport` to hold the necessary
pointers for accessing a core WebAssembly table from a component. Since
`VMTableImport` no longer was exclusively used for imported tables, it
seems reasonable to rename it to something less specific: `VMTable`.
This changes all the functions referencing `vmtable_import*` as well
except those that are specifically dealing with imported tables.

show more ...

Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)

* Fix assertion in `PartialEq` for `RegisteredType` again

It is possible for two `

Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)

* Fix assertion in `PartialEq` for `RegisteredType` again

It is possible for two `WasmSubType`s to be equal to each other, as far as
`derive(PartialEq)` is concerned, but still different from each other if they
are in different rec groups or even if they are at different indices within the
same rec group. The assertion mistakenly did not permit either of these,
however.

Fixes #9714

* Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`s

Rather than canonicalizing them on demand in functions like
`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it in
one place, up front, so that it is very unlikely we miss anything. Doing this
involves changing some things from `ModuleInternedTypeIndex`es to
`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch of
uses of those things need to unwrap the appropriate kind of type index at usage
sites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtime
uses usage will unwrap `VMSharedTypeIndex`es). And it additionally required
implementing the `TypeTrace` trait for a handful of things to unlock the
provided `canonicalize_for_runtime_usage` trait method for those things.

All this machinery is required to avoid an assertion failure in the regression
test introduced in the previous commit, which was triggered because we were
failing to canonicalize type indices inside `ExternType`s for runtime usage on
some code paths. We shouldn't have to play that kind of whack-a-mole in the
future, thanks to this new approach.

* Fix a warning in no-default-features builds

* Fix another warning in weird cfg builds

show more ...

winch: Gracefully handle unsupported Wasm types (#9949)

* winch: Gracefully handle unsuppported Wasm types

Follow-up to https://github.com/bytecodealliance/wasmtime/pull/9851

Prior to this commit,

winch: Gracefully handle unsupported Wasm types (#9949)

* winch: Gracefully handle unsuppported Wasm types

Follow-up to https://github.com/bytecodealliance/wasmtime/pull/9851

Prior to this commit, Winch's ABI layer would panic on unsupported Wasm
types, i.e., `v128`, `externref`.

This commit ensures that a recoverable error is returned in case an
unsupported type is found in a function signature.

This change is particularly helpful to start running spec tests for
aarch64.

* Fix unit tests for x64/aarch64 abi

show more ...

Winch atomic loads x64 (#9970)

* enable thread feature for x86

* implement atomic loads for x64

* add atomic load support to winch codegen

* add i32.atomic.load8_u to visitor

* test i32.atomic.l

Winch atomic loads x64 (#9970)

* enable thread feature for x86

* implement atomic loads for x64

* add atomic load support to winch codegen

* add i32.atomic.load8_u to visitor

* test i32.atomic.load8_u

* implement i32.atomic.load16_u

* add test for i32.atomic.load16_u

* implement i32.atomic.load

* add test for i32.atomic.load

* implement i64.atomic.load8_u

* add test for i64.atomic.load8_u

* implement i64.atomic.load16_u

* add test for i64.atomic.load16_u

* implement i64.atomic.load32_u

* add test for i64.atomic.load32_u

* implement i64.atomic.load

* add test for i64.atomic.load

* fmt

* clarify comment

* review edits

* handle shared memory in winch

* update winch spec tests

* fmt

* update HeapData doc

show more ...

Remove the use of `MemoryStyle` in Winch (#9581)

This applies a similar change as #9576 but to Winch. Similar to the
previous PR one case needed some reshuffling, but otherwise all current
behavior

Remove the use of `MemoryStyle` in Winch (#9581)

This applies a similar change as #9576 but to Winch. Similar to the
previous PR one case needed some reshuffling, but otherwise all current
behavior is maintained and this should otherwise be a refactoring.

show more ...

More refactoring to remove `MemoryStyle` (#9543)

* Remove tuple return value of `MemorysStyle::for_memory`

The second option is always `tunables.memory_guard_size`, so propagate
this to the various

More refactoring to remove `MemoryStyle` (#9543)

* Remove tuple return value of `MemorysStyle::for_memory`

The second option is always `tunables.memory_guard_size`, so propagate
this to the various locations reading it.

* Remove `offset_guard_size` from compiler `Heap` structs

Push reading `Tunables` down further into where it's needed instead of
having duplicate storage per-heap.

* Plumb wasm memory types further down in Winch

This commit plumbs `wasmtime_environ::Memory` further down the stack in
Winch to where heaps are processed. This avoids an extra layer of
indirection through a `Heap` type which peels apart a `Memory` to pick
out a few fields. In the future this'll be used with more helpers on
`Memory` to simplify the static/dynamic memory cases.

* Plumb memory type further down in Cranelift

This commit removes the `HeapStyle` structure from Cranelift and instead
plumbs the `wasmtime_environ::Memory` type further down the stack
through in `HeapData` (same as Winch before this commit). This removes
redundant fields in `MemoryType` and continues to push down the
`MemoryStyle` structure even further.

This commit additionally and unconditionally defines a `GlobalValue` for
the heap limit of memory. This is unused most of the time for 32-bit
wasm and is conditionally used depending on how bounds checks are
generated. This is a small amount of bloat to each function since
previously functions that didn't need this `GlobalValue` elided it. A
future refactoring, however, will make it a bit more clear how this is
used even for "static" memories.

* Update test expectations

show more ...

Remove the `wasmtime_environ::MemoryPlan` type (#9532)

* Remove the `wasmtime_environ::MemoryPlan` type

This is the equivalent of #9530 for memories. The goal of this commit is
to eventually remove

Remove the `wasmtime_environ::MemoryPlan` type (#9532)

* Remove the `wasmtime_environ::MemoryPlan` type

This is the equivalent of #9530 for memories. The goal of this commit is
to eventually remove the abstraction layer of `MemoryPlan` and
`MemoryStyle` in favor of directly reading the configuration of
`Tunables`. The prediction is that it will be simpler to work directly
with configured values instead of a layer of abstraction between the
configuration and the runtime which needs to be evolved independently to
capture how to interpret the configuration.

Like with #9530 my plan is to eventually remove the `MemoryStyle` type
itself, but that'll be a larger change, so it's deferred to a future
PR.

* Fix shared memory disabled build

show more ...

Remove the `wasmtime_environ::TablePlan` type (#9530)

* Remove the `wasmtime_environ::TablePlan` type

In my quest to simplify memory configuration and how things work
internally in Wasmtime one thi

Remove the `wasmtime_environ::TablePlan` type (#9530)

* Remove the `wasmtime_environ::TablePlan` type

In my quest to simplify memory configuration and how things work
internally in Wasmtime one thing I've identified to accomplish is the
removal of the `TablePlan` and `MemoryPlan` types. These introduce an
abstraction layer between table/memory implementations and `Tunables`
and personally I find it simpler to directly reference `Tunables` and
use that instead. The goal of this commit is to plumb `Tunables` closer
to where it's directly read by removing the "indirection" through the
`*Plan` types.

The `TablePlan` and `MemoryPlan` types are pervasively used throughout
Wasmtime so instead of having one large commit delete everything this is
instead a piecemeal approach to incrementally get towards the goal of
removal. Here just `TablePlan` is removed and `Tunables` is plumbed in a
few more places. I plan to also in the future remove `TableStyle` and
`MemoryStyle` in favor of directly reading `Tunables` but that's left
for a future commit. For now `TableStyle` persists and its usage is a
bit odd in isolation but I plan to follow this up with the removal of
`TableStyle`.

* Fix non-component-model build

show more ...

Refactor `WasmparserTypeConverter` to avoid needing a `Module` (#9513)

While poking with @alexcrichton at how component core types are
translated (or not, as we found), we realized that the
`Wasmpar

Refactor `WasmparserTypeConverter` to avoid needing a `Module` (#9513)

While poking with @alexcrichton at how component core types are
translated (or not, as we found), we realized that the
`WasmparserTypeConverter` doesn't need an entire `Module` in order
lookup type indices. In fact, we were previously passing empty `Module`s
in cases where no lookups were needed. This change threads through a
closure instead, which should help later with component core types when
we certainly won't have a `Module`.

Co-authored-by: Alex Crichton <[email protected]>

show more ...

winch: Implement Fuel-Based Interruption (#9472)

* winch: Implement Fuel-Based Interruption

Closes: https://github.com/bytecodealliance/wasmtime/issues/8090

This commit introduces the initial impl

winch: Implement Fuel-Based Interruption (#9472)

* winch: Implement Fuel-Based Interruption

Closes: https://github.com/bytecodealliance/wasmtime/issues/8090

This commit introduces the initial implementation of fuel-based
interruption in Winch.

To maintain consistency with existing fuel semantics, this
implementation closely follows the Wasmtime/Cranelift approach, with the
following exception:

* Local Fuel Cache: Given Winch's emphasis on compilation speed,
this implementation does not optimize for minimizing loads and stores.
As a result, checking and incrementing fuel currently requires
explicit loads and stores. Future optimizations may be considered to
improve this aspect.

This commit also includes a small refactoring in the visitor, which
introduces more generic "visitor hook" which enable handling the invariants that need
to happen before and after emitting machine code for each Wasm operator.

* Use the vmruntime limits directly

* Remove unsupported fuel warning

show more ...

Bump wasm-tools crates to 219 (#9399)

* Bump wasm-tools crates to 219

Keeping up-to-date

* Fix wasmtime-environ build with less features

* Use crates.io-based versions

* Fix build of adapter ver

Bump wasm-tools crates to 219 (#9399)

* Bump wasm-tools crates to 219

Keeping up-to-date

* Fix wasmtime-environ build with less features

* Use crates.io-based versions

* Fix build of adapter verifier

* Fix factc compile

* Fix wasmtime-environ fuzzer

show more ...

Implement the table64 extension to the memory64 proposal (#9206)

This commit implements the table64 extention in both Wasmtime and
Cranelift.

Most of the work was changing a bunch of u32 values to

Implement the table64 extension to the memory64 proposal (#9206)

This commit implements the table64 extention in both Wasmtime and
Cranelift.

Most of the work was changing a bunch of u32 values to u64/usize.
The decisions were made in align with the PR #3153 which
implemented the memory64 propsal itself.

One significant change was the introduction of `IndexType`
and `Limits` which streamline and unify the handling of limits
for both memories and tables.

The spec and fuzzing tests related to table64 are re-enabled which
provides a good coverage of the feature.

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 ...

Change `MemoryStyle::Static` to store bytes, not pages (#8608)

* Change `MemoryStyle::Static` to store bytes, not pages

This commit is inspired by me looking at some configuration in the
pooling al

Change `MemoryStyle::Static` to store bytes, not pages (#8608)

* Change `MemoryStyle::Static` to store bytes, not pages

This commit is inspired by me looking at some configuration in the
pooling allocator and noticing that configuration of wasm pages vs bytes
of linear memory is somewhat inconsistent in `Config`. In the end I'd
like to remove or update the `memory_pages` configuration in the pooling
allocator to being bytes of linear memory instead to be more consistent
with `Config` (and additionally anticipate the custom-page-sizes
wasm proposal where terms-of-pages will become ambiguous). The first
step in this change is to update one of the lowest layered usages of
pages, the `MemoryStyle::Static` configuration.

Note that this is not a trivial conversion because the purpose of
carrying around pages instead of bytes is that bytes may overflow where
overflow-with-pages typically happens during validation. This means that
extra care is taken to handle errors related to overflow to ensure that
everything is still reported at the same time.

* Update crates/wasmtime/src/runtime/vm/instance/allocator/pooling/memory_pool.rs

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

* Fix tests

* Really fix tests

---------

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

show more ...

Wasmtime(gc): Add support for supertypes and finality (#8595)

This is the final type system change for Wasm GC: the ability to explicitly
declare supertypes and finality. A final type may not be a s

Wasmtime(gc): Add support for supertypes and finality (#8595)

This is the final type system change for Wasm GC: the ability to explicitly
declare supertypes and finality. A final type may not be a supertype of another
type. A concrete heap type matches another concrete heap type if its concrete
type is a subtype (potentially transitively) of the other heap type's concrete
type.

Next, I'll begin support for allocating GC structs and arrays at runtime.

I've also implemented `O(1)` subtype checking in the types registry:

In a type system with single inheritance, the subtyping relationships between
all types form a set of trees. The root of each tree is a type that has no
supertype; each node's immediate children are the types that directly subtype
that node.

For example, consider these types:

class Base {}
class A subtypes Base {}
class B subtypes Base {}
class C subtypes A {}
class D subtypes A {}
class E subtypes C {}

These types produce the following tree:

Base
/ \
A B
/ \
C D
/
E

Note the following properties:

1. If `sub` is a subtype of `sup` (either directly or transitively) then
`sup` *must* be on the path from `sub` up to the root of `sub`'s tree.

2. Additionally, `sup` *must* be the `i`th node down from the root in that path,
where `i` is the length of the path from `sup` to its tree's root.

Therefore, if we maintain a vector containing the path to the root for each
type, then we can simply check if `sup` is at index `supertypes(sup).len()`
within `supertypes(sub)`.

show more ...

Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)

* Rename `WasmHeapType::Concrete(_)` to `WasmHeapType::ConcreteFunc(_)`

* Rename `wasmtime::HeapType::Co

Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)

* Rename `WasmHeapType::Concrete(_)` to `WasmHeapType::ConcreteFunc(_)`

* Rename `wasmtime::HeapType::Concrete` to `wasmtime::HeapType::ConcreteFunc`

* Introduce Wasm sub- and composite-types

Right now, these are only ever final function types that don't have a supertype,
but this refactoring paves the way for array and struct types, and lets us make
sure that `match`es are exhaustive for when we add new enum variants. (Although
I did add an `unwrap_func` helper for use when it is clear that the type should
be a function type, and if it isn't then we should panic.)

show more ...