QubesOS
Port Qubes OS to KVM
This issue tracks the work done for KVM development and integration.
This is a subset of tasks for https://github.com/QubesOS/qubes-issues/issues/4318.
References:
- https://groups.google.com/forum/?oldui=1#!topic/qubes-devel/dIw40asXmEI
- https://github.com/shawnanastasio/libkvmchan/issues/12
I wonder what version of KVM is used by Google Compute Engine. That version has a fantastic security record, IIRC.
Does this mean that any future projects (that are esp. VMM-sensitive) on Qubes OS shall not rely on Xen being available as an option for backend VMM?
Does this mean that any future projects (that are esp. VMM-sensitive) on Qubes OS shall not rely on Xen being available as an option for backend VMM?
I'm not sure to understand your point. Currently, it's only a matter to allow running Qubes OS on KVM.
I wonder what version of KVM is used by Google Compute Engine
According to this guy (and suggested in blog posts by Google) - "GCE is built with a forked version of KVM. Google even created their own qemu replacement among many other things in that space."
I haven't found any other details though.
I don't believe so; they have wanted it to be VMM independent for a long time and are porting it to KVM for a variety of reasons(PPC64, better GUI passthrough, etc.). See here, here, and here
Xen will remain the default, at least for now, due to being significantly more secure.
Not sure if this is the right place to post this, but crosvm may be more interesting than KVM for a Qubes port. One of the disadvantages of KVM over Xen is that it is significantly less secure. Crosvm is based on KVM so theoretically has the same advantages as KVM, but it is written in Rust and it allows sandboxing virtual devices making it more secure than KVM. It is also designed for desktop use(as opposed to Firecracker), which is why it is also used by SpectrumOS. Spectrum has also improved on crosvm to run devices completely separate: https://alyssa.is/working-on-crosvm/
The community is documenting pros and cons in an architectural discussion on the qubes forum here: https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-other-than-xen-abstracting-the-functionality-early-stage/23478/8
@flflover mentioned this thread there.
This would be in fact very neat and I would like to publicly express my support for "Qubes on KVM" initiative and wish you good luck
I think the main blockers at this point are:
- There is currently no implementation of libvchan for KVM. Qubes OS uses libvchan for qubesdb, qrexec, audio, and GUI.
- The GUI daemon relies on grant tables. The GUI daemon is also going to be replaced by virtio-GPU cross-domain contexts, though. Ironically, those don’t support Xen yet.
- KVM has very poor support for driver domains. Networking, specifically, can be handled by a userspace proxy that provides a vhost-user network device to all of the firewall’s VMs. Spectrum OS is already implementing this. However, this does not work for block or USB devices.
- Linux’s poor security policy means that this would require weekly kernel updates. On the other hand, GPU acceleration will already require this, so getting the infrastructure in place is necessary anyway.
(Disclaimer: not a current Qubes OS developer, but I was for several years.)
I will also add that, given my past interactions with the Qubes team, I believe that high-quality PRs adding KVM support would be accepted. @fepitre even did some of the work in the past, though it wasn’t finished.
In the long term, I think a KVM libvchan port is the main blocker. The GUI daemon will lose its grant table requirement once it is replaced by virtio-GPU. Weekly kernel updates are already needed for GPU acceleration, and Spectrum needs to solve the driver domain problem as it has the same requirements. A community member already ported libvchan to KVM, but the port was never merged.