[reycharles]

A big difference in my opinion is that projects like Mirage does not try to reimplement the same hardware drivers as the host system and instead implements much simpler drivers for virtual hardware.

For example, how do you write to a block device? You make a hypercall with a "handle", offset into the block device, the number of blocks to write and a pointer to memory to be written. There's no pretending it's a spinny disk with sectors and heads or what have you.

https://github.com/Solo5/solo5/blob/bf29b8af11feec9dbc2e74cc...

[Veserv]

That is just infinitely worse than calling write() on a file handle like a regular application.

The hypervisor + OS + application model is stupid. The hypervisor and OS are duplicative. If you can rewrite the application (as is needed for a unikernel design) there is no reason to use a hypervisor in your stack at all. You should just be running a OS directly on the bare metal with no hypervisor at all.

The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary. Everything else about them is strictly inferior to a standard application on OS model.

[eyberg]

One of the key insights for unikernels in general is that everything is virtualized now to begin with. The entire public cloud: AWS, GCP, Azure, etc. is virtualization with an api on top of it.

So unikernels take advantage of this fact to get the performance, security and ease of use benefits.

Hypervisors most definitely have better hardware-based isolation than a few processes running in linux. In fact the isolation is so good that the entire public clouds are built on this model.

[necrophcodr]

This only works if your environment is bare metal to begin with. In some cases you may be in an environment where a lot of applications are proprietary, virtualized, or otherwise constrained in some other way. It is not an environment where you get to pick and choose how everything is setup. In such a case, having a distinct small application that fits as "an OS" in a virtualized environment can fit a lot better in, than trying to retrofit a baremetal containerized environment into a large enterprise datacenter where everything is already running Windows servers and proprietary services, managed by other people than yourself.

[naasking]

> The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary.

That's wrong. They rightly believe that traditional operating systems deployments come with much larger attack surfaces.

[Veserv]

There is no meaningful security difference between commercial operating systems and hypervisors when considering technically competent, commercially-motivated attackers. No systems built on such insecure systems can stop even minor attacks staffed by a single-digit number of FTEs. Maybe there is a material difference, but it is irrelevant compared to their total inadequacy relative to the present threat landscape. The person who can climb Mount Everest is still no closer to achieving orbit than the person who can only climb a tree.

To move beyond the mere practical aspects, even theoretically you are wrong. The techniques needed to develop a secure hypervisor are basically exactly the same techniques needed to develop a secure operating system. They are almost trivially transferrable. If you can do one, you can do the other. So, again, no advantage to preferring a hypervisor based solution.

[naasking]

Even if I accepted the claim that the techniques are the same, it's irrelevant. It's simply a matter of fact that standard installs of commodity server operating systems have a significantly larger attack surface than a unikernel system. Sys loggers, email agents, inflexible and insecure user/group access control, and just general ambient authority. Unikernel systems have none of this cruft by default.

[0xDEAFBEAD]

>The only reason to prefer a unikernel is because you wrongly believe that hypervisors are a security boundary.

Thoughts on Qubes?