Fix lost wakeups with stdin and wasip3 (#12711)I've been running some tests with wasip3 recently and I was running intoa situation where a program would read stdin, get some data, and thenstdin w
Fix lost wakeups with stdin and wasip3 (#12711)I've been running some tests with wasip3 recently and I was running intoa situation where a program would read stdin, get some data, and thenstdin would be closed. The second read of stdin wouldn't get a wakeupand would get stuck forever despite stdin being closed. I'm not 100%sure what was happening but I'm highly suspect of the `Notify`-basedsynchronization here as I know historically that's a tricky primitive towork with. This applies a hammer and moves some lock scopes up a bitfurther to avoid dealing with trickiness and instead ensure everythingproceeds in lockstep.
show more ...
Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis in
Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis introduces new knobs to Wasmtime to limit the scope of resourcesthat WASI implementations will allocate on behalf of guests. Unlikebackports to 41.0.x-and-prior these knobs all have default values whichare considered reasonable for hosts if they don't further tune them. Thefollowing 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 whenadding 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 expectationsprtest:full---------Co-authored-by: Mark Bundschuh <[email protected]>Co-authored-by: Pat Hickey <[email protected]>Co-authored-by: Joel Dice <[email protected]>
Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our fl
Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code
Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)* Migrate wiggle and wiggle generate to `wasmtime::error`* Fix testing `wiggle` and `wiggle-test` in isolationWhen doing plain old `cargo te
Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)* Migrate wiggle and wiggle generate to `wasmtime::error`* Fix testing `wiggle` and `wiggle-test` in isolationWhen doing plain old `cargo test -p wiggle` (or `wiggle-test`) the test wouldfail due to linking errors because Wasmtime's `std` cargo feature (and maybeothers) wasn't being enabled. The crate's tests would pass when run as part ofthe whole workspace, however, because of cargo feature resolution and othercrates that enabled the necessary features, which is why CI is green.* Remove direct anyhow dependency in wiggle-test* Migrate wasi-nn to `wasmtime::error`* Migrate wasi-keyvalue to `wasmtime::error`* Migrate wasi-io to `wasmtime::error`* Migrate wasi-http to `wasmtime::error`* Migrate wasi-config to `wasmtime::error`* Migrate wasi-common to `wastime::error`This is another interesting one because wasi-common is used internally toWasmtime but also by other projects. Therefore, rather than using`wastime::error::*` and making `wasmtime` a hard dependency, we use just`wasmtime_environ::error`.* cargo fmt* Migrate wasmtime-wasi to `wasmtime::error`
wasip3: Update std{out,err} implementation (#11618)* wasip3: Update std{out,err} implementationMatch the WASIp2 stdio implementation and "lie" about stdio actuallybeing async. Instead of using T
wasip3: Update std{out,err} implementation (#11618)* wasip3: Update std{out,err} implementationMatch the WASIp2 stdio implementation and "lie" about stdio actuallybeing async. Instead of using Tokio's primitives use the `std::io`primitives which will block the current program while the output isproduced. This matches WASIp2 semantics and we always have the option ofmaking this more async in the future (or even have it as a runtimeflag). This avoids the need to call `poll_flush` in stdiounconditionally in the `wasi:cli` implementation which didn't feel quiteright.* One fewer run for WindowsIt's got a shorter command line length limit
Share stdio implementations in WASIp{2,3} (#11368)* Share stdio implementations in WASIp{2,3}This commit is a refactoring of the`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more co
Share stdio implementations in WASIp{2,3} (#11368)* Share stdio implementations in WASIp{2,3}This commit is a refactoring of the`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more code. Thegeneric trait object that represents stdio now has the ability toacquire either a p2 stream or an async-based stream. The acquisition ofp2 has a default implementation so in the future this can be primarily`Async{Read,Write}`-based.Many trait implementations and types and such were all consolidatedtogether into the `wasmtime_wasi::cli` module. One-off implementationsin p2/p3 are now shared in one location and `WasiCtxBuilder` no longerneeds any generics for different stdio streams.Functionally this necessitated the addition of `Async{Read,Write}`implementations for some "base" implementations of stdio primitives.Implementations were mostly trivial except for a few adapters which weresignificantly more complicated, namely the `Async{Read,Write}Stream`adapter which converts a single `Async{Read,Write}` into the stdio of acomponent.Finally the stdin implementation for p3 was refactored to avoid use of`tokio::io::stdin()` which generally isn't safe to use. It's replacedwith a custom `AsyncRead` using the worker thread implementation we havein the crate already.Eventually I hope to remove the distinction between `p{2,3}::WasiCtx`and have these be the same type. This will make it nicer to only have asingle `WasiView` trait and additionally make it easier tosimultaneously implement all of WASIp{1,2,3}.* Fix build of C API* Fix build of `wasmtime serve`