Op seems to misunderstand the following:
1. Your hypervisor is the security boundary. 2. Unikernel design lets you maximize the security benefits of AppSec and LangSec by removing the large OS surface area.
1. Your hypervisor is the security boundary. 2. Unikernel design lets you maximize the security benefits of AppSec and LangSec by removing the large OS surface area.
On 1) " Hypervisor vulnerabilities emphatically exist; one cannot play up Linux kernel vulnerabilities as a silent menace while simultaneously dismissing hypervisor vulnerabilities as imaginary"
This is obvious, but it's true that people somehow think hypervisor vulnerabilities don't exist. Amazon and Linode just rebooted a bunch of machines because of a Xen vulnerability. Could something like Xen be more secure than the Linux kernel? Maybe. That's a good question, and one I haven't seen the answer to.
I actually doubt it because emulating hardware is probably full of more "C tricks" than kernel code, but I'm not an expert here. Another complication is that when you use a hypervisor, you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone. But there are probably some mitigating factors.
2) "And to the degree that unikernels don’t contain much code, it seems more by infancy (and, for the moment, irrelevancy) than by design."
I agree that unikernels are smaller at the moment mostly because they don't have a lot of features. (Writing in a memory safe language helps, but it also hurts! Because I need to run linear algebra in production, etc.) When you run them on a hypervisor, they actually rely on Linux for real drivers and such. So you're not actually getting rid of the code -- you're moving it around.
The answer might possibly be 'yes': https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xe...
The reasoning is that Xen is fairly small, so relatively easy to audit by hand, OpenBSD-style.
It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux).
>you always have Linux in addition. You generally use its drivers for the real hardware. It would seem that Linux + hypervisor is less secure than Linux alone
Doesn't have to be Linux - but even if it is, users have no way to exploit most Linux vulnerabilities because the hypervisor (hopefully) doesn't make most possible system calls.
> It ought to be, because the attack surface is zillions of times smaller (x86 spec vs all the system calls offered by linux).
Bullshit. Either your Hypervisor is a user mode program (it uses syscalls) and therefore requires a full kernel underneath all of the other abstractions you've got (which makes it slower). Or it's like KVM, where it's kernel mode and thus doesn't need syscalls to break the host (does the phrase "floppy driver local root" mean anything to you?).
Of course, nobody would listen to "you're all idiots for continuing to run Linux when I gave you this perfectly good Linux emulation on Solaris without a CVE every week" either. (Myself included, to be fair.)
Further unikernels don't remove the large OS surface area they replace it with something that may or may not be larger and safer.
Many hypervisor security flaws which allow peeking between the VM isolation boundaries rely on sloppy protections around the virtualized virtual memory subsystem.
Most unikernel platforms don't even expose a virtual memory semantic, and thus don't consume these sometimes leaky hypervisor HAL implementation flaws. They don't use or expose the flimsiest floorboards in the hypervisor. A full OS (including SmartOS) on the other hand... definitely does.