4 ms·

> Well, no. IOMMU is a thing. You can do passthrough of I/O devices is you need to. That's not virtualization. That's explicitly not virtualizing that device.

> Well, no. IOMMU is a thing. You can do passthrough of I/O devices is you need to. That's not virtualization. That's explicitly not virtualizing that device. I don't think any cloud vendors do that for anything but perhaps GPU acceleration. It doesn't make much sense for a unikernel - would you really dedicate a NIC to each app? > There is no question that running a software in a VM is safer than running it straight on the kernel. The isolation enforced is far stronger. There is no magic extra isolation. You think there is because of what we've built with VM technology. The underlying hardware doesn't provide extra isolation. I recently built my own hypervisor from scratch for ARM64. There is no magic "isolation on" bit. On ARM64, there are three execution levels: EL2 (hypervisor), EL1 (guest), and EL0 (userspace). Running stuff in userspace (EL0) in a VM is identical to running it in userspace outside a VM (also EL0), except for whatever VM features you've turned on. These are things like second stage paging, trapping certain system operations, etc. Effectively none of these have any impact on EL0; they are all there to allow you to run a guest kernel at EL1, not to isolate it more than userspace already is. In fact, in non VHE mode, your host OS kernel also runs at EL1 - kernels without VM support just drop to EL1 from EL2 on startup and effectively run as "uniguests" with no hypervisor. Intel works a different way, but that's just implementation technicalities; the security position is the same in practice. We consider VMs to have better isolation merely because we've done a better job at having a smaller attack surface in our paravirtualized interface designs than we have with our syscall interface designs. Nothing more. It's all in the software. It has nothing to do with the actual VM part. > A unikernel keeps the advantage of discarding plenty of attack vectors just by virtue of every unnecessary part of the kernel not being there however. But the kernel is there. It's right there outside the unikernel. You just have a smaller attack surface because its paravirt hardware interfaces are better designed than its syscall interfaces. > You can certainly harden systems in different way and enforce isolation though different means but VMs have the advantage of being a fairly old and well known technology with good toolings around them, especially in the entreprise world. Now you're getting somewhere. Yes, VM tooling makes VMs more secure. As I said, it's purely a result of how we use VM technology. It's not intrinsic.

WastingMyTime89 5y ago
> That's not virtualization. That's explicitly not virtualizing that device. So what? You are still running on top of the hypervisor. It’s entirely doable from a unikernel. > It doesn't make much sense for a unikernel - would you really dedicate a NIC to each app? Of course it makes sense. The point is if you need the performance of a dedicated NIC you can get them, same things for the other I/O interfaces. Need a dedicated disk array with full performance? You can get it. > There is no magic extra isolation. You think there is because of what we've built with VM technology. The underlying hardware doesn't provide extra isolation. I think there is because there is. When you write « what’ve built with VM technology », that’s what that means. It doesn’t matter that you could in theory do the same on the kernel because there is no underlying mechanism at the hardware level. In the actual world, VM are safer. > But the kernel is there. It's right there outside the unikernel. You just have a smaller attack surface because its paravirt hardware interfaces are better designed than its syscall interfaces. If you can’t even call the interface because support is not there in the unikernel 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. You are completely missing the point because you live in a fantasy.
- marcan_42 5y ago
  > 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).

WastingMyTime89 5y ago

> That's not virtualization. That's explicitly not virtualizing that device. So what? You are still running on top of the hypervisor. It’s entirely doable from a unikernel. > It doesn't make much sense for a unikernel - would you really dedicate a NIC to each app? Of course it makes sense. The point is if you need the performance of a dedicated NIC you can get them, same things for the other I/O interfaces. Need a dedicated disk array with full performance? You can get it. > There is no magic extra isolation. You think there is because of what we've built with VM technology. The underlying hardware doesn't provide extra isolation. I think there is because there is. When you write « what’ve built with VM technology », that’s what that means. It doesn’t matter that you could in theory do the same on the kernel because there is no underlying mechanism at the hardware level. In the actual world, VM are safer. > But the kernel is there. It's right there outside the unikernel. You just have a smaller attack surface because its paravirt hardware interfaces are better designed than its syscall interfaces. If you can’t even call the interface because support is not there in the unikernel 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. You are completely missing the point because you live in a fantasy.

marcan_42 5y ago
> 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).