vt-d Virtualisation and Trusted Execution Technology

Question

Being a long time VirtualBox user and having recently purchased a new laptop equipped with an intel i7 720QM I discovered that it supported vt-d.

In the meantime I've found out that vt-d comes with TXT which is a kind of hardware security addition to the i386 architecture. I've got two questions:

• Why is vt-d coupled with TXT ?
• How does TXT enhance security ?

Answer 1

Trusted Execution Technology is coupled with a collection of security features available on the modern Intel chipset. The Trusted Platform Module (TPM) and other DRM like features are also in this bundle. The reasoning behind this is because of abstraction, which is more commonly attributed to a software architecture. The commonality behind all of these features is restricting what access a piece of software has and there for they are going to share complexity and thus they become coupled.

This leads into the next question How does TXT enhance security? A very important feature of TXT is to isolate the memory used by guest vm's. What if a guest vm had a malicious kernel that tried to access memory owned by a host or another guest? TXT is very efficient method of preventing this from happening. Purely software VM's also have this important feature, but there is more overhead. TXT also comes into play for controlling who has access to hardware peripherals like the mouse/keyboard and mass storage devices.

Answer 2

Because it needs isolation to make sure the measurements cannot be manipulated (TOCTOU style of attacks) by anything (e.g. DMA-enabled device).

If you like, you can see this as a firewall for I/O and interrupt - obviously, it's not but you get the picture. VT-d is simply Intel’s term to describe their IOMMU. AMD call it AMD-Vi. The role of this unit is to control Device Memory Access (DMA) and interrupt remapping.

The best way I have to describe it is by using a PCI passthrough example. Here’s my –simplistic – explanation:

If you dedicate a DMA-enabled device to a particular virtual machine, let say your network card, then without proper VT-d protection, this VM would have access to the complete host memory. The VM would be able to break out of the VM container through the view of the network card DMA. Recall that DMA provide a direct and complete memory access (this includes host/vmm memory). If VT-d is correctly implemented, the network card would only have access to the VM memory it is assigned to, nothing else. Yeah, some sort of I/O firewall if this helps.

TXT will only use VT-d to build isolation around what it needs to evaluate: measure code, send those measurements in some TPM protected registers (PCRs) for later use, .e.g., remote attestation, unseal operations.

See this for more info about VT-d.

The second question is very tricky as TXT brings new security capabilities (see below) not security by itself. Security can be created in different way depending how those capabilities are used - it's up to our imagination. PrivateCore vCage is a good example.

• Protected Execution - hardware-based domain separation
• Protected Memory Pages - providing protection against ways memory can be accessed - software, DMA, GPU cards - some caveats with SMM, and AMT
• Sealed Storage - encrypt data based on the environment running or in other words, what has been measured (based on the PCRs values stored in the TPM)
• Protected Input - build a trusted channel between the user and the secured environment - not implemented IFAIK
• Protected Graphics - build a trusted channel between the secured environment and the graphic card - not implemented IFAIK
• Attestation - securely report to other parties what measurements are stored in the TPM (PCRs values), e.g. Remote Attestation aka the quote operation.

See this paper for more info about TXT.

Answer 3

From Joanna Rutkowska's blog: (and I admit I'm skating at the edge of my understanding here...)

When you load a hypervisor using TXT, the SENTER instruction would first apply the VT-d protections around the hypervsior image, then do the measurements, and only then load it, with VT-d protections still in-place.

And her more complete explanation:

... let's make the following assumptions:
1) The OS/VMM properly uses IOMMU to isolate the network card(s)
2) Once the attacker got control over the NIC firmware, the attacker can also modify the persistent storage (EEPROM) where this firmware is kept. This has been confirmed by Loic in a private email exchange.
3) The system implements trusted boot via SRTM, i.e. using just BIOS and TPM, without Intel TXT.

Now, the attacker can modify the firmware in the EEPROM and this will allow the attacker to survive the platform reboot. The card's firmware will start executing early in the boot process, definitely before the OS/VMM gets loaded. Now, the compromised NIC, because it is capable of doing DMA to the host memory, can compromise the image of the VMM in a short time window between the time it got measured and loaded by the (trusted) OS loader, e.g. Trusted GRUB, but still before the time VMM had a chance to setup proper IOMMU/VT-d protections for itself.