Earlier quoted context omitted.
It is possible to corrupt data on the stack due to out of bounds.
Yes, bugs can always exist.
Not sure what you mean by that, but probably not that stack corruption is a necessary evil of any language.
Lucet: Native WebAssembly Compiler and Runtime
61–70 of 99 posts
Re: Lucet: Native WebAssembly Compiler and Runtime
#62Now that I see this, a question comes to mind: Why do we have yet another VM? Why didn't browsers just implement LLVM? Is it the sandbox? Don't get me wrong, I'm excited to see wasm spread, but the question does cross my mind.
Google’s PNaCl was essentially portable LLVM.
Re: Lucet: Native WebAssembly Compiler and Runtime
#63Earlier quoted context omitted.
Thanks for asking! I'm Syrus, I started the Wasmer project. Lucet just released, but so far these are the current differences as far as I can tell: 1. Wasmer is meant to execute any WebAssembly file and run on any platform. Wasmer currently runs on Mac, Linux and Windows. Lucet only works on Linux at the moment, since its main goal is to be executed on Fastly's infra. 2. We support multiple compiler backends: dynasm,…
That is a good summary! Lucet's runtime has a C API as well. We haven't created bindings to languages beyond C and Rust, but it should be pretty straightforward using the C API.
Thanks for the correction! And congrats for the great work
Re: Lucet: Native WebAssembly Compiler and Runtime
#64Earlier quoted context omitted.
LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform independent, and was never intended for this use-case. It is also significantly more complex than wasm, which is partially why wasm ended up working. Start small, add over time: that's the way of the web platform.
Every reliable complex system started as a reliable simple system and evolved.
"Worse Is Better", but describing it from the other side.
Re: Lucet: Native WebAssembly Compiler and Runtime
#65Earlier quoted context omitted.
Given that in-process sandboxing in the face of spectre is currently an unsolved problem, how do you plan on actually addressing it? The only established mitigation at this point is to just use process isolation, so what's the plan or is there just not one?
Even interprocess isolation is not a solved problem in the face of SMT (hyperthreading), so yes- there is none. You simply can’t deliver these kinds of shared metal products and defend against cache timing attacks. You also can’t deliver these kinds of products at this price and be profitable without sharing metal, so here we are. If you care about being isolated, you can’t share hardware- simple as that.
There's a huge difference in viability & mitigations here, though. In a shared metal system a portsmash attack isn't likely to be practically viable, and worst case is sched affinity or similar is used to just firewall off processes from co-inhabiting the same physical core. Kernel scheduler could even do this in a clever way, this has a very clear path to which it is basically fully mitigated.
So all signs point to shared metal still being viable security-wise, with mitigations either already deployed or pretty straightforward. Shared hardware will remain totally fine.
Shared-process, though, nobody is really talking about making that viable from a security perspective.
Re: Lucet: Native WebAssembly Compiler and Runtime
#66Earlier quoted context omitted.
It also compromises on resource abuse: "lucet does not currently provide a framework for protecting against guests that consume excessive CPU time (e.g. via an infinite loop). These protections must be provided by the host environment." I'm not sure how you're supposed to handle that, either, given host environment usually does limiting at a process granularity but this doesn't use multiple processes.
Most OSes have a way to specify priority for a given thread.
Priority yes, but that's barely useful. cgroups, rlimits, cpulimit, etc... are far more useful here, and are all per-process.
Re: Lucet: Native WebAssembly Compiler and Runtime
#67Now that I see this, a question comes to mind: Why do we have yet another VM? Why didn't browsers just implement LLVM? Is it the sandbox? Don't get me wrong, I'm excited to see wasm spread, but the question does cross my mind.
LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform independent, and was never intended for this use-case. It is also significantly more complex than wasm, which is partially why wasm ended up working. Start small, add over time: that's the way of the web platform.
More importantly LLVM-IR isn't stable. It's intended to just be an intermediate between the bundled front-ends & back-ends. There's some limited compatibility provided ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compa... ), but nothing close to suitable for an actually persisted format.
Re: Lucet: Native WebAssembly Compiler and Runtime
#68Earlier quoted context omitted.
Most OSes have a way to specify priority for a given thread.
Priority yes, but that's barely useful. cgroups, rlimits, cpulimit, etc... are far more useful here, and are all per-process.
You can use timer_create to arrange to deliver a signal after some amount of CPU time elapsed, then terminate the sandbox from the signal handler.
Re: Lucet: Native WebAssembly Compiler and Runtime
#69Re: Lucet: Native WebAssembly Compiler and Runtime
#70Earlier quoted context omitted.
Please re-read what Rusky said; the point is about the boundary. Yes, wasm programs can mess up their own memory. That’s not what I’m talking about. I should be more clear about this in the future though, thanks.
I don't understand this point. We don't say that C is memory safe because of the kernel boundary, even though this boundary does provide important safety guarantees. 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 pro…
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.