Main menu

Tor at the Heart: Qubes OS

During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.Donate today!

Qubes OS

by Michael Carbone and Andrew David Wong

Qubes OS is a security and privacy-oriented free and open source operating system that provides you with a safe platform for communications and information management. Its architecture is built to enable you to define different security environments (or "qubes") on your computer to manage the various parts of your digital life, including safely using Tor.

"If you're serious about security, @QubesOS is the best OS available today. It's what I use, and free. Nobody does VM isolation better."
--- Edward Snowden

Qubes OS allows you to safely manage the different communications, data, and identities in your digital life in securely compartmentalized qubes. All of these qubes are integrated into a single desktop environment with unforgeable colored window borders so that you can easily identify applications and windows from different security environments.

Some features of Qubes OS include:

Safer anonymous browsing

Qubes incorporates Whonix to provide a safer way to use Tor Browser, by compartmentalizing the Tor Browser and Tor process in separate qubes. This means that if the Tor Browser is exploited, the attacker still cannot discover your real IP address, because the Tor Browser and its qube do not know your real IP address. Moreover, that compromise cannot spread from Tor Browser to the Tor process, since they are isolated in different qubes, so any other Tor-related activities you have in other qubes remain secure and private.

Enforce Tor use for non-Tor-aware applications

Once a qube is set to use the Tor network, all network traffic that leaves it is forced to go through Tor. This means that no matter which applications you use, they will not be able to leak your real IP address, even if they are not Tor-aware.

All software and OS updates through Tor

Qubes allows users to download all software and OS updates through Tor, which means that network attackers can't target you with malicious updates or selectively block you from receiving certain updates. In addition, downloading all updates through Tor preserves your privacy, since it prevents your ISP and package repositories from tracking which packages you install.

Robust and safe networking

In addition to easily running non-Tor-aware programs through the Tor network, you can -- at the same time -- have other qubes go through VPNs or be non-networked, for instance to enable easily accessible but offline storage of sensitive information like your password manager. Common attack vectors like network cards are isolated in their own hardware qube while their functionality is preserved through secure networking and firewalls.

Secure communications

Qubes is integrated with existing secure communications tools like Pretty Good Privacy (PGP) to provide security-in-depth and reduce user error. With Split-GPG functionality, a compromise of your email client does not enable an adversary to access your private PGP key.

Safely interact with untrusted media

You can open an untrusted attachment from your email client, and any potential malicious payload in the document is isolated to a separate disposable, non-networked qube. No information from that session can be sent to the attacker, since it is not connected to the internet, and after the document has been read, the entire domain is deleted. You can convert the PDF to a “trusted PDF” that is known not to be malicious, which you could then share with colleagues or save in an offline Documents qube for later reference. In the same way, a potentially malicious DOC file can be opened in a disposable qube that enables the user to edit the file, save it, and send it without providing an opportunity for potential computer compromise.

Windows integration

Many users still rely on Windows-based programs for their work. Qubes enables them to do so securely.

Physical security

Qubes also protects your computer against some physical attacks. If an adversary plugs a malicious USB device into your computer while you're not watching, it isn't game over. Qubes isolates the entire USB stack from the rest of the system. And if you want to dual-boot, or if your computer is seized at the border and then returned, you can tell whether a malicious bootloader was installed, so you know not to input your decryption password.

Smooth integration of qubes

Integrated file and clipboard copy and paste operations make it easy to work across various qubes without compromising security. The innovative Template system separates software installation from software use, allowing qubes to share a root filesystem without sacrificing security (and saving disk space).

There are many different ways to contribute to Qubes, including creating artwork, reporting bugs, editing documentation, making financial contributions and more. If your company would like to license Qubes, please contact the Qubes team.

There is an experimental live USB image on their downloads page. At this point, it is really only intended for trying Qubes to see if the hardware is supported and if the basic functions work. Using it for extended periods of time is almost guaranteed to cause instability.

Qubes is a nice concept, but the implementation has some real downsides. Being based on vanilla Fedora, it lacks grsecurity/PaX hardening patches, and it uses Xen, which is... not the best hypervisor around, as we all have found out in the last two years. It uses Linux under the hood, and a non-hardened version at that. The protection against DMA attacks can be accomplished with proper DMAR tables and Intel TXT. It also does not protect against cross-VM biometric fingerprinting and keylogging via cache-timing attacks (the major ones being flush+flush, flush+reload, prime+probe, and evict+time).

