13.1. Trusted Boot Project Overview¶

Trusted Boot (tboot) is an open source, pre-kernel/VMM module thatuses Intel TXT to perform a measured and verified launch of an OSkernel/VMM.

It is hosted on SourceForge athttp://sourceforge.net/projects/tboot.The mercurial source repo is available athttp://www.bughost.org/repos.hg/tboot.hg.

Tboot currently supports launching Xen (open source VMM/hypervisorw/ TXT support since v3.2), and now Linux kernels.

13.2. Value Proposition for Linux or “Why should you care?”¶

While there are many products and technologies that attempt tomeasure or protect the integrity of a running kernel, they allassume the kernel is “good” to begin with. The IntegrityMeasurement Architecture (IMA) and Linux Integrity Module interfaceare examples of such solutions.

To get trust in the initial kernel without using Intel TXT, astatic root of trust must be used. This bases trust in BIOSstarting at system reset and requires measurement of all codeexecuted between system reset through the completion of the kernelboot as well as data objects used by that code. In the case of aLinux kernel, this means all of BIOS, any option ROMs, thebootloader and the boot config. In practice, this is a lot ofcode/data, much of which is subject to change from boot to boot(e.g. changing NICs may change option ROMs). Without referencehashes, these measurement changes are difficult to assess orconfirm as benign. This process also does not provide DMAprotection, memory configuration/alias checks and locks, crashprotection, or policy support.

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

13.3. How Does it Work?¶

• Tboot is an executable that is launched by the bootloader asthe “kernel” (the binary the bootloader executes).
• It performs all of the work necessary to determine if theplatform supports Intel TXT and, if so, executes the GETSEC[SENTER]processor instruction that initiates the dynamic root of trust.
  • If tboot determines that the system does not support Intel TXTor is not configured correctly (e.g. the SINIT AC Module wasincorrect), it will directly launch the kernel with no changesto any state.
  • Tboot will output various information about its progress to theterminal, serial port, and/or an in-memory log; the outputlocations can be configured with a command line switch.
• The GETSEC[SENTER] instruction will return control to tboot andtboot then verifies certain aspects of the environment (e.g. TPM NVlock, e820 table does not have invalid entries, etc.).
• It will wake the APs from the special sleep state the GETSEC[SENTER]instruction had put them in and place them into a wait-for-SIPIstate.
  • Because the processors will not respond to an INIT or SIPI whenin the TXT environment, it is necessary to create a small VT-xguest for the APs. When they run in this guest, they willsimply wait for the INIT-SIPI-SIPI sequence, which will causeVMEXITs, and then disable VT and jump to the SIPI vector. Thisapproach seemed like a better choice than having to insertspecial code into the kernel’s MP wakeup sequence.
• Tboot then applies an (optional) user-defined launch policy toverify the kernel and initrd.
  • This policy is rooted in TPM NV and is described in the tbootproject. The tboot project also contains code for tools tocreate and provision the policy.
  • Policies are completely under user control and if not presentthen any kernel will be launched.
  • Policy action is flexible and can include halting on failuresor simply logging them and continuing.
• Tboot adjusts the e820 table provided by the bootloader to reserveits own location in memory as well as to reserve certain otherTXT-related regions.
• As part of its launch, tboot DMA protects all of RAM (using theVT-d PMRs). Thus, the kernel must be booted with ‘intel_iommu=on’in order to remove this blanket protection and use VT-d’spage-level protection.
• Tboot will populate a shared page with some data about itself andpass this to the Linux kernel as it transfers control.
  • The location of the shared page is passed via the boot_paramsstruct as a physical address.
• The kernel will look for the tboot shared page address and, if itexists, map it.
• As one of the checks/protections provided by TXT, it makes a copyof the VT-d DMARs in a DMA-protected region of memory and verifiesthem for correctness. The VT-d code will detect if the kernel waslaunched with tboot and use this copy instead of the one in theACPI table.
• At this point, tboot and TXT are out of the picture until ashutdown (S<n>)
• In order to put a system into any of the sleep states after a TXTlaunch, TXT must first be exited. This is to prevent attacks thatattempt to crash the system to gain control on reboot and stealdata left in memory.
  • The kernel will perform all of its sleep preparation andpopulate the shared page with the ACPI data needed to put theplatform in the desired sleep state.
  • Then the kernel jumps into tboot via the vector specified in theshared page.
  • Tboot will clean up the environment and disable TXT, then use thekernel-provided ACPI information to actually place the platforminto the desired sleep state.
  • In the case of S3, tboot will also register itself as the resumevector. This is necessary because it must re-establish themeasured environment upon resume. Once the TXT environmenthas been restored, it will restore the TPM PCRs and thentransfer control back to the kernel’s S3 resume vector.In order to preserve system integrity across S3, the kernelprovides tboot with a set of memory ranges (RAM and RESERVED_KERNin the e820 table, but not any memory that BIOS might alter overthe S3 transition) that tboot will calculate a MAC (messageauthentication code) over and then seal with the TPM. On resumeand once the measured environment has been re-established, tbootwill re-calculate the MAC and verify it against the sealed value.Tboot’s policy determines what happens if the verification fails.Note that the c/s 194 of tboot which has the new MAC code supportsthis.

That’s pretty much it for TXT support.

13.4. Configuring the System¶

This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.

In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSesallow these to be individually enabled/disabled and the screens inwhich to find them are BIOS-specific.

grub.conf needs to be modified as follows:

title Linux 2.6.29-tip w/ tboot  root (hd0,0)        kernel /tboot.gz logging=serial,vga,memory        module /vmlinuz-2.6.29-tip intel_iommu=on ro               root=LABEL=/ rhgb console=ttyS0,115200 3        module /initrd-2.6.29-tip.img        module /Q35_SINIT_17.BIN

The kernel option for enabling Intel TXT support is found under theSecurity top-level menu and is called “Enable Intel(R) TrustedExecution Technology (TXT)”. It is considered EXPERIMENTAL anddepends on the generic x86 support (to allow maximum flexibility inkernel build options), since the tboot code will detect whether theplatform actually supports Intel TXT and thus whether any of thekernel code is executed.

The Q35_SINIT_17.BIN file is what Intel TXT refers to as anAuthenticated Code Module. It is specific to the chipset in thesystem and can also be found on the Trusted Boot site. It is an(unencrypted) module signed by Intel that is used as part of theDRTM process to verify and configure the system. It is signedbecause it operates at a higher privilege level in the system thanany other macrocode and its correct operation is critical to theestablishment of the DRTM. The process for determining the correctSINIT ACM for a system is documented in the SINIT-guide.txt filethat is on the tboot SourceForge site under the SINIT ACM downloads.