[cbd1984]

> I really find it hard to believe that security is really wonderfully provided for in a unikernel

I think you've missed the point: The hypervisor provides security. The unikernel does not. Everything in the same unikernel guest is in the same security domain, meaning everything in the same unikernel guest trusts everything else in that unikernel.

The hypervisor is the correct level to provide security because that's all it does. It exists to securely multiplex hardware, to allow multiple unikernel guests to run on the computer at the same time without having to be aware of each other. The hypervisor is, ideally, invisible, in that its only "API" is intercepting hardware access attempts and doing its magic at that point; it provides no abstractions of any kind, so it can be as simple as possible. You can't hit what you can't see, and you can't exploit code which isn't there.

The hypervisor of course uses all of the hardware tricks the CPU provides to provide isolation. Modern virtualization hardware fits the bill just fine here.

It's therefore possible for unikernels to establish and enforce their own security policy, just like how you can run Linux as a guest under Xen. It's just that it shouldn't be necessary in a proper hypervisor/unikernel setup, because everything running in the same guest should trust each other and only need to worry about information coming in from the outside world.

[lolo_]

Sure, but what about private state in the unikernel? If I exploit it, I have access to everything inside it without restriction, I could even change the way the drivers work totally transparently to the rest of the software.

Is the idea that a single unikernel is equivalent to a single process? Surely we're getting into realms of serious performance issues if that's the case?

I do take your point on there being less going on meaning there is less to attack, and what you are saying is very interesting, don't get me wrong :) I'm just trying to understand it.

There have been hypervisor exploits, but of course far fewer than linux/windows/mac escalations

[eru]

> Is the idea that a single unikernel is equivalent to a single process?

Yes.

A unikernel is equivalent to a process in a more traditional system. We usually don't secure parts of a process against other parts of the same process. We just start more processes.

> Surely we're getting into realms of serious performance issues if that's the case?

Why?

[lolo_]

> Why?

Are you suggesting running an entire virtualised kernel in place of a process is not going to introduce a performance penalty?

There might also be latencies introduced in IPC.

[eru]

If you ran an virtualized version of an entire traditional kernel, you'd have a hard time with performance. So that's not what you would be doing.

Go, read the old exokernel papers (see https://en.wikipedia.org/wiki/Exokernel#Bibliography, especially http://pdos.csail.mit.edu/exo/theses/engler/thesis.ps). They got nice performance improvements out of running their equivalent of unikernels. It's exactly because they can cut through all the layers of one-size-fits-all abstraction.

They also address IPC.

(This reminds me, I should go and re-read how they actually did IPC.)