3 ms·

I don't understand how we got here. A cross platform byte code that runs in some kind of emulated machine was done ages ago and called Java. Or C#. And they see

I don't understand how we got here. A cross platform byte code that runs in some kind of emulated machine was done ages ago and called Java. Or C#. And they seem not-exactly-immune to security problems. Then we did containers and they were better. Then we did containers running in a lightweight VM and they were better too. Surely a compiled language on a unikernel (as in no kernel) in a lightweight VM is the ultimate good result for secure + fast + scales? Wouldn't this buy you all sorts of hardware acceleration goodies like direct access to network hardware a la DPDK and no switching between user and kernel modes?

why_only_15 4y ago
Java and C# to my understanding are intended to be run in an untrusted way and can cause segfaults or take over the surrounding process (with JNI or C# unsafe). With something like wasmtime I can have untrusted user code in the same process that I have. This means I can do things like have really low-latency interconnect or start running a user's code in microseconds.
- saagarjha 4y ago
  You can just deny the process access to JNI; it's not too difficult assuming you've patched the JDK appropriately.
  - awestroke 4y ago
    Running untrusted java code sounds like a nightmare. And saying you can do something in java if you've "patched the JDK appropriately"... How is that even comparable to a 100% sandboxed by default vm and runtime?
    - saagarjha 4y ago
      You patch the JDK because it doesn’t make sense to try to access the filesystem if there is no filesystem, lol. The JVM is sandboxed, it’s the APIs you give it that let it break out.
moring 4y ago
> A cross platform byte code that runs in some kind of emulated machine was done ages ago and called Java. Java does not emulate a machine. It abuses the term "virtual machine" for what is actually a compiler back-end. A particular difference to WASM is that the JVM's idea of how memory works is totally different from both WASM and real machines. > And they seem not-exactly-immune to security problems. This has nothing to do with the JVM but with the standard library, which tries to implement security for very-high-level operations. WASM is closer to browsers, which already implement security in a much more robust way. > Then we did containers and they were better. If you think that containers are the way to run native code in the web, I'd suggest you build a proof-of-concept. Because to me that doesn't sound like a great idea at all. > ... direct access to network hardware ... Talk about security nightmares...
- RantyDave 4y ago
  Containers are running native code. iPhones, for instance, seem happy to run containers. And it's my (perhaps shaky) understanding that the multi-process model for browsers involves running processes with reduced privileges - containers, in other words, even if not specifically "docker" ones. AWS lambda is built on a VM/container hybrid IIRC. And VM's, again, have direct access to hardware. This is what this SR-IOV business is all about and how we (RoCE) can have remote disks across networks that run even vaguely well. Virtual machines have been running arbitrary code for a long time now, I think this is pretty much a done deal.

why_only_15 4y ago

Java and C# to my understanding are intended to be run in an untrusted way and can cause segfaults or take over the surrounding process (with JNI or C# unsafe). With something like wasmtime I can have untrusted user code in the same process that I have. This means I can do things like have really low-latency interconnect or start running a user's code in microseconds.

saagarjha 4y ago
You can just deny the process access to JNI; it's not too difficult assuming you've patched the JDK appropriately.
- awestroke 4y ago
  Running untrusted java code sounds like a nightmare. And saying you can do something in java if you've "patched the JDK appropriately"... How is that even comparable to a 100% sandboxed by default vm and runtime?
  - saagarjha 4y ago
    You patch the JDK because it doesn’t make sense to try to access the filesystem if there is no filesystem, lol. The JVM is sandboxed, it’s the APIs you give it that let it break out.

moring 4y ago

> A cross platform byte code that runs in some kind of emulated machine was done ages ago and called Java. Java does not emulate a machine. It abuses the term "virtual machine" for what is actually a compiler back-end. A particular difference to WASM is that the JVM's idea of how memory works is totally different from both WASM and real machines. > And they seem not-exactly-immune to security problems. This has nothing to do with the JVM but with the standard library, which tries to implement security for very-high-level operations. WASM is closer to browsers, which already implement security in a much more robust way. > Then we did containers and they were better. If you think that containers are the way to run native code in the web, I'd suggest you build a proof-of-concept. Because to me that doesn't sound like a great idea at all. > ... direct access to network hardware ... Talk about security nightmares...

RantyDave 4y ago
Containers are running native code. iPhones, for instance, seem happy to run containers. And it's my (perhaps shaky) understanding that the multi-process model for browsers involves running processes with reduced privileges - containers, in other words, even if not specifically "docker" ones. AWS lambda is built on a VM/container hybrid IIRC. And VM's, again, have direct access to hardware. This is what this SR-IOV business is all about and how we (RoCE) can have remote disks across networks that run even vaguely well. Virtual machines have been running arbitrary code for a long time now, I think this is pretty much a done deal.