Integrity management using Intel TXT [LWN.net] (original) (raw)

Being able to verify that the code running on a system is the "correct" code is an important feature for some environments. The Linux integrity management architecture (IMA) patches—recently merged for 2.6.30—look at the integrity of processes as they are started by the kernel. But that requires running on a "good" kernel. So a patch, recently put out for comments on linux-kernel, proposes a lower-level mechanism which uses Intel's Trusted Execution Technology (TXT) to verify the integrity of the kernel itself.

Whereas the IMA lives completely within the Linux kernel, but uses Trusted Platform Module (TPM) hardware to check and enforce the integrity of code that is executed, the TXT-based integrity system interposes a virtual machine monitor (VMM or hypervisor) between the hardware and the kernel. This hypervisor, called Trusted Boot or tbootinteracts with the TXT hardware, which is contained in various recent Intel chipsets, to verify the integrity of the kernel before launching it.

The TXT hardware can itself verify the integrity of many of the firmware components (things like BIOS and option ROMs) that must be assumed when using IMA. In their introductory post, Joseph Cihula and Shane Wang of Intel describe the advantages of a TXT-based integrity system as follows:

To get trust in the initial kernel without using Intel TXT, a static root of trust must be used. This bases trust in BIOS starting at system reset and requires measurement of all code executed between system reset through the completion of the kernel boot as well as data objects used by that code. In the case of a Linux kernel, this means all of BIOS, any option ROMs, the bootloader and the boot config. In practice, this is a lot of code/data, much of which is subject to change from boot to boot (e.g. changing NICs may change option ROMs). Without reference hashes, these measurement changes are difficult to assess or confirm as benign. This process also does not provide DMA protection, memory configuration/alias checks and locks, crash protection, or policy support.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

By using the hardware-based root of trust that Intel TXT provides, many of these issues can be mitigated. Specifically: many pre-launch components can be removed from the trust chain, DMA protection is provided to all launched components, a large number of platform configuration checks are performed and values locked, protection is provided for any data in the event of an improper shutdown, and there is support for policy-based execution/verification. This provides a more stable measurement and a higher assurance of system configuration and initial state than would be otherwise possible. Since the tboot project is open source, source code for almost all parts of the trust chain is available (excepting SMM and Intel-provided firmware).

It is interesting that they mention system management mode (SMM) as that has recently been the target of some research on undetectable rootkits. The kind of malware described in the research could subvert even TXT-based integrity systems.

In a followup post, Cihula and Wang describe in some detail how TXT, tboot, and the kernel cooperate to make it all work. Tboot is loaded by the bootloader—typically grub—as the "kernel". The grub.conf file lists the Linux kernel and Intel-supplied binary-only "authenticated code module" as "modules" that get loaded as well. For those who wish it, tboot also supports launching the Xen hypervisor, instead of the Linux kernel, as the guest. Tboot then does all of the setup necessary to determine if the TXT environment is present and configured correctly, if not, it just launches the kernel as usual. But if it finds a proper TXT environment, it initiates the integrity checking and verifies the hardware environment.

At that point, user-defined policies are consulted to determine the how to verify the integrity of the kernel and initial ramdisk (initrd) and what to do if verification fails. Tboot creates a shared page of memory and populates it with some data about itself for the kernel to use. The physical address of the shared page is passed to the kernel as a boot parameter. The kernel then maps that page as part of the boot process.

The shared page is also used by the kernel to communicate its intent to move to one of the sleep states of the processor. Instead of directly sleeping, it informs tboot of all of the relevant ACPI data via the shared page and jumps into tboot via a vector listed in the page. When going into the standby (suspend to RAM or S3) sleep, additional steps are taken to ensure the memory integrity across the S3 boundary. This is done by calculating a hash value over critical memory regions (kernel code and data as well as the S3 resume code) and signing it using the TPM. The user-supplied tboot policies determine what actions to take if the RAM verification fails upon coming out of S3.

The patch itself is relatively small and comments on it nearly non-existent. While it provides a potentially interesting protection against various attack scenarios, it also adds a layer underneath the kernel. In addition, there are some binary components to tboot that may raise some eyebrows. It will be interesting to see what kind of reception it gets, once folks start looking at it.