Wasmtime GitHub notifications bot (Feb 03 2021 at 20:06): Wasmtime GitHub notifications bot (Feb 03 2021 at 20:06):triage: I am not sure if this should be closed or not. Stack probes are implemented but using a separate stack for wasm isn't.
Wasmtime GitHub notifications bot (Feb 03 2021 at 20:14):cfallin commented on Issue #5:
Providing an option for stack-switching under wasmtime would be worthwhile; I'm pretty sure @alexcrichton is already thinking about this in the context of async work?
Wasmtime GitHub notifications bot (Feb 03 2021 at 21:04):alexcrichton commented on Issue #5:
Since this was written Wasmtime and cranelift have been updated with multiple strategies for limiting stack usage. Cranelift retains support for Rust-style
__probestackstack probing but Wasmtime has moved to Cranelift's support for stack quotas. In this mode wasm code can be assigned to consume at most a fixed amount of stack space on the wasm stack. This isn't stack switching, but https://github.com/bytecodealliance/wasmtime/issues/5#issuecomment-391150935 seems to indicate that stack switching wasn't what was desired in the end (this is a 3-year-old issue after all).On the topic of stack switching the upcoming support for async in Wasmtime does indeed implement this. The purpose for that, though, is suspendable stacks rather than any sort of stack allocation and/or protection. That's all entirely separate from Cranelift, though.
I'm going to go ahead and close this though since I think the spirit of the issue (limiting wasm stack without running the risk of clobbering the native stack too much) is done. If cranelift-supported stack switching is still desired then I think it's probably best if a fresh issue is opened with more specifics targeted at today's state-of-being.
Wasmtime GitHub notifications bot (Feb 03 2021 at 21:04):alexcrichton closed Issue #5:
If SIP really does isolate, then perhaps wasm code shouldn't be able to smash the native stack.
Currently Cretonne expects wasm and native code to share the stack so for example wasm code can call an imported native function.What I'd like:
- SIP wasm environment/code runs using its own stack (sized to fit, mmap guarded).
- ability to switch stacks when making wasm -> native calls, and native->wasm calls.
If imported fn return types are i32, then perhaps this could be marshalled using a register, and a few assembler instructions could take care of the return value and prologue/epilogue modifying the stack pointer.
Is this a crazy idea?
Thanks!
Last updated: Oct 23 2024 at 20:03 UTC