dundargoc opened PR #8569 from dundargoc:backport/release-20.0.0
to bytecodealliance:release-20.0.0
.
dundargoc requested elliottt for a review on PR #8569.
dundargoc requested wasmtime-core-reviewers for a review on PR #8569.
dundargoc requested wasmtime-default-reviewers for a review on PR #8569.
dundargoc edited PR #8569:
[20.0.0]: Backport fixes from main to the release branch (#8331)
cranelift: Include clobbers and outgoing args in stack limit (#8301)
When we compute the amount of space that we need in a stack frame for
the stack limit check, we were only counting spill-slots and explicit
stack-slots. However, we need to account for all uses of the stack which
occur before the next stack limit check. That includes clobbers and any
stack arguments we want to pass to callees.The maximum amount that we could have missed by is essentially bounded
by the number of arguments which could be passed to a function. In
Wasmtime, that is limited byMAX_WASM_FUNCTION_PARAMS
in
wasmparser::limits
, which is set to 1,000, and the largest arguments
are 16-byte vectors, so this could undercount by about 16kB.This is not a security issue according to Wasmtime's security policy
(https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html)
because it's the embedder's responsibility to ensure that the stack
where Wasmtime is running has enough extra space on top of the
configuredmax_wasm_stack
size, and getting within 16kB of the host
stack size is too small to be safe even with this fixed.However, this was definitely not the intended behavior when stack limit
checks or stack probes are enabled, and anyone with non-default
configurations or non-Wasmtime uses of Cranelift should evaluate whether
this bug impacts your use case.(For reference: When Wasmtime is used in async mode or on Linux, the
default stack size is 1.5MB larger than the default WebAssembly stack
limit, so such configurations are typically safe regardless. On the
other hand, on macOS the default non-async stack size for threads other
than the main thread is the same size as the default for
max_wasm_stack
, so that is too small with or without this bug fix.)
- fix: bindgen trappable_errors using unversion/versioned packages (#8305)
Signed-off-by: Brian H <brian.hardock@fermyon.com>
Cranelift: Do not dedupe/GVN bitcasts from reference values (#8317)
Cranelift: Do not dedupe/GVN bitcasts from reference values
Deduping bitcasts to integers from references can make the references no long
longer live across safepoints, and instead only the bitcasted integer results
would be. Because the reference is no longer live after the safepoint, the
safepoint's stack map would not have an entry for the reference, which could
result in the collector reclaiming an object too early, which is basically a
use-after-free bug. Luckily, we sandbox the GC heap now, so such UAF bugs aren't
memory unsafe, but they could potentially result in denial of service
attacks. Either way, we don't want those bugs!On the other hand, it is technically fine to dedupe bitcasts to reference
types. Doing so extends, rather than shortens, the live range of the GC
reference. This potentially adds it to more stack maps than it otherwise would
have been in, which means it might unnecessarily survive a GC it otherwise
wouldn't have. But that is fine. Shrinking live ranges of GC references, and
removing them from stack maps they otherwise should have been in, is the
problematic transformation.
Add additional logging and debug asserts for GC stuff
Handle out-of-bounds component sections (#8323)
Handle out-of-bounds component sections
Fixes https://github.com/bytecodealliance/wasmtime/issues/8322
- Add a test that trancated component binaries don't cause panics
Signed-off-by: Brian H <brian.hardock@fermyon.com>
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
Co-authored-by: Brian <brian.hardock@fermyon.com>
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Backport 8066 to release-20.0.0 (#8351)
wasmtime-c-api: switch from wasi-common to wasmtime-wasi (#8066)
wasmtime-c-api: switch from using wasi-common to wasmtime-wasi
Fix WasiP1Ctx references, and stop eagerly opening dirs for preopens
Add OutputFile to skip async writes in stdout/stderr
Co-authored-by: Trevor Elliott <telliott@fastly.com>
- Add release notes for 8066
Co-authored-by: Pat Hickey <phickey@fastly.com>
[20.0.0] More backports of fixes, mostly c-api related (#8368)
c-api: Better differentiate between
wasm.h
andwasmtime.h
APIs (#8344)This renames some types and adds some type aliases to help us better distinguish
betweenwasm.h
APIs andwasmtime.h
APIs, primarily forStore
-related
types. In general,WasmFoo
is related towasm.h
andWasmtimeFoo
is related
towasmtime.h
.
StoreRef
->WasmStoreRef
- Introduce the
WasmStore[Data]
andWasmStoreContext[Mut]
aliasesStoreData
->WasmtimeStoreData
CStoreContext[Mut]
->WasmtimeStoreContext[Mut]
Introduce the
Wasmtime{Store,Caller}
aliases
wasmtime-c-api
: Improve non-support of GC references inwasm.h
APIs (#8345)c-api: Better differentiate between
wasm.h
andwasmtime.h
APIsThis renames some types and adds some type aliases to help us better distinguish
betweenwasm.h
APIs andwasmtime.h
APIs, primarily forStore
-related
types. In general,WasmFoo
is related towasm.h
andWasmtimeFoo
is related
towasmtime.h
.
StoreRef
->WasmStoreRef
- Introduce the
WasmStore[Data]
andWasmStoreContext[Mut]
aliasesStoreData
->WasmtimeStoreData
CStoreContext[Mut]
->WasmtimeStoreContext[Mut]
Introduce the
Wasmtime{Store,Caller}
aliasesc-api: Improve non-support of GC references in
wasm.h
APIsA couple small tweaks: error message improvements, exhaustive matching, etc...
Fix running wasi-common tests on CI (#8353)
Fix running wasi-common tests on CI
Turns out we haven't been running wasi-common tests for some time in CI
and they've started failing. Force enable the test at all times and then
fix the test failures. The test failures here were introduced in #8277
and weren't caught due to the test not running and the fix was to relax
the implementation offd_pread
to avoid taking multiple mutable
borrows.
Fix CI
Update release notes for 20.0.0 (#8358)
A busy release!
- Enable the gc feature by default in the c-api (#8356)
Match the Wasmtime crate in this respect
- wasmtime-c-api: Add support for GC references in
wasmtime.h
APIs (#8346)Restores support for
externref
inwasmtime_val_t
, methods for manipulating
them and getting their wrapped host data, and examples/tests for these things.Additionally adds support for
anyref
inwasmtime_val_t
, clone/delete methods
similar to those forexternref
, and a fewi31ref
-specific methods. Also adds
C and Rust example / test for working withanyref
.
Fix calculation of gc refs in functions (#8355)
Fix calculation of gc refs in functions
In addition to excluding i31 also exclude funcrefs.
Review comments
Remove
wasi_config_preopen_socket
from C header (#8364)This was removed in #8066
Tidy up some headers related to shared memory (#8366)
Tidy up some headers related to shared memory
Don't declare an anonymous
struct wasmtime_sharedmemory
, instead
#include
the actual definition.Fix an issue where a header in
sharedmemory.h
referred to a type in
extern.h
which wasn't#include
'd. This function,
wasmtime_sharedmemory_into_extern
, additionally isn't necessary as
it's no different than manually constructing it. Fix this by removing
this function.Run clang-format
c-api: Fix alignment of
wasmtime_val_*
(#8363)c-api: Fix alignment of
wasmtime_val_*
This commit fixes an issue where
wasmtime_val_raw_t
had an incorrect
alignment. In RustValRaw
contains au128
which has an alignment of
16 but in C the representation had a smaller alignment meaning that the
alignment of the two structures was different. This was seen to cause
alignment faults when structure were passed from C++ to Rust, for
example.This commit changes the Rust representation of
ValRaw
'sv128
field
to do the same as C which is to use[u8; 16]
. This avoids the need to
raise the alignment in C which appears to be nontrivial. Cranelift is
appropriately adjusted to understand that loads/stores fromValRaw
are
no longer aligned. Technically this only applies to thev128
field but
it's not too bad to apply it to the other fields as well.
Try alternate syntax for alignof
Use
--locked
on allcargo install
in CI, also remove non-locked example (#8369)Use
--locked
on allcargo install
in CIPrevents any updates to rustc or crates from accidentally causing issues
by ensuring that the same set of deps is used over time.
- Remove rust/WASI markdown parser example
The documentation referring to this example was removed in #6994 and
that forgot to remove this as well. This example is building without a
lock file which is causing issues in #8368.
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
c-api: Create
RootScope
where necessary (#8374) (#8375)c-api: Create
RootScope
where necessaryThis commit changes the
wasmtime_val_t::{from_val, to_val}
methods to
take aRootScope
instead of anyAsContextMut
. This then required a
number of refactorings in callers to ensure that aRootScope
was
created for any function that needed one. This is required to ensure
that GC references in the C API aren't forced to live for the entire
lifetime of the store.This additionally added
*_unrooted
variants which do the same thing
but don't requireRootScope
. This was needed for when the C API calls
out to the embedder through a function call because a newRootScope
wouldn't work for return values (they're bound to a scope within the
closure when we want them to outlive the closure). In these situations
though we know aRootScope
is already present at the entrypoint.Closes #8367
Review comments
Fix use-after-free in externref example (#8410) (#8414)
[message truncated]
dundargoc edited PR #8569:
- fix(c-api): give a cleaner error message if cargo isn't found (#8497)
Instead of
Performing build step for
'wasmtime-crate''WASMTIME_CARGO_BINARY-NOTFOUND' is not recognized as an
internal or external command, operable program or batch file.this will now instead output
"cargo" was not found. Ensure "cargo" is in PATH. Aborting...
c-api: use
--release
when MinSizeRel and RelWithDebInfo is used (#8549)build: add "fastest-runtime" profile for runtime optimization (#8554)
This is extremely useful for cases where the default optimizations just
are not enough.Background: neovim is interested to
add wasmtime support in https://github.com/neovim/neovim/pull/28415 but
we noticed that including wasmtime, even when not using wasmtime
directly, heavily affects runtime performance. This is not only
reflected in the increased startuptime but affects the runtime
performance overall.Here are the benchmarks for startuptimes for different configurations.
Important to note is that all of runtime is affected, but the
startuptime is a decent proxy to measure runtime performance:No wasm Time (mean ± σ): 50.5 ms ± 1.5 ms [User: 32.8 ms, System: 12.3 ms] Range (min … max): 48.3 ms … 54.4 ms 56 runs Wasm, lto=thin Time (mean ± σ): 104.9 ms ± 3.5 ms [User: 86.5 ms, System: 12.7 ms] Range (min … max): 99.5 ms … 111.1 ms 26 runs Wasm, lto=true Time (mean ± σ): 83.8 ms ± 2.5 ms [User: 65.8 ms, System: 12.1 ms] Range (min … max): 80.5 ms … 93.3 ms 31 runs Wasm, lto=true, strip="none", incremental=false, codegen-units=1, panic="abort" Time (mean ± σ): 53.1 ms ± 1.0 ms [User: 35.5 ms, System: 12.5 ms] Range (min … max): 50.6 ms … 55.5 ms 54 runs
alexcrichton submitted PR review.
alexcrichton merged PR #8569.
Last updated: Dec 23 2024 at 13:07 UTC