3 ms·
A proper solution for this problem will also help with the WebGPU API. Mapping a GPU resource returns a JS array view, which currently requires a memcpy-roundtr
by flohofwoe 4y ago
A proper solution for this problem will also help with the WebGPU API. Mapping a GPU resource returns a JS array view, which currently requires a memcpy-roundtrip into and out of the WASM heap (for instance see here in Emscripten's WebGPU shim: https://github.com/emscripten-core/emscripten/blob/37aa752ebec8e6997c21578a37603d188dc1989c/src/library_webgpu.js#L1871-L1875 https://github.com/emscripten-core/emscripten/blob/37aa752eb...).
Ideally the array view could either be mapped directly into the WASM heap, or at least would be accessible from the C/C++/Rust side with a special pointer type (maybe WASM should get a segmented address space like back in the 286 days lol).
- pjmlp 4y agoWhich most likely will never happen, given the security constraints of browsers.
- flohofwoe 4y agoIt really wouldn't add any additional attack surface compared to accessing the same data through Javascript though.
- kevingadd 4y agoFor once, this would not expose any additional attack surface other than the inevitable bugs in the C++ implementation of it that gets shipped in all the browsers.
- kevingadd 4y agoThere are stray references to the concept of multiple address spaces (or 'memories') in the wasm spec at present, and I recall at one point you may have always been passing 'memory #0' to your load/store opcodes before it was dropped from 1.0. It looks like people are still working on that as the solution. https://github.com/WebAssembly/multi-memory https://github.com/WebAssembly/multi-memory > Add a memory index to all memory-related instructions. > Loads and stores have the memop field, in which we can allocate a bit indicating a memory index immediate in the binary format. > All other memory instruction already have a memory index immediate (which currently has to be 0).