
Enhancing Qubes with Rumprun unikernels - snaky
http://northox.github.io/qubes-rumprun/
======
mwcampbell
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.

~~~
throwaway7767
> 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...](https://www.qubes-
os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf)

------
rwmj
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.

~~~
throwaway7767
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.

