4 ms·

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading an

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAssembly application call-stacks are maintained by the JS VM, outside the memory addressable by the application, which reduces the exploitability of application bugs. (Though, again like asm.js and unlike PNaCl, the compiler is trusted.) ---

dullgiulio 9y ago
I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.
- satysin 9y ago
  I think they are talking about something like the Ken Thompson hack? http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
- roca 9y ago
  It means that a bug in the compiler/optimizer could allow WebAssembly code to escape its sandbox. This is a real issue, but o some extent this extra attack surface is mitigated because vendors are reusing JS compiler backends that are already part of the TCB.
- foxylad 9y ago
  Add extraneous code?
- fpoling 9y ago
  Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.
  - amelius 9y ago
    This. Webassembly is an overcomplication. But, as always, I suppose we have to live with it.
  - ascheidecker 9y ago
    It would be possible to leverage a simple machine code verifier similar to NaCl's in a WebAssembly backend. Nobody does it right now, but there's been some work on taking WebAssembly as input to their Subzero PNaCl->NaCl compiler.
  - Nokinside 9y ago
    >nothing checks that the output of WebAssembly is safe machine code. The JS/WASM VM does. If unsafe WASM code is allowed to execute, there is a bug in VM. VM must prevent semantically incorrect WASM from executing Control flow integrity and incorrect use of pointers are detected at load time. There are traps for invalid indexes, exceeding stack limits, invalid indexes in the index space.
    - fpoling 9y ago
      This is not about unsafe WASM which should be rejected by verifier. This is about the raw machine output that the compiler generates from WASM. As with JIT for JS currently nothing verifies WASM compiler output. So a bug in the compiler may result in a WASM that passes the verifier to be translated into unsafe machine code.
      - Nokinside 9y ago
        Same thing applies to NaCl verifier. Bugs in verifier can cause problems. Verification or generation bugs are bug, not security weaknesses in the architecture. (I should not need to mention this but compiling is form of verification).
        fpoling 9y ago
        NaCl verifier in practice is much simpler than WASM compiler leading to a significantly reduced attack surface.
- ben0x539 9y ago
  The security model for nacl is afaik that you run almost arbitrary native code. It was compiled by someone else, your input is basically machine code that you don't know anything about except for some please-dont-break-my-sandbox checks. With asm.js, your input is javascript code which can't do all the weird things that native code can do, and you're in charge of generating the native code that ultimately gets executed (much like the traditional JIT setup), so assuming you didn't fuck up the translation, you get to assume it can't do anything that javascript code couldn't have done to begin with, relaxing your sandboxing requirements around, like, arbitrary memory accesses or syscalls.
- panic 9y ago
  The "compiler" here refers to the WebAssembly -> machine code compiler, not the C -> WebAssembly compiler. NaCl used some clever tricks to guarantee the safety of raw machine code.
- bru 9y ago
  The « Reflections on Trusting Trust » paper by Ken Thompson addresses this exact issue: http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-thompson.pdf http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...
- brudgers 9y ago
  The question reminds me of Ken Thompson's Turing Award essay, Reflections on Trusting Trust, http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-thompson.pdf http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...
  - giantahead 9y ago
    one can never bring this up enough when discussing execution trust, but still, in context of relative security, some things look weaker than others

dullgiulio 9y ago

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

satysin 9y ago
I think they are talking about something like the Ken Thompson hack? http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
roca 9y ago
It means that a bug in the compiler/optimizer could allow WebAssembly code to escape its sandbox. This is a real issue, but o some extent this extra attack surface is mitigated because vendors are reusing JS compiler backends that are already part of the TCB.
foxylad 9y ago
Add extraneous code?
fpoling 9y ago
Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code. As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.
- amelius 9y ago
  This. Webassembly is an overcomplication. But, as always, I suppose we have to live with it.
- ascheidecker 9y ago
  It would be possible to leverage a simple machine code verifier similar to NaCl's in a WebAssembly backend. Nobody does it right now, but there's been some work on taking WebAssembly as input to their Subzero PNaCl->NaCl compiler.
- Nokinside 9y ago
  >nothing checks that the output of WebAssembly is safe machine code. The JS/WASM VM does. If unsafe WASM code is allowed to execute, there is a bug in VM. VM must prevent semantically incorrect WASM from executing Control flow integrity and incorrect use of pointers are detected at load time. There are traps for invalid indexes, exceeding stack limits, invalid indexes in the index space.
  - fpoling 9y ago
    This is not about unsafe WASM which should be rejected by verifier. This is about the raw machine output that the compiler generates from WASM. As with JIT for JS currently nothing verifies WASM compiler output. So a bug in the compiler may result in a WASM that passes the verifier to be translated into unsafe machine code.
    - Nokinside 9y ago
      Same thing applies to NaCl verifier. Bugs in verifier can cause problems. Verification or generation bugs are bug, not security weaknesses in the architecture. (I should not need to mention this but compiling is form of verification).
      - fpoling 9y ago
        NaCl verifier in practice is much simpler than WASM compiler leading to a significantly reduced attack surface.
ben0x539 9y ago
The security model for nacl is afaik that you run almost arbitrary native code. It was compiled by someone else, your input is basically machine code that you don't know anything about except for some please-dont-break-my-sandbox checks. With asm.js, your input is javascript code which can't do all the weird things that native code can do, and you're in charge of generating the native code that ultimately gets executed (much like the traditional JIT setup), so assuming you didn't fuck up the translation, you get to assume it can't do anything that javascript code couldn't have done to begin with, relaxing your sandboxing requirements around, like, arbitrary memory accesses or syscalls.
panic 9y ago
The "compiler" here refers to the WebAssembly -> machine code compiler, not the C -> WebAssembly compiler. NaCl used some clever tricks to guarantee the safety of raw machine code.
bru 9y ago
The « Reflections on Trusting Trust » paper by Ken Thompson addresses this exact issue: http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-thompson.pdf http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...
brudgers 9y ago
The question reminds me of Ken Thompson's Turing Award essay, Reflections on Trusting Trust, http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-thompson.pdf http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/p761-th...
- giantahead 9y ago
  one can never bring this up enough when discussing execution trust, but still, in context of relative security, some things look weaker than others