Friday, June 21, 2013

Qubes OS R3 Alpha preview: Odyssey HAL in action!

In a previous post I have outlined a new direction we're aiming with the Qubes project, which is a departure from using a “hardcoded” hypervisor with Qubes (as well as “hardcoded” Linux as Dom0, GUI domain, etc).

Today I'm happy to announce that we've already completed initial porting of the current Qubes OS into this Hypervisor-Abstraction-Layer-based framework. The new version of Qubes, that we call “R3 Alpha” for now, builds fine, installs fine, and even (mostly) works(!), as can be admired on the screenshot below :) It still uses Xen, of course, but this time in a non-hardcoded way, which allows to replace it easily with another hypervisor, as I discuss below.

Our Qubes Odyssey backend needed to support a specific hypervisor comprises essentially three parts:
  1. A libvirt driver to support a given VMM. In our case we got it (almost) for free, because Xen 4.2 is well supported by libvirt. I wrote “almost” for free, because some patches to libvirt were still needed, mostly to get rid of some unjustified simplifying assumptions, such as that all the backends are always in Dom0, which is not the case for Qubes OS, of course. Some of those patches were accepted into upstream libvirt, some (still) not, so we had to fork libvirt.
  2. A VMM-specific implementation of our vchan – a simple, socket-like, VMM shared memory-based communication stack between the VMs. Again, in case of Xen 4.2 we got that (almost) for free, because Xen 4.2 has now included a libxenvchan component, which is modified (improved and cleaned up) version of our original vchan (written in early Qubes days for older Xen versions) contributed and maintained by Daniel De Graff from the NSA.
  3. Some minor configuration files, e.g. to tell libvirt which hypervisor protocol to use (in our case: xen:///), and VM configuration template files.
Now, if one wanted to switch Xen for some other hypervisor, such as e.g. the KVM, we would need to write a KVM Odyssey backend in a form of providing the above mentioned three elements. Again, libvirt driver we would get for free, configuration files would be trivial to write, and the only task which would require some coding would be the vchan for KVM.

Ok, one thing that is left out (non-HAL'ified) for now, is the xc_map_foreign_pages() Xen-specific function call within our GUI daemon.

Ideally such call could also be handled by the libvirt API, however it's not clear to us whether true zero-copy page access is really supported (and intended). If it is not, we will try to contribute a patch to libvirt to add such functionality, as it is generally useful for many things that involve high-speed inter-VM communication, of which our GUI virtualization is just one example. So, at this moment, one would need to add an ugly #if (BACKEND_VMM == ...) to the code above and use another VMM's function(s), equivalent to the xc_map_foreign_pages() on Xen.

But besides the above, essentially everything else should Just Work (TM). And that's pretty amazing, I think :) While I personally can't immediately see any security benefit of switching from Xen to KVM, it might appeal to some people for other reasons (Performance? Better hardware support?). The point is: this should be now easy to do.

If one wanted to support some Windows-based hypervisor, on the other hand, such as MS Hyper-V, or Virtual Box on top of Windows, then two more things will need to be taken care of:

  1. Our core management stack (the core-admin repository), the core RPC services (mostly the qrexec daemon, currently part of core-admin-linux repo), and the libvirt code (core-libvirt, a forked original libvirt with some custom patches I mentioned above), all would need to build and run fine on Windows. While this is not a big problem for core-admin (it's all python) and core-libvirt (it is supposed to build and run on Windows fine), the qrexec daemon would need to be rewritten with Windows OS in mind. We're currently working on this step, BTW.
  2. The GUI daemon would also need to be ported to run on Windows, instead of on top of X Server. This is somehow orthogonal to the need to get rid of the hardcoded xc_map_foreign_pages() function as mentioned above. This step might be optional, however, if we wanted to use a Linux-based (and so Xorg-based GUI server) as a GUI domain.

Once the above two pieces are made Windows-ready (note how I wrote Windows-ready, and not specific-VMM-ready), we can then use any Windows-based hypervisor we want (i.e. for which we have libvirt driver, and can write vchan).

This is again pretty amazing, because it means we don't need N*M variations of each component (where N is the number of VMMs, and M the number of host/GUI OSes to support) – but only N+M! This is similar to how modern compilers are designed using a language-specific frontends (C, C++, Pascal, C#, etc), and architecture-specific backends (x86, x64, ARM, etc), and an Intermediate Language for internal “grinding”, again achieving this N+M number of needed variants instead of N*M, which otherwise would be just totally impractical.

One other detail I would like to point out, and which is also visible on the screenshot above, is that we also got rid of using the Xen-specific Xenstore infrastructure (a registry-like tree-based infrastructure for inter-VM configuration and status exchange), and we replaced it with our own, vchan-based Qubes DB (core-qubesdb).

One interesting thing about Qubes DB is that it get rids of the (overly complex and unnecessary) permission system that is used by xenstore, and instead uses the most simple approach: each VM has its separate Qubes DB daemon, and so a totally separate configuration/state namespace. This is inline with the rest of the Qubes philosophy, which basically says that: permissions is dead, long live separation!

So, in Qubes OS we just isolate everything by default, unless a user/configuration specifically allows an exception – e.g. no file copy operation between domains is possible, unless the user expresses an explicit consent for it.

Many old-school security people can't imagine a system without permissions, but if we think about it more, we might get to a conclusion that: 1) permissions are complex and so often difficult to understand and set correctly, 2) require often complex code to parse and make security decisions, and 3) often are absolutely unneeded.

As a practical example of how permissions schemes might sometime trick even (otherwise somehow smart) developers into making a mistake consider this bug in Qubes we made a long time ago when setting permissions on some xenstore key, which resulted in some information leak (not much of a security problem in general, but still). And just today, has published this advisory, that sounds pretty serious, again caused by bad permissions on some xenstore keys. (Yes, we do have updated Xen packages to fix that, of course).

Back to Qubes R3 Alpha, the first successful Qubes based on Odyssey HAL framework. As previously mentioned, we plan to make most of the framework open sourced, specifically all the non-Windows code. However, we're not publishing this Odyssey/R3 code at this moment, mainly for two reasons: 1) we don't want people to immediately start building other backends, such as to support KVM, right at this stage, because we still might want/need to modify some interfaces slightly, e.g. for our vchan, and we don't want to tide our hands now, and 2) the other reason is that we're still in the middle of “Beta” releases for Qubes R2, and we want people to rather focus on testing that, rather stable release, than jumping onto Qubes R3 alpha.

In other news: everybody seems to be genuinely surprised that unencrypted information can be intercepted and analyzed without user consent... Can it be that people will "discover" cryptography now? How many of you use PGP everyday? And how long will it take then to understand that cryptography without secure client devices is useless?


Smattr said...

Great news, Joanna. Minor correction: I think you meant to say "...hypervisor comprises essentially three parts", not "compromises."

Joanna Rutkowska said...

Yes :) Thanks Smattr.

Anonymous said...

In regard to your remarks at the end about PRISM, encryption and people becoming aware of these things I'd suggest following articles about quantum computers and how they can or will be able to decrypt any algo in seconds or minutes:

Google and NASA have just bought a 512 qbit quantum computer few months ago from D-Wave and it seems to be a trend that govts. and other corporations (think of Telecom providers!) will catch up with upgrading their equipment as soon as prices drop a little.

Todays encryption will become totally obsolete and probably already is in regard to intel agencies. Now that is stuff that has become public (albeit silent) but we all know that in secret the technology is at least 20 years ahead.

15-20 years ago when first Nintendo came out or the first 286 PC with ridiculous capacities, todays technology we would have called "impossible" or "Science Fiction". That naive thinking is one of the reasons mankind follows its "leaders" blindly and which lead us to where we are today.

That's one of the main reasons, as outlined in one of the articles, why govts. worldwide save and store all communications data indefinitely. So that they can decrypt protected files and communications over time when computing resources drastically increase, and soon to an extent they'll decrpyt it in near or real time ;-)

So it seems we'll need quantum computers soon to develop new encryption algos which cannnot be cracked by q-computers :-)

Joanna Rutkowska said...


The articles you referred to are full of inaccuracies, the most obvious one being that the author treats both public-key schemes as well as symmetric crypto schemes like if they were both equally vulnerable to the quantum cryptoanalysis. While it is currently being disputed whether quantum computers can be built so that they can break currently-used public-key schemes, it is not the case for symmetrical crypto, which most (all?) researchers agree are not vulnerable to quantum-based cryptoanalysis.

Here's some more toned down reporting on Google's "quantum computer":

Christian said...

I really do like qubes-os, but I stumbled upon a cherry that might even give qubes the stomach aches:

I don't even want to think about whether it was possible to read the luks-keys or not.

Timo Ollech said...

"contributed and maintained by Daniel De Graff from the NSA" - you checked his code thoroughly, didn't you?!?

Joanna Rutkowska said...

@Timo: No, why? Are you saying the American government couldn't be trusted. Nah...

Anonymous said...

@Timo: Using that logic, SELinux is massive backdoor ;-)
The reality is a little deeper then that. The NSA works on increasing security for products, just as much as it works on breaking said security. The best outcome for the NSA is making a product secure against common threats, while having a non-obvious backdoor for their own purpose. So are the projects they worked on secure?, Probably. Do their projects have some kind of back door to subvert security? You bet!