5 ms·

The general thrust of your argument is correct, but you missed a key part of the evolution. People see that the operating system is insecure, so they run the o

by Veserv 3y ago

The general thrust of your argument is correct, but you missed a key part of the evolution. People see that the operating system is insecure, so they run the operating system as a virtual machine on top of a hypervisor. The hypervisor operates the system as a bundle of virtual machines and provides shared services to them. People realize the hypervisor is just a operating system, so they target the hypervisor API instead of the kernel API and thus unikernels are invented. The question then becomes: Why unikernel on a hypervisor instead of a process on a operating system? The standard answer is that hypervisors are more "secure". However, this is total nonsense. Any technique that made a hypervisor "secure" could be directly applied back to a normal operating system as they are solving the same fundamental problem of multiplexing a single machine to run multiple programs. To quote Theo de Raadt: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." The actual answer is that everybody sucks at multiplexing hardware, so everybody knows the old stuff does not work. However, they do not know the new stuff does not work yet, so they bet it all on the new stuff. Unikernels on a hypervisor are a strictly inferior solution to a process on a operating system, but people think hypervisors are better than operating systems, so they develop unikernels. The truth of the matter is that you just need a better operating system so you can develop processes which is a strictly better model.

intelVISA 3y ago
Ah yes, processes on an OS: the original unikernels run by VMM. What next, perhaps, a VMM for VMMs? a VMMM?
elromulous 3y ago
I'm not necessarily saying virtual machines are more secure, but, here's where I think the difference might be: the api. Linux has so many system calls, and with each new one you get a whole new attack surface (e.g. most recently with io_uring). But the attack surface with hypervisors is pretty static, and perhaps can be better reasoned about. Again, not strongly arguing which is safer, but just pointing out that there is a pretty fundamental difference between the two that could make for a difference in security.
- Veserv 3y ago
  Yes, but the API is not inherent to the hypervisor/kernel split. You can have a operating system that exposes a smaller API similar to a hypervisor and voila, you have a better model. The only reason to prefer a hypervisor over a similar operating system is if you need to run a binary targeting a different operating system. At that point you actually do need a virtual machine and you actually do need the operating system in it. However, this is contrary to the point of a unikernel which is to get rid of the operating system within the virtual machine. Processes and OS services are a strictly better model than virtual machines and virtual devices when developing a program. They fulfill the same purposes, but the operating system model is less clunky as you are "virtualizing" a ideal machine that requires no setup and ideal devices that requires no setup. In contrast, virtual machines and virtual devices expose a API that includes the nitty-gritty details of actual hardware which is just a distraction when developing a regular old application. You actually see a funny convergence where optimized hypervisors implement specialized virtual devices that do not exist in reality that offer streamlined interfaces. These are basically the reinvention of operating system interfaces as the virtual machine guests (processes) consume a abstract interface that the hypervisor (operating system) maps onto the actual hardware. They also support specialized virtual devices for communicating between guests (IPC calls). Reinvention for everyone, but worse, yay.
tenebrisalietum 3y ago
I thought unikernels collapsed userspace and kernelspace for performance reasons.
- Veserv 3y ago
  The model was originally: OS + processes. Due to security reasons (which are wrong) it changes to: hypervisor + OSs + processes. However, the hypervisor and the OS really do the same thing; they multiplex multiple programs onto a single piece of hardware. The unikernel people recognized that and decided to collapse the OS + processes so you now just have: hypervisor + (hypercall library/OS stub + process)s. The better model is just making a better OS so you can drop the hypervisor layer and return to OS + processes. This model has better performance, easier development, more observability, and is basically just better in every way. Unfortunately, nobody wants to do this because everybody wrongly believes that hypervisors are magically more secure than operating systems for the reasons I stated in my previous comment. This is really the only thing propping up the hypervisor and, by extension, the unikernel concept. As soon as you no longer believe they are magically more secure there are hardly any reasons to prefer a hypervisor over a properly designed operating system beyond the one use case I mentioned in a sibling comment which is running a binary-only program targeting a different operating system.

by Veserv 3y ago

intelVISA 3y ago

Ah yes, processes on an OS: the original unikernels run by VMM. What next, perhaps, a VMM for VMMs? a VMMM?

elromulous 3y ago

I'm not necessarily saying virtual machines are more secure, but, here's where I think the difference might be: the api. Linux has so many system calls, and with each new one you get a whole new attack surface (e.g. most recently with io_uring). But the attack surface with hypervisors is pretty static, and perhaps can be better reasoned about. Again, not strongly arguing which is safer, but just pointing out that there is a pretty fundamental difference between the two that could make for a difference in security.

Veserv 3y ago
Yes, but the API is not inherent to the hypervisor/kernel split. You can have a operating system that exposes a smaller API similar to a hypervisor and voila, you have a better model. The only reason to prefer a hypervisor over a similar operating system is if you need to run a binary targeting a different operating system. At that point you actually do need a virtual machine and you actually do need the operating system in it. However, this is contrary to the point of a unikernel which is to get rid of the operating system within the virtual machine. Processes and OS services are a strictly better model than virtual machines and virtual devices when developing a program. They fulfill the same purposes, but the operating system model is less clunky as you are "virtualizing" a ideal machine that requires no setup and ideal devices that requires no setup. In contrast, virtual machines and virtual devices expose a API that includes the nitty-gritty details of actual hardware which is just a distraction when developing a regular old application. You actually see a funny convergence where optimized hypervisors implement specialized virtual devices that do not exist in reality that offer streamlined interfaces. These are basically the reinvention of operating system interfaces as the virtual machine guests (processes) consume a abstract interface that the hypervisor (operating system) maps onto the actual hardware. They also support specialized virtual devices for communicating between guests (IPC calls). Reinvention for everyone, but worse, yay.

tenebrisalietum 3y ago

I thought unikernels collapsed userspace and kernelspace for performance reasons.

Veserv 3y ago
The model was originally: OS + processes. Due to security reasons (which are wrong) it changes to: hypervisor + OSs + processes. However, the hypervisor and the OS really do the same thing; they multiplex multiple programs onto a single piece of hardware. The unikernel people recognized that and decided to collapse the OS + processes so you now just have: hypervisor + (hypercall library/OS stub + process)s. The better model is just making a better OS so you can drop the hypervisor layer and return to OS + processes. This model has better performance, easier development, more observability, and is basically just better in every way. Unfortunately, nobody wants to do this because everybody wrongly believes that hypervisors are magically more secure than operating systems for the reasons I stated in my previous comment. This is really the only thing propping up the hypervisor and, by extension, the unikernel concept. As soon as you no longer believe they are magically more secure there are hardly any reasons to prefer a hypervisor over a properly designed operating system beyond the one use case I mentioned in a sibling comment which is running a binary-only program targeting a different operating system.