11–20 of 79 posts
Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?
2. Some platforms prohibit creating new executable pages, which prevents JITing.
3. Memory savings!
The motivation for WebAssembly rather than plain ARM or x86 assembly = portability, security. It would be interesting to see how this is designed for security in mind.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
The motivation for WebAssembly rather than plain ARM or x86 assembly = portability, security. It would be interesting to see how this is designed for security in mind.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
Needs to be memory safe otherwise a wasm program can execute arbitrary code, access memory that it should not, etc.
> Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code
WASM compiled to a novel bytecode format aimed at efficient interpretation.
> Commonly occurring sequences of operations can can also be optimized into a "fused" operation.
Peephole optimizations producing fused opcodes, makes sense.
> In M3/Wasm, the stack machine model is translated into a more direct and efficient "register file" approach
WASM translated to register-based bytecode. That's awesome!
> Since operations all have a standardized signature and arguments are tail-call passed through to the next, the M3 "virtual" machine registers end up mapping directly to real CPU registers.
This is some black magic, if it works!
Earlier quoted context omitted.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
Sandboxing is trivial, because you can cover all paths to the outside world.
The motivation for WebAssembly rather than plain ARM or x86 assembly = portability, security. It would be interesting to see how this is designed for security in mind.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table.
2. Calls out of the sandbox are also table based.
3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares.
The result is something which may become internally inconsistent (can Heartbleed) but cannot perform arbitrary accesses to host memory.
Earlier quoted context omitted.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
WASM has a sandboxing model. The idea is: 1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table. 2. Calls out of the sandbox are also table based. 3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares. The result is something whi…
The motivation for WebAssembly rather than plain ARM or x86 assembly = portability, security. It would be interesting to see how this is designed for security in mind.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
Earlier quoted context omitted.
WASM has a sandboxing model. The idea is: 1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table. 2. Calls out of the sandbox are also table based. 3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares. The result is something whi…
How is that different from CLR or JVM?
JVM and WASM both have statically-verifiable control flow. No wild jumps, no executable stacks, etc. Phew.
Arrays and pointer arithmetic are a big difference. WASM has a big linear memory block, and instructions may access arbitrary locations within it - the runtime performs bounds checking only at the edges. So your `sprintf` can still overflow the buffer, and smash the stack's data, but can't affect the host, or the control flow.
JVM goes further: it prohibits pointer arithmetic and pushes array accesses down into the instruction stream. To access a JVM array, you must provide the array reference itself, and the runtime will perform bounds checking using the length.
The JVM approach gives you better runtime safety - no Heartbleed! The WASM approach is lower-level and is more easily adapted to existing system languages: C++, Rust, other LLVMites.
Earlier quoted context omitted.
Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.
WASM has a sandboxing model. The idea is: 1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table. 2. Calls out of the sandbox are also table based. 3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares. The result is something whi…