Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lucet: Native WebAssembly Compiler and Runtime

fastly.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Lucet: Native WebAssembly Compiler and Runtime

#71

Post by pjmlp »

EamonnMR wrote: post #59
StavrosK wrote: post #48

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.

Sun and Oracle are pretty open to JVM vendors that don't play license games.

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#...

Additionally, Google could have bought Sun, and decided to see how it would burn instead.

Re: Lucet: Native WebAssembly Compiler and Runtime

#73

Post by writepub »

steveklabnik wrote: post #51
StavrosK wrote: post #48

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.

There's a subset of LLVM-IR that IS platform independent. PNacl, and many others rely on this.

The reason for wasm's victory is two found:

1. WASM is a stack based VM (LLVM IR is register based). Additionally, instructions chosen for wasm were inspired by the byte code representation used in existing JS JIT compilers. This meant that WASM almost fit effortlessly into the browser compiler pipeline. Compare this to adding the LLVM jit engine that the nacl philosophy uses. WASM was easier to implement. Stack based VMs are also (apparently) easier to sandbox, with a significantly lower attack surface

2. Firefox was philosophically against nacl/PNacl. Considering how Webview Safari eventually chose LLVM jit for it's JS JIT, as of 2019, PNacl would probably have won, given Microsoft (chromium edge), Google and Safari all support LLVM jit anyways.

Re: Lucet: Native WebAssembly Compiler and Runtime

#74

Post by dmitriid »

k__ wrote: post #31
steveklabnik wrote: post #28

Earlier quoted context omitted.

I'm not 100% sure what you mean by that final sentence, could you maybe elaborate?

Sure. Does WASM have better performance than the JVM? If not, could it have better performance theoretically? Is it more secure? How much slower than a regular binary would it be? etc.

WASM has a subset of a subset of a percentage of features that JVM provides.

It's basically a runtime for C/C++-like feature set [1], JVM has support for many of the features that are still on WASM's roadmap [2]

I would be very wary of any performance comparisons between WASM and ... pretty much anything else (except, possibly, bare C?).

[1] https://webassembly.org/docs/high-level-goals/

[2] https://webassembly.org/docs/future-features/

Re: Lucet: Native WebAssembly Compiler and Runtime

#75

Post by kryptiskt »

writepub wrote: post #73
steveklabnik wrote: post #51

Earlier 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.

There's a subset of LLVM-IR that IS platform independent. PNacl, and many others rely on this. The reason for wasm's victory is two found: 1. WASM is a stack based VM (LLVM IR is register based). Additionally, instructions chosen for wasm were inspired by the byte code representation used in existing JS JIT compilers. This meant that WASM almost fit effortlessly into the browser compiler pipeline. Compare this to add…

Safari ditched LLVM JIT for B3 a couple of years ago and V8 has never used it, so it was never really established for JS engines.

Re: Lucet: Native WebAssembly Compiler and Runtime

#76

Post by amelius »

phickey wrote: post #7
azakai wrote: post #5

> With Lucet, Fastly’s edge cloud can execute tens of thousands of WebAssembly programs simultaneously, in the same process , without compromising security. [emphasis mine] How does it handle Spectre, etc.?

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.

It would be interesting to see if you could compile+run+reproduce this:

https://github.com/flxwu/spectre-attack-demo

Re: Lucet: Native WebAssembly Compiler and Runtime

#78

Post by littlestymaar »

ridiculous_fish wrote: post #53
Rusky wrote: post #49

Earlier quoted context omitted.

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.

The issue with Unix process is that a process has the same rights than the user who ran that process. The design goal of WASI is to provide a capability-based system[1], so an attacker exploiting a buffer overflow wouldn't be able to access things that the original program wasn't supposed to.

[1]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

Re: Lucet: Native WebAssembly Compiler and Runtime

#79

Post by littlestymaar »

ridiculous_fish wrote: post #56
steveklabnik wrote: post #55

Earlier 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…

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

#80

Post by k__ »

dmitriid wrote: post #74
k__ wrote: post #31

Earlier quoted context omitted.

Sure. Does WASM have better performance than the JVM? If not, could it have better performance theoretically? Is it more secure? How much slower than a regular binary would it be? etc.

WASM has a subset of a subset of a percentage of features that JVM provides. It's basically a runtime for C/C++-like feature set [1], JVM has support for many of the features that are still on WASM's roadmap [2] I would be very wary of any performance comparisons between WASM and ... pretty much anything else (except, possibly, bare C?). [1] https://webassembly.org/docs/high-level-goals/ [2] https://webassembly.org/d…

If I understood this correctly, that's what the Fastly people do. They compare it to bare C binaries and besides string-performance, it holds up good.
Post reply on HN