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

InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

innative.dev

Post reply on HN
Print view View original

11–20 of 96 posts

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#11

Post by kbumsik »

techntoke wrote: post #6
mises wrote: post #3

"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.

Because WASM is already bad for user security, they want to make it worse.

> WASM is already bad for user security

Any source?

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#12

Post by MBCook »

sanxiyn wrote: post #7
mises wrote: post #3

"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java.

What extra benefit does this provide, except avoiding Oracle?

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#13

Post by FullyFunctional »

ryacko wrote: post #2

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about whether our favorite language compiles to it." WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.

I used to resort to binary translation for experimental CPU projects, but WASM looks like a much better starting point. The controversial lack of arbitrary control flow is a massive advantage for me.

Writing an complete compiler backend/asm/ld is a significant undertaking which is only worthwhile for very stable architectures.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#14

Post by jchw »

MBCook wrote: post #12
sanxiyn wrote: post #7

Earlier quoted context omitted.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?

Oh good point, we can just embed the JVM into browsers instead. WebAssembly’s cancelled everyone!

Jokes aside, why are you comparing these two very different virtual machines? WASM is a general purpose VM, JVM is not. For example, you won’t find a Rust JVM target any time soon. (Not to suggest that the JVM is strictly limited to Java, it isn’t obviously, but it is not nearly as suited to being a target for lower level languages. Also, the security model is very different.)

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#15

Post by alangpierce »

MBCook wrote: post #12
sanxiyn wrote: post #7

Earlier quoted context omitted.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?

Wasm bytecode is lower-level than JVM bytecode, so I believe it's a much easier compilation target for a variety of source code languages.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#16

Post by snek »

MBCook wrote: post #12
sanxiyn wrote: post #7

Earlier quoted context omitted.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?

We already tried JVM in browsers, remember java applets? I sure remember the security and compatibility problems :)

WASM has been designed from the ground up with portability, security, and stability in mind. It is also a lower target than JVM bytecode, which makes it more suitable to represent languages like rust and go. It has also been designed to take advantage of the sandboxed JIT engines that browsers already have for running javascript. Additionally, WASM is an open standard that anyone can contribute to, which is something that is greatly valued on the web.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#17

Post by writepub »

mises wrote: post #3

"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.

Because LLVM IR is CPU-Arch specific. For instance, IR for x86 cannot be used on ARM CPUs, which is also the reason why Apple's bitcode representation intended to make apps portable, doesn't cross the iOS (ARM) MacOs (x64) boundary, unless ARM ISA emulation is happening in Mac (like in Marzipan?)

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#18

Post by _nhynes »

mises wrote: post #4
ryacko wrote: post #2

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about whether our favorite language compiles to it." WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.

Literally the whole point of WASM is fast, sandboxed code. It's not a language, it's an LLVM target. So why turn LLVM IR into a native binary? It's basically the same thing as "native wasm", whatever that would mean. "Native wasm" is just JITed bytecode. Either that, or you're turning it into a normal binary, in which case, why even use WASM?

You get a bit of safety because Wasm programs have statically validated function calls and operate only within linear memory. If there are no bugs in the stdlib or the bytecode compiler, then the host is still sandboxed from the module even without virtual memory.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#19

Post by techntoke »

kbumsik wrote: post #11
techntoke wrote: post #6

Earlier quoted context omitted.

Because WASM is already bad for user security, they want to make it worse.

> WASM is already bad for user security Any source?

You are running a binary and you have to trust the sandbox. Hasn't worked so well for web browsers even with JavaScript.

Re: InNative: Run WebAssembly Outside the Sandbox at 95% Native Speed

#20

Post by Arbalest »

MBCook wrote: post #12
sanxiyn wrote: post #7

Earlier quoted context omitted.

WebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.

We already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?

Besides the point about already trying out Java Applets, Why would you dismiss the Oracle avoidance? Oracle recently moved with Java to show a strong preference to monetising it, whereas lots of people on the web cannot afford any licencing just to be able to make stuff to run on the client machine. It is actually a very strong feature of it.
Post reply on HN