Hacker News Reader

Comment by wmf | Hacker News Reader

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.

But they should definitely add ASLR.

View on HN

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 a unikernel, how would you even detect you've been hacked ?

Reply on news.ycombinator.com