But the ability to integrate with other OSes is nice for new users, so it's useful to prevent accidental leaks. But against a nation-state adversary, you'd need something with mandatory access controls and grsecurity, not Qubes. Ideally that would be Subgraph OS, when it's mature.

If it used grsecurity, intra-VM mandatory access controls, a hypervisor like KVM (or Xen on top of a secure microkernel, rather than Xen on top of vanilla Linux), and had a warning about cross-VM side-channel attacks, it would be a lot better.

mac is bad managed : SE is not the right way, apparmor is buggy & tomoyo has one maintainer ; these features are bad explained , bad implemented , the freedom of choice is not present and it does nor run per default at the boot (an option at the install step should show us the 3 choices ! ) : that is a shame.
GR&pax are not free , your versions are certainly obsolete lol so absolutely useless.
A vanilla is not the right way , choose a clean kernel (without blob) could be a first step.
I do not know if sub graph is made for end-user and not for managing a large lan.

> mac is bad managed
This makes no sense. A MAC is managed by a sysadmin. You can manage them well, or you can manage them poorly.

> SE is not the right way
Do you mean SELinux? I'd like to hear you explain why you think that. It's a great MAC with RBAC and MLC capabilities.

> apparmor is buggy
AppArmor is very stable and probably one of the least buggy LSMs out there.

> tomoyo has one maintainer
That is true, though I don't know why it's relevant. Tomoyo would not be my first suggestion anyway.

> these features are bad explained , bad implemented , the freedom of choice is not present and it does nor run per default at the boot (an option at the install step should show us the 3 choices ! )
There is extensive documentation for all of them, and they are implemented through the well-designed LSM API. You have freedom of choice as you can select which one you want via a boot parameter. You don't even need to do it at the install step, you can choose at every boot.

> GR&pax are not free
Yes they are. I am using grsecurity right now. I didn't pay anything for it. You must be talking about the commercial version, which is still licensed under the GPLv2.

> GR&pax are not free , your versions are certainly obsolete lol so absolutely useless.
You make no sense.

<> you do not understand ! (at least you know your limit !!!)
Have you tried it or are you speaking by ignorance ?
> mac is bad managed
mac is managed within the soft of your choice ; a user should not read so much doc & how to , and should trust its mac protection with a gui or clear explanations it could better user-friendly and maybe felt like a necessity and not a tool for geek or paranoiac
> apparmor is buggy
apparmor e.g does not protect firefox but chrome - so the user thinks that his browser is protected (firefox) but it is not the case.
> SE is not the right way
do not follow this way because it' suits you , use the right tool for the right purpose : Se linux is a bad way if you are concerned by privacy or anonymous speech or circumventing/ censorship. (nsa tool, very complicated for a real protection, for experimented user only)
> tomoyo has one maintainer
tomoyo is a nice mac protection & one maintener is not enough for improvement.
> these features are bad explained , bad implemented , the freedom of choice is not present and it does not run per default at the boot (an option at the install step should show us the 3 choices ! )
you do not understand ! Have you tried it or are you speaking by ignorance ?
the choice of the security feature must be present on every cd:dvd ; it must be configured before the install and be managed rightly without any action of the user : these simple steps are not present !!!!
> GR&pax are not free
Gr& pax are not free (anymore) at all !!! it is finished !!! you have a short&not updated version (even with alpine) & runs without any protection !!! go the dev-site pls -

Before posting you should by yourself be educated and well informed but unfortunately it is not the case ...
the mac protection are not improved:finished:completed : too many hole and obscure tweak do not help the user to trust in his personal anonymous activity on the net ; tor is not enough.

> Have you tried it or are you speaking by ignorance ?
Have I tried the MACs? Yes, I've tried all of the ones I've mentioned, with the exception of TOMOYO which, as I mentioned, I only know a little about.

> mac is managed within the soft of your choice ; a user should not read so much doc & how to , and should trust its mac protection with a gui or clear explanations it could better user-friendly and maybe felt like a necessity and not a tool for geek or paranoiac

There is no such thing as a software which just provides immediate and magical protection with a simple GUI and clear explanations. The AV industry's scam has lead people to believe that such a thing is a reality. The reason security is difficult is because, if you want fine-grained control, you need a robust and bespoke solution.

> apparmor e.g does not protect firefox but chrome - so the user thinks that his browser is protected (firefox) but it is not the case.

