Hacker News Reader

Comment by pjmlp | Hacker News Reader

Benchmarks regarding meaningful impact in production code?

Also WASM remains to be battle tested regarding exploits in the wild.

The WASM spec was developed with formal verification in mind, and the core specification, interpreter and type checker had mechanized safety proofs very early on [1]. This is backwards from how most bytecodes were designed, so that's very promising. Note also that the specification is an explicitly single-pass type checking, which is very efficient.

The difficulty of full safety verification on the JVM is well studied [2]. The security-focused Joe-E language actually decompiles JVM bytecodes back to Java to avoid the many full abstraction failures that have been documented.

The CLR is a little better on the safety record, but the verification costs can be even higher because the CLR supports various pointer types. Proper verification requires control-flow analysis, but instead they partition the bytecode into safe/unsafe variants and only the safe variant is "verifiable". IIRC, WASM doesn't have this limitation.

[1] https://www.cl.cam.ac.uk/~caw77/papers/mechanising-and-verif...

[2] http://www-master.ufr-info-p6.jussieu.fr/2005/IMG/pdf/leroy-...

Well, repolfx already pointed out a couple of issues with WASM security.

As for the links I will check them later. Thanks providing them.

No, repolfx didn't. There were some security bugs with WASM, but why shouldn't have that happened with Java Bytecode? Also the JVM isn't immune to security bugs either.

The point is that it did, with more than 20 years experience in production to fine tune its security.

WASM still needs to prove itself in similar scenarios.

Java's security is still terrible. Read up on the Joe-E work to see why.

"Fine-tuning security" is typically symptomatic of bad security design. Security is not a separable concern.

Well WASM has been fined tuned already, given the referred bug fixes.

I will read the paper later on.

"Fine tuned" != "bug fixes". Fine tuning means they start changing the security model and the properties it can enforce because it was poorly designed to begin with. That is the case with the JVM but not with WASM.

A great WASM benchmark: http://iswebassemblyfastyet.com/

Thanks, but I was refereeing to some kind of benchmark where WASM verification wins against JVM verification, in similar scenarios.

Reply on news.ycombinator.com