I was looking into module poisoning for Wasm and saw that apparently WASI already implements something that prevents module re-entrance.
Following the code from Rustc into wasi-libc
I can't find anything in this regard. Is this part of the spec and handled by the execution environment or how exactly does WASI deal with this?
WASI 0.2 targets the Component Model, and one of the proposed invariants in the Component Model MVP prevents re-entrance.
See https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#component-invariants
The issue you linked also links to this issue discussing the differences between targeting plain WASM versus the Component Model: https://github.com/rustwasm/wasm-bindgen/issues/3687
I take it then that WASI without the component model proposal does not prevent re-entrance?
Isn't that something Rust should care about as well?
The idea here is that if Rust Wasm implements module poisoning it can extend that to WASI (without the component model proposal) as well.
Yes the wasm32-wasip1
/wasm32-wasi
targets would need reentrance protection, but the wasm32-wasip2
targets could be exempted. I'm not aware of any reentrance preotection in wasi-libc myself.
WASIp1 / core modules don't really have the ability to distrust the outside environment. They export their linear memory, which means the outside world could trivially induce "Undefined Behavior" in the code inside the module, and there's no way to stop it.
Core modules inherently have to have an unenforced convention with the outside world, and "don't reenter me" can be part of that convention.
Last updated: Dec 23 2024 at 12:05 UTC