| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This fixes an issue we had with wasm-wasi-component failing to load
components with
2024/11/06 21:08:50 [alert] 107196#107196 failed to create initial state
Caused by:
0: failed to compile component
1: WebAssembly translation error
2: Invalid input WebAssembly code at offset 15936: zero byte expected
Which was a symptom of
<https://github.com/bytecodealliance/wasmtime/issues/9130>
Closes: https://github.com/nginx/unit/issues/1477
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Bumps <https://github.com/bytecodealliance/wasmtime> from 24.0.0 to
24.0.1.
Fixes:
a runtime crash when combining tail-calls with host imports that
capture a stack trace or trap. GHSA-q8hx-mm92-4wvg
a race condition could lead to WebAssembly control-flow integrity and
type safety violations. GHSA-7qmx-3fpx-r45m
Link: Release notes <https://github.com/bytecodealliance/wasmtime/releases>
Link: Changelog <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-some-possible-changes.md>
Link: Commits <https://github.com/bytecodealliance/wasmtime/compare/v24.0.0...v24.0.1>
Signed-off-by: dependabot[bot] <support@github.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
While the C based wasm language module inherits the process environment
the Rust based wasm-wasi-component language module did not.
One upshot of this is that with wasm-wasi-component you don't get access
to any environment variables specified in the Unit configuration.
wasm-wasi-component was based on wasmtime 17.0.0. This capability wasn't
added to the wasmtime-crate until version 20.0.0.
Now that wasm-wasi-component has been updated to a newer wasmtime-crate
we can enable this functionality.
Closes: https://github.com/nginx/unit/issues/1312
[ Commit message - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Ava Hahn <a.hahn@f5.com>
|
|
Bumps <https://github.com/rustls/rustls> from 0.21.10 to 0.21.11.
"This release corrects a denial-of-service condition in
rustls::ConnectionCommon::complete_io(), reachable via network input. If
a close_notify alert is received during a handshake, complete_io() did
not terminate. Callers which do not call complete_io() are not
affected."
The wasm-wasi-component language module is not effected by this as it
doesn't handle client connections, Unit does.
Link: Release notes <https://github.com/rustls/rustls/releases>
Link: Commits <https://github.com/rustls/rustls/compare/v/0.21.10...v/0.21.11>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Bumps h2 <https://github.com/hyperium/h2> from 0.4.2 to 0.4.4.
Limit number of CONTINUATION frames for misbehaving connections.
Link: Changelog <https://github.com/hyperium/h2/blob/master/CHANGELOG.md>
Link: Commits <https://github.com/hyperium/h2/compare/v0.4.2...v0.4.4>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Liam reported a problem when trying to restart wasm-wasi-component based
applications using the /control/applications/APPLICATION_NAME/restart
endpoint.
The application would become unresponsive.
What was happening was the old application process(es) weren't
exit(3)ing and so while we were starting new application processes, the
old ones were still hanging around in a non-functioning state.
When we are terminating an application it must call exit(3).
So that's what we do. We use the return value of nxt_unit_run() as the
exit status.
Due to exit(3)ing we also need to now explicitly handle the return on
error case.
Reported-by: Liam Crilly <liam@nginx.com>
Fixes: 20ada4b5c ("Wasm-wc: Core of initial Wasm component model language module support")
Closes: https://github.com/nginx/unit/issues/1179
Tested-by: Liam Crilly <liam@nginx.com>
Tested-by: Danielle De Leo <d.deleo@f5.com>
Co-developed-by: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Bumps mio <https://github.com/tokio-rs/mio> from 0.8.10 to 0.8.11.
Fixes receiving IOCP events after deregistering a Windows named pipe.
Not that that effects Unit...
Link: <https://github.com/nginx/unit/security/dependabot/1>
Link: Changelog <https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md>
Link: Commits <https://github.com/tokio-rs/mio/compare/v0.8.10...v0.8.11>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
It seems we do want to track this thing. This is just the latest version
that cargo had generated for me.
Cc: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
With the initial port to wasmtime 17 we could no longer use the
'reactor' adaptor but had to switch to the more restrictive 'proxy'
adaptor.
This meant amongst other things (probably) we could no longer access the
filesystem.
Thanks to Joel Dice for pointing out the fix.
With this we can go back to using the 'reactor' adaptor again and things
are back to working as before.
It's worth noting that you can use either the 'proxy' or 'reactor'
adaptor depending on your requirements.
Cc: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This brings WASI 0.2.0 support.
Link: <https://github.com/bytecodealliance/wasmtime/releases/tag/v17.0.0>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
When Unit receives a request, if the body of that request is greater
than a certain amount (16KiB by default) then it is written to a
temporary file.
When a language module goes to read the request body in such situations
it will end up using read(2).
The wasm-wasi-component language module was failing to properly read
request bodies of around 2GiB or more.
This is because (on Linux at least) read(2) (and other related system
calls) will only read (or write) at most 0x7ffff000 (2,147,479,552)
bytes, this is the case for both 32 and 64-bit systems.
Regardless, it's probably not a good idea doing IO in such large chunks
anyway.
This patch changes the wasm-wasi-component language module to read the
request buffer in 32MiB chunks (this matches the original 'wasm'
language module).
We are still limited to a 4GiB address space and can only upload files a
little under 4GiB.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Run from the repository root like
$ rustfmt --edition 2021 src/wasm-wasi-component/src/lib.rs
Also manually fix up some overly long comments.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is the work of Alex Crichton.
This is written in Rust. The problem is that there is currently no
support on the C side of things for the component model, which is the
point of this module.
It talks to Unit via automatically generated bindings.
I've (Andrew) just made some minor tweaks to src/lib.rs, build.rs &
Cargo.toml to adjust some paths, adjust where we get the language module
config from and the module name and where it's located in the source
tree,
I also removed and disabled the tracking of the Cargo.lock file, this is
constantly changing and not tracking it seems right for 'libraries' and
dropped the README's...
Other than that I have tried to leave his work intact, subsequent
commits will make some larger changes, but I didn't want to intermix
them with Alex's work.
One such commit will update the module to use wasmtime 17 which brings
WASI 0.2.0 support.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
