If you’ve been watching the xen-user, xen-devel or the xen channel on freenode you’ve probably seen me asking questions about setting up a driver domain. You also may have noticed that the Xen wiki page dedicated to the topic [1] is a bit light on details. I’ve even had a few people contact me directly through email and my blog to see if I have this working yet which I think is great. I’m glad to know there are other people interested in this besides me.
This post is the first in a series in which I’ll explains how I went about configuring Xen to bind a network device to an unprivileged domain (typically called domU) and how I configured this domU (Linux) to act as a network back end for other Linux domUs. This first post will frame the problem and tell you why you should care. My next post will dig into the details of what needs to be done to set up a network driver domain.
Why
First off why is this important? Every Xen configuration I’ve seen had all devices hosted in the administrative domain (dom0) and everything worked fine. What do we gain by removing the device from dom0 and having it hosted in a domU.
The answer to these questions is all about security. If all you care about is functionality then don’t bother configuring a driver domain. You get no new “features” and no performance improvement (that I know of). What you do get is a dom0, the most security critical domain, with a reduced attack surface.
Let’s consider an attack scenario to make this concrete: Say an exploit exists in whichever Linux network driver you use. This exploit allows a remote attacker to send a specially crafted packet to your NIC and execute arbitrary code in your kernel. This is a worst case scenario, probably not something that will happen but it is possible. If dom0 is hosting this and all other devices and their drivers your system is hosed. The attacker can manipulate all of your domUs, the data in your domUs, everything.
Now suppose you’ve bound your NIC to a domU and configure this domU to act as a network back end for other domUs. Using the same (slightly far-fetched) vulnerability as an example, have we reduced the impact of the exploit?
The driver domain makes a significant difference here. Instead of having malicious code executing in dom0, it’s in an unprivileged domain. This isn’t to say that the exploit has no effect on the system. What we have achieved though is reducing the effects of the exploit. Instead of a full system compromise we’re now faced with a single unprivileged domain compromise and a denial of service on the networking offered to the other VMs.
The attacker can take down the networking for all of your VMs but they can’t get at their disks, they can’t shut them down, and they can’t create new VMs. Sure the attacker could sit in the driver domain and snoop on you domUs traffic but this sort of snooping is possible remotely. The appropriate use of encryption solves the disclosure problem. In the worst case scenario attacker could use this exploit as a first step in a more complex attack on the other VMs by manipulating the network driver front ends and possibly triggering another exploit.
In short a driver domain can reduce the attack surface of your Xen system. It’s not a cure-all but it’s good for your overall system security. I’m pretty burned out so I’ll wrap up with the matching “How” part of this post in the next day or two. Stay tuned.
technomasochism 
Great! It’s a good scheme to make the dom0 more secure. Have you ever think about another scheme, which move all the drivers of dom0 to a unprivileged domain? This may be not more secure than the one-driver-driverdomain (described in your article). But, besides security, I think this scheme also have some other advantages, such as 1)reducing the size of dom0 dramatically and 2)providing all kinds of driver to other domain, which doesn’t have any device drivers except for some simple front drivers.
LikeLike
Sorry for the late response gavin, hopefully you’ll get an email notification. Regardless, dedicating a driver domain to each driver is likely unrealistic. This would require a PV driver back/front end for each device and, as far as I know, things like sound are still emulated by QEMU for Xen.
That said there’s nothing preventing someone from using a driver domain to host something like the hard disk drivers which is pretty much the only other realistic example I can come up with. Like the network driver domain a hard disk driver domain could be made “security non-critical” by using full disk encryption in the client VMs. Having both the network and hard disk drivers (the ones that manage data for all VMs) touching only encrypted data would be a huge step forward for security.
This scheme only compounds management problems and makes things like dom0 configuration/boot that much more difficult. If you’re interested take a look at the qubes os project. Their design documentation was very good when I took a look at it last summer.
LikeLike