Back in 2013 we've started the work on generalizing Qubes architecture, which we code-named “Odyssey”, to allow for use of multiple hypervisors instead of just Xen via Hypervisor Abstraction Layer (“HAL” -> “Space Odyssey”, get it? ;). The concept has been described in this post, which I recommend to re-read if you're more interested in understanding our goals.

We have been wandering here and there since that time. Lots of work has been invested in the light-weight Qubes edition for Windows, which, sadly, turned out to be a failure.

We have also done a lot of work in the meantime to polish Qubes R2 and bring it to the state of the final release, which happened earlier this fall.

We have also been heavily researching possibilities of other cool projects based on this flexible new architecture. Some of which you might hear about in the coming months, others turned out to be dead ends.

Today we're finally releasing the Qubes R3 source code to the public. The code builds fine (see here for building instruction), produces install-able ISO, and, if that was not enough, even seems to be working, mostly fine, when installed :)

However, we don't recommend users to switch to it, and we intend this release for developers only, specifically those who would like to start working towards porting of other hypervisors, or other containerization technologies, like LXC, to Qubes R3. I highly recommend these devlopers to discuss what they try to achieve on the qubes-devel mailing list, before they start the actual coding.

Currently the only implemented and supported backend is Xen, of course, specifically the Xen 4.4, currently the latest version. It should be now trivial to switch to future versions as they become available, although, a decision to rush with that might not be such a no-brainer from the security point of view. We should remember that the hypervisor, unlike Linux kernel, is not someting you would like to change every month or so. Ideally we should aim for having a stable version of Xen for desktops that would work for years without needing any updates.

But use of other hypervisors might open up lots of interesting possibilities: imagine e.g. Qubes Live USB edition that has backends for 1) Xen, 2) KVM, and 3) LXC, and choose automatically the most secure one which is still supported on the given laptop.

Major features of the current release, compared to Qubes R2:
  • Hypervisor Abstraction Layer for all the core management stack (but still missing for the GUI daemon, see below)
  • New implementation of vchan and qrexec. As you might know our original vchan has been rewritten and improved (better performance and flexibility) and included in the upstream Xen starting from v4.2. Now we're switching to this upstream libvchan. Also, qrexec has been slightly rewritten to utilize some new features of this libvchan, which results in much better performance for inter-VM traffic (like a few orders of magnitude better!) Especially important for things such as USB virtualization that we're testing right now (not to be confused with USB controller pass-though).
There is still some work going on which we would like to complete before we officially decide to release Qubes OS 3.0-rc1 ISO, and this includes:
  • Rewrite of some internal code for the core management stack, which includes internal API of the python classes. This should mostly be of no interest to users, and even most developers working on Qubes.
Further down the road (Qubes OS 3.1) we plan to work on some really exciting things:
  • More flexibility to qrexec policy (more on that in a separate post)
  • More flexibility to Qubes Admin API (expose it to slelect other VMs)
  • Split of Dom0 into (semi-depriviliged) GUI domain and minimal Admin domain. This would be great opportunity to also add the missing HAL support for the GUI daemon.
One of the immediate application of these features above would be to introduce support for remote management of Qubes installations, an absolutely necessary feature for corporate adoption of Qubes.

Also note how all these tasks are independent of the actual hypervisor support, meaning it's perfectly possible for other developers to work on porting other hypervisors to Qubes in the meantime.

The possibilities seems to be endless now. Join us and help us with The Revolution! :)