Hacker News new | ask | show | jobs
by justinmchase 2646 days ago
Love it. This could be a huge innovation and really push the dream of cross platform development to the next level.

I suppose this would have pretty big implications for Electron or a similar successor to aid in the UI portion of this endeavor.

2 comments

Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).
Properly sandboxed VM that you can compile practically any language into?
AS/400 TIMI comes to mind, and CLR as well.
CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete.

The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed.

For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.

And WASM remains to be battle tested in the wild, as in the juicy target of millions of black hats out there.

Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable.

Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.

The CLR is not a great target for running unmodified C code. I suspect that was included in "practically any language."
Yeah, Managed C++ and C++/CLI don't exist.
I was careful to say "unmodified." C++/CLI is hardly that. It's also not at all sandboxed the way wasm is.

Why the chip on the shoulder?

Yes, it's called DOSBox. Or QEMU with dynamic syscall translation if you want to be real fancy.
JVM and CLR.
But lack of good and safe isolation was a serious problem
Yep, just like....wait for it....UCSD Pascal.
Nobody is saying that the idea of a sandboxed VM is original. The interesting parts of wasm are the theoretically-uninteresting but important-in-practice features: JS interoperability, the LLVM backend, cross-browser support, etc.
Well, many are behaving as such.

Actually JVM got there first with JS-interoperabily.