Pyodide implemented JSPI shadow stack suspend/resume semantics quite comprehensively in https://blog.pyodide.org/posts/jspi-with-c-runtime/.
I'm now seeing similar issues for Rust and JSPI, and have been prototyping some (unfinished) ideas in https://github.com/guybedford/jspi - where as far as I can tell Emscripten is not automatically handling the shadow stack save and restore operations, so that JSPI will lead to stack corruption in Rust per Hood's blog post scenario.
In addition, wasm-bindgen is about to land support for JSPI with it's own shadow stack handling in wasm-bindgen/wasm-bindgen#5193 and to get these approaches to interoperate well requires falling on strong conventions.
All conventions come down to needing a stack top though for the shadow stack suspension range. And the stack top is not easy to get since by the time you call emscripten_stack_get_current() you're always deep into the entry point Rust wrapper code.
We can't use the stack base, because WebAssembly.promising functions can be called with arbitrary non-JSPI stack depth, so this core feature missing to integrate this well into Rust seems to me to be a emsripten_stack_get_promising_top() for the current WebAssembly.promising which Emscripten in theory would know about.
Unless I'm missing something, as far as I can tell this leaves us with two options for Rust JSPI soundness:
- Either fully implement the shadow stack save/restore work at the compiler / toolchain level (instead of as a library)
- Expose a new JSPI-specific
emscripten_stack_get_promising_top() primitive
I'd be interested to hear what others think about how to handle the problems here.
Pyodide implemented JSPI shadow stack suspend/resume semantics quite comprehensively in https://blog.pyodide.org/posts/jspi-with-c-runtime/.
I'm now seeing similar issues for Rust and JSPI, and have been prototyping some (unfinished) ideas in https://github.com/guybedford/jspi - where as far as I can tell Emscripten is not automatically handling the shadow stack save and restore operations, so that JSPI will lead to stack corruption in Rust per Hood's blog post scenario.
In addition, wasm-bindgen is about to land support for JSPI with it's own shadow stack handling in wasm-bindgen/wasm-bindgen#5193 and to get these approaches to interoperate well requires falling on strong conventions.
All conventions come down to needing a stack top though for the shadow stack suspension range. And the stack top is not easy to get since by the time you call
emscripten_stack_get_current()you're always deep into the entry point Rust wrapper code.We can't use the stack base, because
WebAssembly.promisingfunctions can be called with arbitrary non-JSPI stack depth, so this core feature missing to integrate this well into Rust seems to me to be aemsripten_stack_get_promising_top()for the currentWebAssembly.promisingwhich Emscripten in theory would know about.Unless I'm missing something, as far as I can tell this leaves us with two options for Rust JSPI soundness:
emscripten_stack_get_promising_top()primitiveI'd be interested to hear what others think about how to handle the problems here.