AppArmor can isolate both Firefox and Chrome equally. However, the protection it provides to both are limited, as they are X11 applications. SELinux is a better choice for those, as there is an option to provide X11 isolation to it with a Xephyr-based sandbox. I believe Fedora is now using Wayland by default, in which case AppArmor and other MACs will indeed provide protection to both Firefox and Chrome.

In the Debian and Ubuntu repositories, there are pre-made policies for both Firefox and Chrome. If there are applications which do not already have policies, you will have to create them. It is not too difficult.

> do not follow this way because it' suits you , use the right tool for the right purpose : Se linux is a bad way if you are concerned by privacy or anonymous speech or circumventing/ censorship.

SELinux has nothing to do with privacy or anonymity. It is a MAC. It can be set to log file accesses if you set it to (this is called permissive mode), but this is stored only on your computer, and it is very obvious. AppArmor can do this as well, so it is not unique to SELinux. I have no idea what it has to do with censorship. Do you consider the fact that it is designed to block access to files "censorship"? That's sort of the purpose of access controls, but as you are the system administrator, you have the final say. SELinux will not, however, dictate what you are and are not allowed to access on the web.

> (nsa tool, very complicated for a real protection, for experimented user only)

SELinux was initially funded by the NSA. The computer mouse was funded by DARPA. So what? It's currently developed by the community, and by various companies which rely on it. You are right that it is very complicated. That is its biggest downside, both for adoption, and because it opens up the risk of security vulnerabilities through attack surface area.

Why do you say it is for experimental use only? It is very stable and has many users.

> tomoyo is a nice mac protection & one maintener is not enough for improvement.

You are right. The development is slow. I wish TOMOYO had a real development community behind it.

> the choice of the security feature must be present on every cd:dvd ; it must be configured before the install and be managed rightly without any action of the user : these simple steps are not present !!!!

Again, they are not simple tools. If you need something that takes absolutely no action, you're out of luck. Go back to Windows and try to delude yourself into thinking that Norton 360 makes you immune from hackers. If you do need an out-of-the-box MAC, Ubuntu and derivatives come with AppArmor pre-configured and enabled for several applications, and Fedora uses SELinux by default, though I believe it starts off in permissive mode. It is easy to change that by changing one configuration file.

> Gr& pax are not free (anymore) at all !!! it is finished !!! you have a short&not updated version (even with alpine) & runs without any protection !!! go the dev-site pls -

The least freely available update was January 9th, 2017. I am writing this on January 11th, 2017. You can see the currently updating changelog at https://grsecurity.net/changelog-test.txt to see for yourself. Distros also use a current version of grsecurity. I have Hardened Gentoo, and "tar tvf --wildcards */4420* /usr/portage/distfiles/hardened-patches-*.patch" shows the date as 2016-12-31.

> the mac protection are not improved:finished:completed : too many hole and obscure tweak do not help the user to trust in his personal anonymous activity on the net ; tor is not enough.

If you only think it's completed when it's a one-click solution to everything, then yes, it is not completed. It does what it is designed to do, control file and resource accesses based on a configurable policy set up by the sysadmin. Systems with predictable setups may have pre-configured policies. Otherwise, you'll have to set one up yourself. There is no alternative.

> Being based on vanilla Fedora, it lacks grsecurity/PaX hardening patches

I have to agree that Fedora might not have been the best choice for the Dom0 base. I probably would have chosen something like Alpine or maybe this Subgraph OS you mentioned.

> and it uses Xen, which is... not the best hypervisor around, as we all have found out in the last two years.

What incidents in the last two years are you referring to?

> It also does not protect against cross-VM biometric fingerprinting and keylogging via cache-timing attacks (the major ones being flush+flush, flush+reload, prime+probe, and evict+time).

Is KVM any better at this?

> a hypervisor like KVM (or Xen on top of a secure microkernel, rather than Xen on top of vanilla Linux)

In what way is Xen on vanilla Linux less secure than KVM on vanilla Linux? We would all prefer a secure microkernel, but Hurd and Minix are about the only options and neither one is practical. Hurd even has Dom0 support, but it the kernel is considered unstable and lacks many features, many of those being security features, even though the fundamental design is more secure.

> I have to agree that Fedora might not have been the best choice for the Dom0 base. I probably would have chosen something like Alpine or maybe this Subgraph OS you mentioned.

Alpine is especially nice because it uses a very lightweight and easy to audit libc. Being very lightweight overall, it's a nice choice for something that would run on Dom0. Subgraph is designed more for being a security solution on its own, with extensive sandboxing. Alpine is just made to be lightweight and hardened.

