Do Unikernels even have real value?

Posted Jul 28, 2017 7:22 UTC (Fri) by alonz (subscriber, #815)
Parent article: IncludeOS: a unikernel for C++ applications

I'm in the camp that considers the entire idea of unikernels to be a net regression in almost all meaningful metrics.

When you ignore the hype, a hypervisor is no different than a run-of-the-mill kernel. It has precisely the same tools at its disposal for dividing resources among tasks (sorry, “domains” is the new buzzword for those) and protecting them from interfering with each other. The only true difference is that hypervisors expose a lower-level API (virtual hardware) vs. kernels' richer interfaces, which actually gives the hypervisor less power to regulate behavior.

When this is combined with unikernels, we have userspace code running in the CPU's protected mode—which means vulnerabilities in this code give attackers even more powerful tools to play with. And this code talks to hardware via minimally-protected interfaces. Nothing to worry about, right?

In short: I hope this remains as an academic exercise. And I doubt any serious cloud providers will allow such magical-thinking solutions near their hardware.

Do Unikernels even have real value?

Posted Jul 30, 2017 10:05 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

The one difference is hardware protection. You now have the hypervisor in ring -1, the guest kernel(s) in ring 0 and userspace(s) in respective ring 1s. Each with different hardware privilege levels.

Do Unikernels even have real value?

Posted Jul 31, 2017 14:29 UTC (Mon) by robbe (guest, #16131) [Link]

For hypervisors in general, you are right. But unikernels eschew user space, so you are only left with rings -1 and 0…

Do Unikernels even have real value?

Posted Aug 3, 2017 14:59 UTC (Thu) by perbu (guest, #14372) [Link]

The amount of legacy shit we currently have to deal with in order to boot virtual machines is incredible. If virtual machines didn't have to pretend it's 1982 development would be a lot quicker.

The reason unikernels need to run in ring 0 is only because of legacy. At some point I expect IncludeOS to start in ring 0, set up page tables and hardware and then chain-load a second includeos unikernel that is running in ring 3. As they are single process the need to restrict access to things like virtual network adaptors is not needed.

But even if we're running in ring 0 trying to compromise a virtual machine with an unknown memory layout and no system calls is .,. challenging. And contrary to what you're indicating there is nothing magical about running in ring 0. Code doesn't automatically get insecure by escalating its privileges. If your application is running on ring 3 on a Linux server that application has a lot more control over the vm than a unikernel has. If I compromise your linux application I can execute the shell, write files, execute processes, call home and do all sort of crazy stuff. If I compromise a Unikernel I can ... well, there isn't really much you can do as everything that isn't explicitly used by the application gets left out by the linker.

Even if there is functionality to say, connect home, how would you call that function? Trying to guess 64 bit addresses?