3 ms·

> Or put another way every compiled program is already on a perfectly portable IR called x86_64. Runs on just about every desktop, laptop, and nearly every serv

> Or put another way every compiled program is already on a perfectly portable IR called x86_64. Runs on just about every desktop, laptop, and nearly every server in the world. But not mobile. (Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.) > Sandboxing is already a solved problem using process isolation If only it were. Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process. > Formally verifying it is about as useful as formally verifying assembly. Which is to say, not useful at all. You can verify memory safety of the compiled code, which is a useful and important property. (I think nobody seriously doubts that Web Assembly is memory safe assuming a bounds checked heap, though, so it's not that practically interesting of a result. Maybe it'll be more so when GC support lands.)

kllrnohj 9y ago
> (Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.) Well, x86_64 is actually AMD's creation not Intel's. But replace x86_64 with ARM on mobile and it's the same thing - a portable IR/instruction set does not result in a portable application. > Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process. Neither does webasm, other than by just not having any features currently. But that's obviously not a viable long-term strategy, certainly not for anything standalone-ish. > You can verify memory safety of the compiled code, which is a useful and important property. My native code is perfectly memory safe as well, enforced in hardware even. Has been that way for decades. Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. A memory safe IR is meaningless outside of the context of being embedded in another process. Aka, when used in a web browser. Or I guess as a massively overcomplicated replacement for Lua. But the point is verifying the resulting webasm doesn't mean your code was correct, it means your code plus current toolchain selection happened to result in verified code. Whether or not that was the result of a fluke or well defined behavior is not something webasm has any impact on.
- pcwalton 9y ago
  > Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. That's not true. Web Assembly semantics don't allow interpreting data as code or explicitly messing with the machine stack. This guarantees control flow integrity, preventing problems like ROP or traditional buffer overflows.
  - andromeduck 9y ago
    While webasm isn't vulnurable to traditional ROP attacks, it will also lose at least as much performance penalty as IR + g-free/indirect return. Memory protection in terms of r/w/x been solved for at least about 3 decades now. It would be absolutely trivial to enforce via binary/IR distribution. At the end of the day webasm is just a shitty IR that only exists because it's the path of least resistance on the web. There's really no point in going from lang-> llvm -> webasm -> llvm -> exec when you can just go from lang -> llvm -> asm.
    - pcwalton 9y ago
      RWX doesn't prevent ROP!
      - andromeduck 9y ago
        Sure but I brought up rwx for their data execution point and g-free/indirect return for ROP mitigation.
  - comex 9y ago
    However, it only partially addresses JOP (jump-oriented programming, i.e. hijacking calls to function pointers and virtual methods). And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack. In fact, I expect Clang CFI to be more widely adopted in the future… However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead. edit: not to mention that WebAssembly is currently missing security mitigations that long have been standard in native code, such as ASLR, and… maybe stack overflow protection? (It looks like emscripten handles the latter manually by checking STACKTOP against STACK_MAX, but I'm not sure LLVM's native WebAssembly target does.) Maybe these will be addressed in the future, but for now there are some interesting exploitation opportunities.

kllrnohj 9y ago

> (Besides, I'm also somewhat uneasy with accepting that the computing lingua franca will forever be proprietary to Intel, covered by innumerable patents, and backwards compatible to 1978.) Well, x86_64 is actually AMD's creation not Intel's. But replace x86_64 with ARM on mobile and it's the same thing - a portable IR/instruction set does not result in a portable application. > Process isolation does not protect against kernel attacks or attacks against whatever IPC mechanism you use to call out to the privileged broker process. Neither does webasm, other than by just not having any features currently. But that's obviously not a viable long-term strategy, certainly not for anything standalone-ish. > You can verify memory safety of the compiled code, which is a useful and important property. My native code is perfectly memory safe as well, enforced in hardware even. Has been that way for decades. Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. A memory safe IR is meaningless outside of the context of being embedded in another process. Aka, when used in a web browser. Or I guess as a massively overcomplicated replacement for Lua. But the point is verifying the resulting webasm doesn't mean your code was correct, it means your code plus current toolchain selection happened to result in verified code. Whether or not that was the result of a fluke or well defined behavior is not something webasm has any impact on.

pcwalton 9y ago
> Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway. That's not true. Web Assembly semantics don't allow interpreting data as code or explicitly messing with the machine stack. This guarantees control flow integrity, preventing problems like ROP or traditional buffer overflows.
- andromeduck 9y ago
  While webasm isn't vulnurable to traditional ROP attacks, it will also lose at least as much performance penalty as IR + g-free/indirect return. Memory protection in terms of r/w/x been solved for at least about 3 decades now. It would be absolutely trivial to enforce via binary/IR distribution. At the end of the day webasm is just a shitty IR that only exists because it's the path of least resistance on the web. There's really no point in going from lang-> llvm -> webasm -> llvm -> exec when you can just go from lang -> llvm -> asm.
  - pcwalton 9y ago
    RWX doesn't prevent ROP!
    - andromeduck 9y ago
      Sure but I brought up rwx for their data execution point and g-free/indirect return for ROP mitigation.
- comex 9y ago
  However, it only partially addresses JOP (jump-oriented programming, i.e. hijacking calls to function pointers and virtual methods). And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack. In fact, I expect Clang CFI to be more widely adopted in the future… However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead. edit: not to mention that WebAssembly is currently missing security mitigations that long have been standard in native code, such as ASLR, and… maybe stack overflow protection? (It looks like emscripten handles the latter manually by checking STACKTOP against STACK_MAX, but I'm not sure LLVM's native WebAssembly target does.) Maybe these will be addressed in the future, but for now there are some interesting exploitation opportunities.