[sitkack]

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/

[still_grokking]

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]

Does the second compilation chain do Control Flow Integrity?

https://en.wikipedia.org/wiki/Control-flow_integrity

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]

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

[sitkack]

> 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/

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.