While the “Qubes 1.0” branch is
currently in the final development and testing, we have already
started working on the Next Big Feature, which is a support for HVM
domains (hardware, or VT-x virtualized domains). This allows to run
e.g. Windows VMs under Qubes. You might be wondering what so special
about this, if Xen has been supporting HVM domains, and specifically
Windows VMs for a long time, and Qubes uses Xen hypervisor, so why
haven't we had Windows support since day one?
The are a couple of things that we
don't like about HVM support in Xen (and also in other VMMs), which
include: the need to run device emulator (AKA qemu) in Dom0, the need
to use crappy VNC, or a similar protocol to access the VM's
framebuffer, or alternatively, the crazy idea (from security point of
view, that is) of using a pass-through graphics for a VM, the lack of
support for disaggregated architecture where backends, e.g. network
backends, run in other domains than Dom0. In fact even the Xen
“stubdomain” feature, introduced a few years ago, that was
supposed to be a solution allowing to move the qemu out of Dom0, in
practice turned out to be quite disappointing, as the qemu in the
stub domain still requires an accompanying process of another qemu in
Dom0, somehow negating all the security benefits this architecture is
supposed to bring... And not to mention the omni present assumption
that backends run always in Dom0, hardcoded in a few places in the
stubdomain code.
So, we didn't like it and that's why
Qubes had no Windows support for long time. But this has now changed,
as we have just finished the 1st stage implementation of
HVM support in Qubes, the way we like it, without any security
compromises. In our implementation we've completely eliminated all
the qemu remains from Dom0 (it's running in a micro stub domain), the
graphics virtualization fully integrates with our very slim GUI
daemon (we didn't have to modify our GUI daemon at all!), using our
Xen-optimized, zero-copy, minimalist GUI protocol, and the networking is
also fully integrated with the Qubes diaggregated networking architecture
that uses isolated domains for all the networking stacks and drivers.
Of course, there are still some rough edges, such as no clipboard
support, and the virtualization is currently in a “per-desktop”
mode, rather than in a “per-window” mode, which is used for PV
domains. But, rest assured, we are working on those things right
now...
