> I'm really sold on the idea: Instead of a full-blown OS,
You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1].
You mean you are sold on the idea of going back to the 80s. We used to have an operating system with every game released[1].
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...
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.
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.
Thoughts on Qubes?
That's wrong. They rightly believe that traditional operating systems deployments come with much larger attack surfaces.
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.