So, basically, we're going to run all your code at ring0, so a single bug is now either a total DoS (kernel shuts down) or an exploit vector straight to ring0. Although they talk hypothetically about a defense for that involving the MMU, this is not implemented in IncludeOS.
The build should not be relied on to be secure either; certain classes of memory disclosure bugs could leak out enough memory to let you work out e.g. a ROP payload, which wouldn't require injecting any machine code necessarily. Plus, a long-lived machine, or a single instance deployed across many machines, would present insufficient diversity to protect against a determined attacker. The gist here appears to be the notion that their build diversity gives them most of their security, while they've eliminated most of the traditional defense layers (ASLR, DEP/NX, privilege separation, API isolation, etc.)
If the attacker gets her machine code running in the unikernel environment, it's game over no matter what. The machine code can just directly implement a subset of needed functionality without having to call out to unikernel functions.
In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".
Keep in mind that it's ring 0 inside a VM that contains almost nothing. Really a unikernel is just a process that uses hypercalls instead of system calls. So exploiting a unikernel is no worse than exploiting a user process, and the article explains a few reasons it could be more secure.
Just like an operating-system executes processes, a VMM executes unikernels. An operating system is responsible for randomizing the layout of processes in memory. Shouldn't the actual question here be "Does my hypervisor implement some mechanism for randomizing the layout of my unikernel?"
I don't think it matters whether it's implemented by the hypervisor or the unikernel since it's all open source. But for compatibility with existing hypervisors/clouds one could imagine a boot loader that loads the main unikernel at a random address, sets up page tables with NX, and then makes a one-way transition to ring 3 so that the page tables cannot be modified.
> one could imagine a boot loader that loads the main unikernel at a random address, sets up page tables with NX, and then makes a one-way transition to ring 3
True - I suppose I'm trying to hold onto the "kernel:hypervisor :: process:unikernel" analogy here for no good reason. Following it suggested that it might be the hypervisor's responsibility.
IncludeOS has ASLR. Or as close to ASLR as you can get without dynamic linking. We randomize the layout when we link. And since we typically re-link the image on each configuration change in a network of 1000s VMs each one will have a different memory layout.
> In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".
From the original pull request drafting this post:
> While I agree that making hyperbolical claims isn't typically good I'm not sure if it is bad here. There seem to be a tradition in unikernel land with outlandish claims in various blogposts ("Unikernels will kill containers in five years", "Unikernels are unfit for production", etc) so I wrote it with that tone in mind.
If the unikernel people keep up with the hyperbole the potential audience will learn to just ignore most posts about unikernels. Please don't use hyperbole.
> So, basically, we're going to run all your code at ring0
From the article: 'However, if the hypervisor can set up the VM before it is booted and provide paravirtualized interfaces to the hardware, we don’t need access to ring 0.'
The build should not be relied on to be secure either; certain classes of memory disclosure bugs could leak out enough memory to let you work out e.g. a ROP payload, which wouldn't require injecting any machine code necessarily. Plus, a long-lived machine, or a single instance deployed across many machines, would present insufficient diversity to protect against a determined attacker. The gist here appears to be the notion that their build diversity gives them most of their security, while they've eliminated most of the traditional defense layers (ASLR, DEP/NX, privilege separation, API isolation, etc.)
If the attacker gets her machine code running in the unikernel environment, it's game over no matter what. The machine code can just directly implement a subset of needed functionality without having to call out to unikernel functions.
In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".