Reading (For Dummies)

Xening Out

So I'm working on this computer sanitization project, and I had a weird idea. Xen is a very nifty hypervisor that allows the running of fully virtualized guest OSes if your CPU supports VT extensions. The CPU of your virtual machine will be quite fast. Unfortunately, you still have to use qemu (or some virtualization layer) to present a fake video card (and a lot of other fake hardware) to the guest OS, and then translate the fake video card to a real video card. You can't talk to the real video card directly, because the first guest OS (dom0, generally linux) loads a driver and places a pointer to its driver in the interrupt descriptor table. So the second guest OS is locked out. An interrupt can only be handled by one function.

Theoretically, you can give direct access to the video card to a guest OS if the main OS stops using video or replaces its driver with a stub that doesn't cause interrupts. The trouble is DMA. The guest OS thinks it knows its address in memory that starts at 0x00, but of course it's wrong. If it tells the video card, or whatever hardware, an address for DMAing memory, the hardware will be terribly confused and will end up reading/writing data in the dom0's memory ("snow crash", anyone? :)).

Enter IOMMU, something that AMD cooked up and the Intel has played along with in the form of VT-d. It provides a real memory management unit for hardware. Now DMAs will be translated via the MMU, and mapped into the correct virtual machine's address space. Sweet.

Except it isn't here yet (IOMMU is, but it's incomplete). And it won't be for a while. I actually used to know 'when', but that notebook was burned when I left my old job. Sigh. But, I am thinking of a workaround...

We boot the hypervisor and move it in memory to be someplace very high (say, at the 1 gig mark) and have it boot the dom0 in the same way, just after itself. It changes the interrupt descriptor table to reflect this change, so they point to the new locations high in memory of the dom0 drivers. The dom0 would then either 'lose' the video interrupt (or simply never register it). The hypervisor can then boot a domU at 0x00. This guest OS would be able to succesfully do DMA with some hardware directly. It could create an entry in the IDT for its own video card driver.

Why go to all this trouble though? Because video is important. More than any other component of a computer it uses a lot of bandwidth. Emulating the amount of IO that goes to a video card is teh suck. You get Guest Interrupt -> qemu/virtualization function and translation -> host OS syscall -> hypervisor -> real video card IO. Multiply this by about a million every time you move your mouse, and you see why it's slow. Giving the domU direct access to video is a good thing. But here's the nice part: security. You virtualize a lot of the domU's hardware using something like qemu. For example, create a fake USB bus for the VM, a fake ethernet, a fake disk.

Then you go nuts securing it. If the user puts in a usb thumb drive, you can have the linux dom0 mount it, say, virus scan it and record an md5sum of all the files, log what's there, then unmount it, then finally connect the device to the virtual usb bus. For disk, perhaps you use dm-crypt to provide an encrypted partition. Then you provide some logging capabilities from the guest domU to the dom0, so the domU's logs get stored "off the (virtual) machine" for audit. Linux could provide a nice firewall and IDS for the traffic going through the virtual ethernet. The list goes on and on, you probably get the idea.

This would only work for a single guest OS, obviously. Other domUs could be run, but they'd be locked out of talking to any (dma) hardware directly due to the issue mentioned at the beginning of this stub. Hrmph.

If anybody is interested in working on such a project with me, get in touch :). krwightm shebang foobar at gmail then a dot then com.