3 ms·

Enhancing Qubes with Rumprun unikernels

38 points by snaky 11y ago

rwmj 11y ago
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 11y ago
  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.
mwcampbell 11y ago
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.
- kryptiskt 11y ago
  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).
- throwaway7767 11y ago
  > 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/arch-spec-0.3.pdf https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a...

38 points by snaky 11y ago

rwmj 11y ago

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 11y ago
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.

mwcampbell 11y ago

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.

kryptiskt 11y ago
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).
throwaway7767 11y ago
> 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/arch-spec-0.3.pdf https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a...