> What incidents in the last two years are you referring to?

I can't recall off the top of my head. They were bad enough that Joanna had a bit of a rant at the Xen developers for their lack of having any proactive self-defense mechanisms in the base at all, and relying entirely on reactive security, not proactive security. In the last two years in general, there have been a torrent of bug after bug. I wouldn't be surprised if, as I write this, a severe bug is in embargo right now. Xen has enjoyed being known as a rock solid hypervisor for a long time, but its reputation has been pretty much shattered in the past few years in the infosec community.

> Is KVM any better at this?

I was more pointing out the fundamental issue with using virtualization as a form of isolation on x86 hardware.

> In what way is Xen on vanilla Linux less secure than KVM on vanilla Linux?

Spender talked about that at length a while ago. The bigger issue is that Xen precludes using any hardening, whereas KVM doesn't. You can use a very stripped down grsecurity system with KVM with as many config options disabled as you want, whereas with Xen, you still have to use their Linux core (and I mean the core of Xen, not Dom0).

> We would all prefer a secure microkernel, but Hurd and Minix are about the only options and neither one is practical.

And both of those are quite insecure, even if Minix looks nice on paper. I would go with something like seL4 instead, or even SafeRTOS if something that lightweight is feasible (and if enough drivers can be made for it). I believe genode supports it. I don't know if Xen supports the L4 family of microkernels.

> Alpine is especially nice because it uses a very lightweight and easy to audit libc. Being very lightweight overall, it's a nice choice for something that would run on Dom0. Subgraph is designed more for being a security solution on its own, with extensive sandboxing. Alpine is just made to be lightweight and hardened.

It sounds like Alpine and SubgraphOS both have their own strengths then. In theory, a minimal Dom0 is ideal: smaller attack surface, and if you use the Dom0 for as little as possible, then sandboxing becomes less relevant. But in reality it's infeasible to get around running, e.g., an X or Wayland server in the Dom0, unless you can successfully PCI-passthru your graphics card. So I guess SubgraphOS's sandboxing features could be useful for sandboxing things like the display server. I don't know much about SubgraphOS, but from what I know it sounds like Alpine and SubgraphOS would both be reasonable choices, if for different reasons.

> They were bad enough that Joanna had a bit of a rant at the Xen developers for their lack of having any proactive self-defense mechanisms in the base at all, and relying entirely on reactive security, not proactive security.

I do sort of remember the Xen security controversy from a while back. I didn't follow it at the time, but I remember it did become a problem, but I got the feeling a solution was being worked on. I think they were trying for better auditing and development principles, though that of course can't mitigate all security problems.

Be careful not to lump QEMU's device emulation vulnerabilities in with Xen's, however. IIRC, VENOM affected QEMU's userspace floppy disk driver, and had really nothing to do with virtualization at all. Xen lets you run QEMU in its own DomU, under Grsec, as non-root, with whatever userspace application-level hardening you want, if you wish. If you chose to run it on your machine in Dom0 as root without Grsec, don't use that as proof that KVM is more secure. I might be off-topic and I'm not accusing you of it, I just wanted to note that here.

> I was more pointing out the fundamental issue with using virtualization as a form of isolation on x86 hardware.

Okay, point taken. But unless there is a virtualization product that can mitigate these issues, there isn't much we can do short of using a different architecture.

> Spender talked about that at length a while ago. The bigger issue is that Xen precludes using any hardening, whereas KVM doesn't. You can use a very stripped down grsecurity system with KVM with as many config options disabled as you want, whereas with Xen, you still have to use their Linux core (and I mean the core of Xen, not Dom0).

I would actually be really interested in reading/hearing that if you're able to find a link. I'm not sure its fair to compare "Linux with Grsec and KVM" to "Xen core without Grsec" if you're talking about the actual bare-metal kernel/hypervisor. Are you suggesting that Xen core itself is objectively not as hardened as Linux+Grsec+KVM? Does Xen core actually have a greater attack surface than a minimal but similarly portable Linux kernel? Just asking; I should really watch the aforementioned talk before going further on this.

> And both of those are quite insecure, even if Minix looks nice on paper. I would go with something like seL4 instead, or even SafeRTOS if something that lightweight is feasible (and if enough drivers can be made for it). I believe genode supports it. I don't know if Xen supports the L4 family of microkernels.

