5 ms·

Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm c

Doesn't that require a language to be engineered to output java bytecode? For example, rust can't be compiled to java bytecode because it does things that jvm can't do. A real polyglot can't only understand a language by requiring it to speak its native language Wasm supports languages that weren't created with wasm in mind, just by requiring a compiler with the right output, without restraining the language.

still_grokking 5y ago
Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
- sitkack 5y ago
  GraalVM has a Wasm front end, there is almost no reason to use bitcode as the interface to Graal. https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
  - still_grokking 5y ago
    That makes no sense in case of Rust (or C/C++ for that matter). You would compile LLVM-frontend -> LLVM-IR -> LLVM-WASM-backend -> GraalVM-WASM-frontend -> GraalVM-bytecode-backend instead of LLVM-frontend -> LLVM-IR -> GraalVM-LLVM-IR-frontend -> GraalVM-bytecode-backend The additional transformations won't be healthy for the performance of your program, or compile times…
    - sitkack 5y ago
      Does the second compilation chain do Control Flow Integrity? https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html It looks like it might be possible, but I really like the security properties of Wasm. It looks like I am moving the goal posts, but I am not, it is the biggest reason to use Wasm, the second one is the capabilities model. It would be a great undergrad research project to measure the difference in those two compilation chains.
      - still_grokking 5y ago
        I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level). And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS. But "sanboxing" some process running on a VM is completely independent of that! WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes. If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) if it isn't also capability-secure. Otherwise the model breaks. To be capability-secure you have actually to rewrite the world… ¹ https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std
        sitkack 5y ago
        > I'm not sure you could hack the control flow when running bytecode on the JVM LLVM IR is C/C++, if you are embedding that into your Graal program w/o the same level of CFI that Wasm has, you can definitely crash your Graal program. We were literally talking about LLVM IR and you switched back to bytecode. JVM bytecode is safe, LLVM IR is not. > WASM won't get you anything beyond a "simple sanbox" ootb. Not true, the core tenet of Wasm is based around CFI. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/ Wasm has capabilities everywhere, it doesn't need an OS to provide this. Graal is so much more than JVM. The way it integrates LLVM IR absolutely matters wrt safety. If you include Wasm into a native code it doesn't reduce any of its security properties. You include LLVM IR into a JVM program and it will reduce your security properties. While LLVM has CFI it doesn't provide the same guarantees that Wasm CFI does.
dkersten 5y ago
> just by requiring a compiler with the right output, How is that different from a compiler that generates JVM bytecode? Yes, the bytecode was designed specifically for Java's needs, but running languages that weren't designed for the JVM on the JVM is still less of a stretch than compiling C to asm.js, something which has worked quite successfully. Or targeting a different CPU architecture.

still_grokking 5y ago

Of course you could run Rust on the JVM (more precisely on GraalVM)! Have a look at Project Sulong. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong

sitkack 5y ago
GraalVM has a Wasm front end, there is almost no reason to use bitcode as the interface to Graal. https://www.graalvm.org/reference-manual/wasm/ https://www.graalvm.org/reference-manual/wasm/
- still_grokking 5y ago
  That makes no sense in case of Rust (or C/C++ for that matter). You would compile LLVM-frontend -> LLVM-IR -> LLVM-WASM-backend -> GraalVM-WASM-frontend -> GraalVM-bytecode-backend instead of LLVM-frontend -> LLVM-IR -> GraalVM-LLVM-IR-frontend -> GraalVM-bytecode-backend The additional transformations won't be healthy for the performance of your program, or compile times…
  - sitkack 5y ago
    Does the second compilation chain do Control Flow Integrity? https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html It looks like it might be possible, but I really like the security properties of Wasm. It looks like I am moving the goal posts, but I am not, it is the biggest reason to use Wasm, the second one is the capabilities model. It would be a great undergrad research project to measure the difference in those two compilation chains.
    - still_grokking 5y ago
      I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level). And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS. But "sanboxing" some process running on a VM is completely independent of that! WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes. If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) if it isn't also capability-secure. Otherwise the model breaks. To be capability-secure you have actually to rewrite the world… ¹ https://github.com/bytecodealliance/cap-std https://github.com/bytecodealliance/cap-std
      - sitkack 5y ago
        > I'm not sure you could hack the control flow when running bytecode on the JVM LLVM IR is C/C++, if you are embedding that into your Graal program w/o the same level of CFI that Wasm has, you can definitely crash your Graal program. We were literally talking about LLVM IR and you switched back to bytecode. JVM bytecode is safe, LLVM IR is not. > WASM won't get you anything beyond a "simple sanbox" ootb. Not true, the core tenet of Wasm is based around CFI. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/ Wasm has capabilities everywhere, it doesn't need an OS to provide this. Graal is so much more than JVM. The way it integrates LLVM IR absolutely matters wrt safety. If you include Wasm into a native code it doesn't reduce any of its security properties. You include LLVM IR into a JVM program and it will reduce your security properties. While LLVM has CFI it doesn't provide the same guarantees that Wasm CFI does.

dkersten 5y ago

> just by requiring a compiler with the right output, How is that different from a compiler that generates JVM bytecode? Yes, the bytecode was designed specifically for Java's needs, but running languages that weren't designed for the JVM on the JVM is still less of a stretch than compiling C to asm.js, something which has worked quite successfully. Or targeting a different CPU architecture.