Hacker News Reader

Comment by mises | Hacker News Reader

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?

View on HN

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.

No, it’s not possible to statically validate that addresses are within linear memory. WebAssembly implementations do runtime memory access checks (either with explicit if checks before some loads and stores or with virtual memory configuration).

> it’s not possible to statically validate that addresses are within linear memory

It might just be me, but I don't think this is what the parent comment said.

“Statically validated” AFAIU means there are no runtime checks.

E. g. WASM stack local variables and globals are statically validated. Compiler can translate loads and stores to locals and globals to simple movs. There are no additional runtime checks, no overhead. Unlike linear memory.

As far as I could parse that comment, it's saying that function calls are statically validated and that memory is linear. Not that all memory accesses can be statically validated.

Given WASM's 32 bit address space, you can effectively validate a programs memory access statically, with a one time initialization in virtual memory - for instance if you'd like to restrict all WASM memory to 64MB, you can allocate/map it to the top of a 4GB virtual address space, effectively giving it a start address of 4GB-64MB.

Since OS/process virtual memory bound checking is handled by the hardware, the one time setup above will lock down WASM memory access to within the 64MB, without software runtime overheads.

This is exactly why WASM memory was picked to be linear (unlike virtual memory that can have holes in continuity)

Fair point, author indeed said that function calls are statically validated, but did not say linear memory access is statically validated.

This phrase “host is still sandboxed from the module even without virtual memory” confused me. Because technically any interpreter (even qemu) can run without virtual memory with more or less expensive runtime checks.

https://en.wikipedia.org/wiki/Java_processor

x86 is translated to micro-ops in the processor. Why use x86 if you don't need a half-carry flag?

" It's not a language"

It sure looks like a language to me, like some sort of assembly language.

https://webassembly.org/getting-started/advanced-tools/

https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo...

granted this is a textual representation (very useful in certain circumstances) but that is semantics. Having done plenty of assembly, I don't see a huge distinction here.

LLVM IR is not architecture-independent. It encodes architecture and ABI assumptions, and is not portable.

Also, this is not "JITed bytecode", it is compiled AOT.

The PNaCL and Apple's variants are architecture independent.

Well. They pick an architecture and stick with it, more like. But one is dead in favour of WebAssembly and the other is an internal format.

It doesn't change the fact that they do exist.

PNaCL died in favour of WebAssembly due to politics.

With Chrome today's might, the decision would most likely be a different one.

Reply on news.ycombinator.com