I shouldn't have brought up Minix at all, in the interest of staying on topic, that is, operating systems that actually support[1] being a Xen Dom0. So there are more secure microkernels out there that I wasn't aware of. Whether they can actually run on a wide enough range of hardware to justify porting Xen/Qubes to them is another question, and even then it would be no small task.

> I do sort of remember the Xen security controversy from a while back. I didn't follow it at the time, but I remember it did become a problem, but I got the feeling a solution was being worked on. I think they were trying for better auditing and development principles, though that of course can't mitigate all security problems.

It did become a problem, and it was a pretty big problem. Sadly the fact that it was a problem for so long has lead many in the security industry to drop Xen as their go-to for a solid hypervisor, which is why its reputation has taken such a bad downfall, whether or not they are working on it. It's a large project, so it'll take time to fix. The fact that we're discovering so many new breaks recently (not just the two) may be going to show that they're paying more attention to security, and (hopefully) attempting to weed out the bugs.

> Be careful not to lump QEMU's device emulation vulnerabilities in with Xen's, however. IIRC, VENOM affected QEMU's userspace floppy disk driver, and had really nothing to do with virtualization at all.

Of course. I was talking only about Xen and KVM, not about any userspace emulators or driver components.

> Okay, point taken. But unless there is a virtualization product that can mitigate these issues, there isn't much we can do short of using a different architecture.

Unfortunately there isn't. The clflush instruction can't be trapped by vmexit. I suppose a hypervisor for a NUMA system could isolate different domains to an individual NUMA node, since the attack only works within a single last level cache (e.g. L3), but most people have only a single CPU. Even if they have multiple cores, all the cores share the same last level cache, so they'd need multiple physical CPUs connected to different sockets on the same motherboard, and have the hypervisor move VMs that are to be isolated from each other to different physical CPUs. Not very practical, and not good granularity. Even ARM, which has a privileged clflush (so userland can't call it, only the kernel), still has an unprivileged equivalent in register 7... So the architecture would have to be *really* different. Like POWER maybe. Dunno.

> I'm not sure its fair to compare "Linux with Grsec and KVM" to "Xen core without Grsec" if you're talking about the actual bare-metal kernel/hypervisor. Are you suggesting that Xen core itself is objectively not as hardened as Linux+Grsec+KVM?

Yes. The Xen core is just a stripped down Linux kernel (with all the problems of vanilla Linux), with heavy patching to give it the functionality unique to Xen. When people talk about how light Xen is compared to Linux, they're talking only about these patches. It's like saying how light KVM is compared to Linux by only talking about the size of kvm.ko, as if the rest of the kernel wasn't also at play.

> Does Xen core actually have a greater attack surface than a minimal but similarly portable Linux kernel?

And is overall more vulnerable and easier to exploit than a similarly minimal Linux core with KVM and grsecurity. As they both provide the same general functionality (in the context of Qubes, VFIO allows KVM to provide the same secure device driver passthrough functionality), it is fair to compare them.

> I would actually be really interested in reading/hearing that if you're able to find a link.

This isn't what I was thinking of (he's written more about it), but he has a mini-rant about it here: http://seclists.org/dailydave/2010/q3/29. I'm sure you could ask him on OFTC. He comes around occasionally, on #grsecurity, as that's his channel.

> Whether they can actually run on a wide enough range of hardware to justify porting Xen/Qubes to them is another question, and even then it would be no small task.

Microkernels are, well, micro. SafeRTOS, FreeRTOS, seL4, Minix, ThreadX, etc. all support x86. As for the rest of the hardware drivers necessary to make it actually useful, like I2C, AHCI, PCI, VGA... that has nothing to do with the microkernel, unlike traditional monolithic/hybrid kernels. All of those drivers have to be implemented in userspace. I think FreeRTOS/SafeRTOS has both a full and a light networking stack, a FAT filesystem stack (no AHCI driver though), seL4 works on Genode with some modifications, and Genode supports AHCI, Minix has userland drivers for a bunch of things, but only on certain hardware, and ThreadX's source code is only available if you pay for it so I dunno what it has. Anyway, off-topic...

> Yes. The Xen core is just a stripped down Linux kernel (with all the problems of vanilla Linux), with heavy patching to give it the functionality unique to Xen. When people talk about how light Xen is compared to Linux, they're talking only about these patches. It's like saying how light KVM is compared to Linux by only talking about the size of kvm.ko, as if the rest of the kernel wasn't also at play.

