Now 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.
Now 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.
I think wasm's memory safety is weaker than JVM. wasm's checking occurs at control flow points and the linear memory boundary, but does not extend down to individual objects. For example arrays are not bound checked in wasm.
The JVM and wasm have completely different memory safety stories on the inside of the sandbox, because wasm can run arbitrary C, so it has to cope with that somehow. But the thing Steve is pointing out is that they're equivalent from the outside , where neither can corrupt the host environment.
But this is true of an ordinary Unix process too, via virtual memory. A Unix process can’t corrupt the kernel or other processes. But in practice there’s still a lot you can do with a buffer overflow vulnerability.
I think wasm's memory safety is weaker than JVM. wasm's checking occurs at control flow points and the linear memory boundary, but does not extend down to individual objects. For example arrays are not bound checked in wasm.
Wasm doesn't really have "arrays", so I don't think wasm checking them would really make sense. I guess you could argue that this is a distinction without a difference. You still won't get memory unsafety, which in my mind, is the higher order bit. YMMV of course.
You do get memory unsafety. OpenSSL compiled to wasm would still be vulnerable to Heartbleed. The JVM would prevent it.
Wasm doesn't really have "arrays", so I don't think wasm checking them would really make sense. I guess you could argue that this is a distinction without a difference. You still won't get memory unsafety, which in my mind, is the higher order bit. YMMV of course.
You do get memory unsafety. OpenSSL compiled to wasm would still be vulnerable to Heartbleed. The JVM would prevent it.
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.
You do get memory unsafety. OpenSSL compiled to wasm would still be vulnerable to Heartbleed. The JVM would prevent it.
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 provides.
We have a security document that addresses the big picture, and this specific concern as well: https://github.com/fastly/lucet/blob/master/SECURITY.md#cave... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.
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.
So currently it does compromise on security? Seems extremely misleading to claim any security if you are just currently ignoring the last years worth of major security issues.
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.
Now 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.
I suspect that the JVM isn't an option since Oracle v Google showed that it's not as open as we'd hoped and nobody wants to try the same trick with .NET.
Now 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.
Every reliable complex system started as a reliable simple system and evolved.