Enhancing Qubes with Rumprun unikernels | Hacker News Reader

Enhancing Qubes with Rumprun unikernels

northox.github.io

38 pointssnaky5 comments

What makes a bunch of VMs running on a hypervisor inherently more secure than a bunch of processes running on a conventional OS kernel? Is the trusted computing base really any smaller in practice, particularly when the hypervisor in question is KVM on Linux, or even Xen with a Linux dom0? ANd when the VMs are unikernels, it seems to me that they're really just reinvented, heavier processes with a much-hyped new name.

> What makes a bunch of VMs running on a hypervisor inherently more secure than a bunch of processes running on a conventional OS kernel?

There's nothing inherently safer about it. I wouldn't trust a VirtualBox setup any more than I would the host OS running it. But it can be done in a way that isolates interfaces that are hard to audit, and that's what the Qubes project is. See the Qubes Architecture document[0] for more information on the various ways this is achieved.

> Is the trusted computing base really any smaller in practice, particularly when the hypervisor in question is KVM on Linux, or even Xen with a Linux dom0?

Yes, it is significantly smaller. If you're interested, you should read the Qubes Architecture document[0]. Chapter 8.2 specifically explores the Xen attack surface.

KVM on linux is not used in Qubes, so it's irrelevant here.

Most of the attacks on Xen have been attacks on device emulation, which is minimised in Qubes and what little there is is moved into stub domains (not run in dom0). There was a really serious Xen bug recently that did not fit that model, and it caused some panic - but it's telling that it's really the only such bug to be uncovered since Qubes started.

[0] https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a...

If you run a process you entrust it with everything that your uid has access to. If you run X, any process gets access to your input. Those aren't security bugs, it's the design, the Qubes design allows you to isolate apps you mistrust (like the browser).

If they're waiting 8.5 seconds for the VM to boot, then they're doing it wrong. On average x86 hardware, libguestfs boots its VM in about 2.5 seconds. We could easily get that down to 1 second if we were "allowed" to use a custom non-distro kernel. When we get all the changes in for Intel clear containers, I expect that to drop to a fraction of a second.

It does not take 8.5 seconds on my machine, the author must have a slow machine (no SSD?). I just tested and I can launch a full qubes VM in about 3.5 seconds. This is for a pretty-much-default qubes fedora template.

Disposable VMs are much faster, because they are essentially hibernated, and the hibernation image is stored in RAM. So there I can boot and launch firefox in about 2 seconds (really doesn't feel any slower than launching firefox on any other system).

Qubes is trying to provide a pretty bog-standard linux machine in the VMs, so as to be the most useful. They do have their own kernel, but I haven't looked at how stripped down it is.

Reply on news.ycombinator.com