[dkersten]

Java, Kotlin, Clojure, Scala, Groovy

More here: https://en.wikipedia.org/wiki/List_of_JVM_languages

It accepts any language that compiles to JVM bytecode. Java is just one of them. Just like an x86 processor accepts any language that compiles to x86 instructions.

[linkpuff]

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.

[dkersten]

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

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

[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