Allow another error in `p3_sockets_tcp_streams` test (#12927)

Captured in a failure in #12924

Closes #12924

Add more test domains. (#12898)

Taken from the `tls_sample_application` tests

Add some debugging to a TCP test (#12890)

Attempting to help diagnose the spurious failure that cropped up in #12864.

Closes #12864

feat(p3): implement wasi:tls (#12834)

* Split off p2-specific bits into submodule

* Vendor the 0.3.0-draft WIT files

* Host traits scaffolding

* Rename p2 test

* Work around bug in `tokio-native

feat(p3): implement wasi:tls (#12834)

* Split off p2-specific bits into submodule

* Vendor the 0.3.0-draft WIT files

* Host traits scaffolding

* Rename p2 test

* Work around bug in `tokio-native-tls`

* Create error type

* Implement p3

Co-authored-by: Roman Volosatovs <[email protected]>

* Fix test on Windows' SChannel

Same reason as described in https://github.com/bytecodealliance/wasmtime/pull/11064

* Satisfy clippy

* Fix typo

---------

Co-authored-by: Roman Volosatovs <[email protected]>

show more ...

Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, simi

Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, similar to the existing
native-debug tests.

- A CI job that runs the above in CI.

- Some minor tweaks to the gdbstub debugger design:
- Rather than the initial single-step to get to the first Wasm
instruction where module(s) will be instantiated into the store
and visible to the debugger, we pre-register modules with the
store eagerly. This avoids the slightly hacky flow and also is a
preparation step for `wasmtime serve` debugging, where we can't
single-step into execution eagerly (because execution doesn't
start at all until an HTTP request arrives).
- Add a separate message-printing path for "debugger info messages",
allowing us to print the "debugger is listening on <PORT>" message
without inheriting stderr for the whole debugger component
environment. This message is necessary for the above integration
test (it parses the message to determine when the debuggee is ready).

show more ...

Implement the new ConnectionBroken error code. (#12840)

Introduced in https://github.com/WebAssembly/WASI/pull/887

fix: correct various typos (#12807)

Signed-off-by: Ho Kim <[email protected]>

p3_big_random_buf test (#12817)

* s

* s

WASIP3 HTTP return error for TooManyFields/TotalSizeTooBig (#12788)

* WASIP3 HTTP return error for TooManyFields/TotalSizeTooBig

Return new error from

* WASIP3 HTTP split tests between p2/p3

p2 c

WASIP3 HTTP return error for TooManyFields/TotalSizeTooBig (#12788)

* WASIP3 HTTP return error for TooManyFields/TotalSizeTooBig

Return new error from

* WASIP3 HTTP split tests between p2/p3

p2 cases unchanged (they trap before break is reached).

p3 cases assert the guest exited successfully and
that it printed "error received", confirming the limit was actually enforced.

show more ...

WASIP3 update to latest rc (#12781)

Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT wor

Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT world that hosts
debug components that have access to "host debug powers" via a
debugging API, and the ability to load such a debug-component and give
it control of the main program as a debuggee when using `wasmtime
run`.

The WIT is namespaced to `bytecodealliance:wasmtime` and is slightly
aspirational in places: for example, the host does not yet implement
injection of early return values or exception-throws. I intend to fill
out a series of TODO issues once this all lands to track followup
("post-MVP") work.

This PR does not include any debug components. I separately have a
gdbstub component, with which I tested and co-developed this host-side
implementation. My plan is to land it in a followup PR as a component
that will be embedded in/shipped with the Wasmtime CLI and available
under an easy-to-use CLI option. Once we have that gdbstub component,
we can also implement end-to-end integration tests that boot up LLDB
and run through an expected interaction. (Separately, those
integration tests will require a release of wasi-sdk to ship an LLDB
binary that we can use.) As such, there are no real tests in this PR:
interesting behaviors only really occur with a full end-to-end flow.

The integration with the CLI is a little awkward (we internally build
another `wasmtime run` command that invokes the debug component, and
tie it together with the debuggee via a special `invoke_debugger` API;
this seemed less bad than reworking all of the WASI setup to be more
reusable). Happy to take more ideas here.

* Review feedback.

* Review feedback.

* Review feedback: update vendor-wit.sh.

* Review feedback: -Ddebugger-arg= -> -Darg=.

* Review feedback.

* Review feedback.

* Review feedback: factor host.rs into several submodules.

* Review feedback: rename Debugger to Debuggee on host side.

* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.

* Review feedback.

* Review feedback.

* Add simple debug-component tests.

* Add wasm32-wasip2 target in a few places in CI

* Cargo vets for wstd dependency.

* Add wasm32-wasip2 in more places

* fix debug-component test dependence on componentization byte offsets

* Review feedback.

* Fix cancel-safety of EventFuture.

* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.

* Review feedback.

* Review feedback: strip down WASI imports in debugger world.

* fold debugger test component back into wasip1 + adapter test artifact compilation flow

show more ...

Enable limiting wasip3 resource limits (#12761)

* Enable limiting wasip3 resource limits

This commit adds a new `Store::concurrent_resource_table` method which
enables getting a handle to the under

Enable limiting wasip3 resource limits (#12761)

* Enable limiting wasip3 resource limits

This commit adds a new `Store::concurrent_resource_table` method which
enables getting a handle to the underlying `ResourceTable` used by the
concurrent implementation of component-model-async. This can in turn be
used to set the max capacity on the table and limit the guest usage of
the table.

Closes #11552

* Adjust features

* Fix imports

show more ...

Refactor `wasi:http` headers' host representation (#12754)

* Refactor `wasi:http` headers' host representation

This commit is a follow-on/extension of #12748 and extends the changes
made for WASIp2

Refactor `wasi:http` headers' host representation (#12754)

* Refactor `wasi:http` headers' host representation

This commit is a follow-on/extension of #12748 and extends the changes
made for WASIp2 headers in #12652 to the WASIp3 implementation as well.
This is done through a number of refactorings to make the WASIp2 and
WASIp3 implementations more similar in terms of how they represent
headers. Changes here are:

* `FieldMap` now has its own dedicated module at the crate root instead
of intermingling with other WASIp2 types.
* `FieldMap` is now internally-`Arc`'d and is cheaply clonable.
`FieldMap` itself now tracks whether it's mutable or immutable (WASI
semantics) and doesn't need different wrappers in WASIp2 and WASIp3.
* Creation of an immutable `FieldMap` can be done without needing a size
limit. Flagging a `FieldMap` as mutable, however, requires a size limit.
* `FieldMap::set` was added to be a bit more efficient w.r.t. clones.
* `FieldMapError` is a new error type that covers all of the possible
error modes of operating with a `FieldMap`. Conversions from this to
WASIp{2,3} `header-error` types are now implemented as well.
* WASIp2 now flags `header-error` as a trappable-error-type, allowing
the use of `?` in implementing header functions (like WASIp3).
* Much of WASIp2's header implementation was refactored with `?`, moving
methods around, shuffling where headers are made vs `FieldMap`, some
minor idioms, etc.
* WASIp3 no longer uses `MaybeMutable` for headers and instead uses
`FieldMap` directly.

cc #12674

* Clippy warnings

show more ...

Fix lost wakeups with stdin and wasip3 (#12711)

I've been running some tests with wasip3 recently and I was running into
a situation where a program would read stdin, get some data, and then
stdin w

Fix lost wakeups with stdin and wasip3 (#12711)

I've been running some tests with wasip3 recently and I was running into
a situation where a program would read stdin, get some data, and then
stdin would be closed. The second read of stdin wouldn't get a wakeup
and would get stuck forever despite stdin being closed. I'm not 100%
sure what was happening but I'm highly suspect of the `Notify`-based
synchronization here as I know historically that's a tricky primitive to
work with. This applies a hammer and moves some lock scopes up a bit
further to avoid dealing with trickiness and instead ensure everything
proceeds in lockstep.

show more ...

wasip3: Limit random number generation by default (#12745)

This commit extends the random-related fixes of #12652 to WASIp3's
implementation of randomness-related interfaces.

cc #12674

Fix two security advisories. (#12652)

* Fix two security advisories.

This commit contains merged fixes for two security advisories in
Wasmtime:

* GHSA-852m-cvvp-9p4w
* GHSA-243v-98vx-264h

This in

Fix two security advisories. (#12652)

* Fix two security advisories.

This commit contains merged fixes for two security advisories in
Wasmtime:

* GHSA-852m-cvvp-9p4w
* GHSA-243v-98vx-264h

This introduces new knobs to Wasmtime to limit the scope of resources
that WASI implementations will allocate on behalf of guests. Unlike
backports to 41.0.x-and-prior these knobs all have default values which
are considered reasonable for hosts if they don't further tune them. The
following CLI knobs have been added:

* `-Smax-resources` - limits the total component-model resources a guest
can allocate in a table
* `-Shostcall-fuel` - a broad limit which enforces that at most this
amount of data will be copied from the guest to the host in any one
API call (e.g. `string` values can't be too big, `list<string>` can't
be quadratic, etc). This fuel is reset on each host function call.
* `-Smax-random-size` - the maximal size of the return value of the
`get-random-bytes` and `get-insecure-random-bytes` WASI functions.
* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields`
values to avoid infinitely buffering data within the host.

The `http` crate has additionally been updated to avoid a panic when
adding too many headers to a `fields` object.

Co-authored-by: Mark Bundschuh <[email protected]>
Co-authored-by: Pat Hickey <[email protected]>
Co-authored-by: Joel Dice <[email protected]>

* CI fixes

* Run rustfmt
* Fix wasi-common build

* Fix tests on 32-bit

* Fix nightly test expectations

prtest:full

---------

Co-authored-by: Mark Bundschuh <[email protected]>
Co-authored-by: Pat Hickey <[email protected]>
Co-authored-by: Joel Dice <[email protected]>

show more ...

[wasi-sockets] disallow sending unpermitted datagrams (#12641)

In #12629, I removed the enforcement of `outgoing-datagram-stream.check-send`
permits, which turned out to be incorrect according to [t

[wasi-sockets] disallow sending unpermitted datagrams (#12641)

In #12629, I removed the enforcement of `outgoing-datagram-stream.check-send`
permits, which turned out to be incorrect according to [the spec]. This
restores the enforcement to conform to the spec while still fixing the issue
addressed by the original PR.

[the spec]: https://github.com/WebAssembly/WASI/blob/41d0de898ec7568e032129156a3bc567d7ebea5d/proposals/sockets/wit/udp.wit#L256C1-L257C111

show more ...

fix `Pollable` impl for `OutgoingDatagramStream` (#12629)

* fix `Pollable` impl for `OutgoingDatagramStream`

Previously, `OutgoingDatagramStream` used its `send_state` field to determine
whether th

fix `Pollable` impl for `OutgoingDatagramStream` (#12629)

* fix `Pollable` impl for `OutgoingDatagramStream`

Previously, `OutgoingDatagramStream` used its `send_state` field to determine
whether the socket was ready for writing without necessarily polling the
`tokio::net::UdpSocket`. The underlying assumption was that a freshly-bound
socket would be immediately ready for writing, but that's not true for `tokio`.
`tokio` assumes a socket is not ready for _anything_ by default and relies on
e.g. `epoll` to tell it otherwise.

In practice, this meant the `Pollable::ready` impl for `OutgoingDatagramStream`
would resolve immediately for a fresh socket, leaving the guest to race with
`tokio`'s use of `epoll`. Usually, `tokio` won and all was well, but
occasionally it lost and the `OutgoingDatagramStream::send` call would return
`Ok(0)` (meaning "would block") leaving the guest confused since it was just
told that the socket was ready for writing.

This commit removes `SendState` entirely, relying exclusively on
`tokio::net::UdpSocket::ready` for the `Pollable` and `check_send`
implementations. As a side effect, we no longer attempt to prevent the guest
from sending more datagrams than `check_send` indicated since the number
returned by `check_send` is only a guess anyway, and `tokio` will push back if
it needs to. For `p3`, the whole `check_send`/`send` pattern is gone, so we
won't need to concern ourselves with it going forward.

Fixes #12612

* address review feedback

show more ...

wasi-sockets: Align stream tests with current P3 spec (#12600)

* Merge the `Connected`, `Receiving` & `P2Streaming` states into one

* Handle remote shutdowns gracefully. Before it would fail with `

wasi-sockets: Align stream tests with current P3 spec (#12600)

* Merge the `Connected`, `Receiving` & `P2Streaming` states into one

* Handle remote shutdowns gracefully. Before it would fail with `ErrorCode::Unknown` because EPIPE is not mapped

* Rewrite P3 TCP stream tests.

Aside from `test_tcp_read_cancellation`, all other tests were ported directly from their P2 counterpart. However, many of those P2 tests were testing semantics that are not relevant in P3. For example, they were testing the interaction between the old `tcp-socket::shutdown` method and its effect of the input/output streams. In P3, `shutdown` is called automatically when the stream is dropped

* `send & `receive` may be called successfully at most once.

* The streams and futures returned by `send` and `receive` should remain operational even after the socket that spawned them has been dropped.

* Clarify the difference between `send` and `send_result`

* Code cleanup

* Windows doesn't use BrokenPipe

show more ...

Connecting a TCP socket may update the local address (#12601)

Test that local address actually changes (#12595)

Unconditionally set SO_REUSEADDR (#12597)

chore: bump to wasi 0.3.0-rc-2026-02-09 (#12557)