> So what? You are still running on top of the hypervisor. It’s entirely doable from a unikernel. Is it? Does this unikernel have support for all the hardware

> So what? You are still running on top of the hypervisor. It’s entirely doable from a unikernel. Is it? Does this unikernel have support for all the hardware that the Linux kernel does? Once you're dealing with real hardware, 90% of your project becomes drivers, and 10% the actual kernel bit. No niche kernel can compete on that front. > Need a dedicated disk array with full performance? You can get it. Meanwhile you're still paying for VM overhead (it's not zero) for no good reason... Again, this thing's selling point is "it runs in the cloud", and cloud vendors don't do passthrough. If you're running your own metal, you're better off with a sandboxing approach that doesn't needlessly involve a full VM. > In the actual world, VM are safer. There are many sandboxing technologies not built on VMs with good track records (or even built on VM modes but much lighter than a full virtual PC like cloud vendors use). Do you have statistics on how VMs are safer than these kinds of technologies? OP is only comparing containers and VMs. There's plenty of more secure technologies, like gVisor (that has a backend that uses KVM and one that does not, and is in both cases lighter weight than a full x86 virtual machine). > If you can’t even call the interface because support is not there in the unikernel it’s not part of your attack surface. If you can't even call the interface because support is not there in the sandbox layer, it's not part of your attack surface. > But you are once again using a completely flawed argument. It doesn’t matter that syscall interfaces could be as safe as the one provided by the VM because they are not. This is not an argument about potential. Again, look at sandboxing technologies. The kind that use either full on syscall wrappers or at least very strict whitelists. There have been plenty of VM escape bugs going around. Syscalls have a larger attack surface because they do more stuff. Start filtering all that with a strong sandbox and you can achieve similar levels of security to VMs. There's no magic thing about VMs that makes them safer. > You are completely missing the point because you live in a fantasy. I guess Google is living in a fantasy too, seeing as they've been running untrusted customer code on App Engine by using sandboxes, on top of kernels shared between multiple customers and also internal code, with no VMs in sight (at least originally; they may have moved to the KVM backend of gVisor now, but again that's still not a full blown virtio PC like the thing this unikernel runs on).