Tor at the Heart: Qubes OS

Thanks for the reply once again; very interesting stuff!

> 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.

It has templates for a number of different guest distros. See https://www.qubes-os.org/doc/ "Managing Operating Systems within Qubes"

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.