Hmm, I didn't realize Xen core was based on Linux, but I guess I should have figured it was. I see now you said that in an earlier reply, but I thought you just said "[Xen's] Linux core" to mean their Xen baremetal hypervisor -- not that it was actually based on Linux.

I assume that, by extension, you're saying the grsec patch set is more secure than the Xen patch set. Hypothetically speaking, would rebasing the Xen core patch set atop Linux+grsec (instead of vanilla Linux) bring Xen core to a similar level of security as Linux+grsec+KVM (Dom0 being a separate matter)?

In other words, the issue has less to do with KVM itself (read: the KVM code in its respective subdirectory of the kernel tree) vs Xen core (read: whatever code goes into building /boot/vmlinuz-...-xen) than it has to do with the hardening (or lack thereof) (read: grsec-ification) of the rest of the kernel?

> And is overall more vulnerable and easier to exploit than a similarly minimal Linux core with KVM and grsecurity. As they both provide the same general functionality (in the context of Qubes, VFIO allows KVM to provide the same secure device driver passthrough functionality), it is fair to compare them.

Now knowing that Xen core is actually based on Linux, I think it is fair to compare Xen core to a similarly minimal and portable Linux+grsec+KVM. So my understanding is, in a sense, Xen core is equivalent to Linux+KVM without grsec.

> This isn't what I was thinking of (he's written more about it), but he has a mini-rant about it here: http://seclists.org/dailydave/2010/q3/29. I'm sure you could ask him on OFTC. He comes around occasionally, on #grsecurity, as that's his channel.

Thanks for the link. I read over that thread (though not the linked papers), and I don't think his thesis in that post is quite the same as mine. He's talking about inter-app isolation being more important than inter-VM isolation, and more or less suggesting that anything with grsec is more secure than that same thing without grsec. I'm talking about KVM vs Xen. In fact, he doesn't directly or indirectly mention KVM at all in that post.

The part about hypervisor self-protection seems relevant though. So, if I understand correctly, the self-protection features of KVM are implemented by grsec (not the the KVM code itself), but Xen precludes grsec, thus KVM can be utilized in a more secure manner than Xen can, even if the two hypervisors are similarly secure (referring to the codebases that we call "Xen" and "KVM", ignoring the rest of the kernel written by Linux and grsec developers -- neither KVM nor Xen is particularly flawed)? (Think of it like saying Browser X is more secure than Browser Y only because the former uses LibreSSL instead of OpenSSL.)

Alas, this, if I am understanding correctly, does still suggest KVM is more secure than Xen in practice.

> that has nothing to do with the microkernel, unlike traditional monolithic/hybrid kernels. All of those drivers have to be implemented in userspace.

Unless you're also implying that there is a standard API for writing pluggable services/drivers that are compatible with many different microkernels, I don't see how the development workload is much different than for monolithic kernels. We would still have to write a "PCI driver for seL4" rather than a "PCI driver for microkernels". And such a standard might exist, but I was under the impression that although the service/driver doesn't run in ring0, it still must be written for a specific microkernel.

If I were to venture a guess: if it wouldn't require any extremely fundamental design changes, I think we might do better by working on securing Hurd, which already has a Linux driver compatibility layer in userspace (not to mention also Dom0 and DomU support), than we would by painstakingly porting/reimplementing Linux's many thousands of drivers on SafeRTOS or something else. Either that or port Hurd's compatibility layer to SafeRTOS or another more secure microkernel. And this is all before considering userland software support (granted, Hurd is POSIX compliant, and Debian-Hurd already runs about two thirds of the Debian packages, so really only Linux-specific software would need to be ported, though most of it probably wouldn't be needed in Dom0, except maybe systemd, now I'm waaay off topic).

In any case, can you name a microkernel-based operating system that I could reasonably expect to support and run on my average consumer laptop as well as Linux does? I would love to see a stable, secure, privilege-separated, microkernel OS that supports as much hardware and userland software as Linux, but I don't see it actually happening during my lifetime.

I've never tried it, but I assume you could use Xen as you normally would if you know what you're doing. That is, any distro with a Xen kernel (as a PV) or even without (as an HVM), but you won't get in-guest support, e.g. drag-and-drop, clipboard, file transfer, etc might not work.

Is audio supported? I ask because there's no paravirtual audio driver for Xen, although I guess audio could be achieved using an HVM by running the device model in Dom0. Other than that, a high-level audio server like JACK or PulseAudio is the only solution I can think of.