4 ms·

I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Ja

• pjmlp 7y ago
  Follow my sibling comment for examples all the way back to 1958. JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong. As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires. It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats. And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.
  • zeroimpl 7y ago
    If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.
    • pjmlp 7y ago
      If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security. The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.