4 ms·

> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is

> WASM proved to be secure and JVM did not. It is interesting to ask why that is the case, from my point of view the reason is that the JVM standard library is just too damn large. While WASM goes on a lower-level approach of just not having one. To make WASM have the capabilities required the host (the agent running the WASM code) needs to provide them. For a lot of languages that means using WASI, moving most of the security concerns to the WASI implementation used. But if you really want to create a secure environment you can just... not implement all of WASI. So a lambda function host environment can, for example, just not implement any filesystem WASI calls because a lambda has no business implementing filesystem stuff. > An alternative is to use virtualization. So you can either compile your code to WASM blob and run it in the big WASM server, or you can compile your code to amd64 binary, put it along stripped Linux kernel and run this thing in the VM. I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster. Or custom WASM runtimes heavily tied to the hardware they run on to make better JIT code. I imagine a future where WASM is treated like LLVM IR

kaba0 2y ago
> I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/arm to “communicate with us”, while they do something else in the form of microcode. So it didn’t really pay off, and I would wager it wouldn’t pay off with WASM either.
- mshockwave 2y ago
  > Heh, there were literally CPUs with some support for the JVM! Jazelle, a dark history that ARM never wants to mention again
cogman10 2y ago
I'll just add one thing here, WASM's platform access is VERY small. There's almost no runtime associated with WASM and thus no guarantees to what WASM can access. When you throw WASM into the browser, it's access to the outside world is granted by the javascript container that invokes it. That's very different compared to how other browser extensions operated. The old browser extensions like the JVM or flash were literally the browser calling into a binary blob with full access to the whole platform. That is why the WASM model is secure vs the JVM model. WASM simply can't interact with the system unless it is explicitly given access to the system from the host calling it. It is even more strictly sandboxed than the Javascript engine which is executing it.
- Vilian 2y ago
  Wht can't wasm have it own invoker, instead of relying on javascript?

kaba0 2y ago

> I think the first approach gives a lot more room for the host to create optimizations, to the point we could see hardware with custom instructions to make WASM faster Heh, there were literally CPUs with some support for the JVM! But it turns out that “translating” between different forms is not that expensive (and can be done ahead of time and cached), given that CPUs already use a higher level abstraction of x86/arm to “communicate with us”, while they do something else in the form of microcode. So it didn’t really pay off, and I would wager it wouldn’t pay off with WASM either.

mshockwave 2y ago
> Heh, there were literally CPUs with some support for the JVM! Jazelle, a dark history that ARM never wants to mention again

cogman10 2y ago

I'll just add one thing here, WASM's platform access is VERY small. There's almost no runtime associated with WASM and thus no guarantees to what WASM can access. When you throw WASM into the browser, it's access to the outside world is granted by the javascript container that invokes it. That's very different compared to how other browser extensions operated. The old browser extensions like the JVM or flash were literally the browser calling into a binary blob with full access to the whole platform. That is why the WASM model is secure vs the JVM model. WASM simply can't interact with the system unless it is explicitly given access to the system from the host calling it. It is even more strictly sandboxed than the Javascript engine which is executing it.

Vilian 2y ago
Wht can't wasm have it own invoker, instead of relying on javascript?