Re:Lucet: Native WebAssembly Compiler and Runtime
by littlestymaar on Friday March 29, 2019 @07:46AM
(#19520759)
The goal is to allow existing C code to run, so in the end you'll need the same freedom when it comes to memory access. The difference between this and plain process is that the sandbox uses a capability-based security model, instead of giving all the user's rights to the process [1].
[1]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
Re:Lucet: Native WebAssembly Compiler and Runtime
by hawski on Friday March 29, 2019 @12:03PM
(#19522808)
There is not a mention of memory safety in this post. It's very confusing term in this context. I wouldn't call running a binary with syscall interception (with qemu for example) as "memory safe".
Re:Lucet: Native WebAssembly Compiler and Runtime
by nindalf on Friday March 29, 2019 @02:45AM
(#19519633)
If the memory safety of your own code is a high priority, consider writing in Rust. If you’re trying to get a C codebase to run everywhere, then that’s fine too but it seems unrealistic to expect the wasm run time to magically make it memory safe.
edit: I guess this viewpoint makes sense for the use case of "thousands of wasm programs in the same process." They are protected from each other, in a sense qualitatively the same as Unix processes. This is still a much weaker guarantee than the JVM provides.