3 ms·

The alternative is not between bare metal and paravirtualization. Hardware assisted virtualisation is a thing. The hypervisor can actually be very thin. I thin

The alternative is not between bare metal and paravirtualization. Hardware assisted virtualisation is a thing. The hypervisor can actually be very thin. I think what you are describing is actually an argument in favor of unikernel. The idea is to get the best of both world. You get the isolation guaranty provided by virtualisation without the cost of a full OS running on a full OS and with the added benefits of compiler optimisation running on the whole stake at once. Intellectually it makes a lot of sense. The question is: can it actually work without creating a lot of frictions during development and deliver these theoretical gains.

marcan_42 5y ago
The host interface is paravirtualized. Hardware assisted virtualization only covers the CPU in most cases. All the hardware and I/O is going to be using paravirtualized devices (virtio or similar). There is no inherent reason why that interface is going to be more secure than the syscall interface. If the goal is security, there are easier ways of hardening that without reaching for virtualization. Virtualization itself doesn't really buy you anything there; we only consider VMs more secure due to how existing implementations work, not due to anything intrinsic.
- WastingMyTime89 5y ago
  > Hardware assisted virtualization only covers the CPU in most cases. All the hardware and I/O is going to be using paravirtualized devices (virtio or similar). Well, no. IOMMU is a thing. You can do passthrough of I/O devices is you need to. > There is no inherent reason why that interface is going to be more secure than the syscall interface. If the goal is security, there are easier ways of hardening that without reaching for virtualization. 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. You could legitimately ask if it’s safer than running it inside a container. That’s a good question especially now that the orchestration surrounding containers is better. 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. > we only consider VMs more secure due to how existing implementations work, not due to anything intrinsic. It’s weird argument. We do indeed consider VMs more secure than running things directly on the kernel because the way they work intrinsically means are. 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.
  - marcan_42 5y ago
    > 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

marcan_42 5y ago

The host interface is paravirtualized. Hardware assisted virtualization only covers the CPU in most cases. All the hardware and I/O is going to be using paravirtualized devices (virtio or similar). There is no inherent reason why that interface is going to be more secure than the syscall interface. If the goal is security, there are easier ways of hardening that without reaching for virtualization. Virtualization itself doesn't really buy you anything there; we only consider VMs more secure due to how existing implementations work, not due to anything intrinsic.

WastingMyTime89 5y ago
> Hardware assisted virtualization only covers the CPU in most cases. All the hardware and I/O is going to be using paravirtualized devices (virtio or similar). Well, no. IOMMU is a thing. You can do passthrough of I/O devices is you need to. > There is no inherent reason why that interface is going to be more secure than the syscall interface. If the goal is security, there are easier ways of hardening that without reaching for virtualization. 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. You could legitimately ask if it’s safer than running it inside a container. That’s a good question especially now that the orchestration surrounding containers is better. 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. > we only consider VMs more secure due to how existing implementations work, not due to anything intrinsic. It’s weird argument. We do indeed consider VMs more secure than running things directly on the kernel because the way they work intrinsically means are. 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.
- marcan_42 5y ago
  > 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