[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.)