2Intel(R) TXT Overview
   5Intel's technology for safer computing, Intel(R) Trusted Execution
   6Technology (Intel(R) TXT), defines platform-level enhancements that
   7provide the building blocks for creating trusted platforms.
   9Intel TXT was formerly known by the code name LaGrande Technology (LT).
  11Intel TXT in Brief:
  13-  Provides dynamic root of trust for measurement (DRTM)
  14-  Data protection in case of improper shutdown
  15-  Measurement and verification of launched environment
  17Intel TXT is part of the vPro(TM) brand and is also available some
  18non-vPro systems.  It is currently available on desktop systems
  19based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
  20Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
  21PM45, and GS45 Express chipsets.
  23For more information, see
  24This site also has a link to the Intel TXT MLE Developers Manual,
  25which has been updated for the new released platforms.
  27Intel TXT has been presented at various events over the past few
  28years, some of which are:
  30      - LinuxTAG 2008:
  33      - TRUST2008:
  35          3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
  37      - IDF, Shanghai:
  40      - IDFs 2006, 2007
  41          (I'm not sure if/where they are online)
  43Trusted Boot Project Overview
  46Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
  47uses Intel TXT to perform a measured and verified launch of an OS
  50It is hosted on SourceForge at
  51The mercurial source repo is available at
  54Tboot currently supports launching Xen (open source VMM/hypervisor
  55w/ TXT support since v3.2), and now Linux kernels.
  58Value Proposition for Linux or "Why should you care?"
  61While there are many products and technologies that attempt to
  62measure or protect the integrity of a running kernel, they all
  63assume the kernel is "good" to begin with.  The Integrity
  64Measurement Architecture (IMA) and Linux Integrity Module interface
  65are examples of such solutions.
  67To get trust in the initial kernel without using Intel TXT, a
  68static root of trust must be used.  This bases trust in BIOS
  69starting at system reset and requires measurement of all code
  70executed between system reset through the completion of the kernel
  71boot as well as data objects used by that code.  In the case of a
  72Linux kernel, this means all of BIOS, any option ROMs, the
  73bootloader and the boot config.  In practice, this is a lot of
  74code/data, much of which is subject to change from boot to boot
  75(e.g. changing NICs may change option ROMs).  Without reference
  76hashes, these measurement changes are difficult to assess or
  77confirm as benign.  This process also does not provide DMA
  78protection, memory configuration/alias checks and locks, crash
  79protection, or policy support.
  81By using the hardware-based root of trust that Intel TXT provides,
  82many of these issues can be mitigated.  Specifically: many
  83pre-launch components can be removed from the trust chain, DMA
  84protection is provided to all launched components, a large number
  85of platform configuration checks are performed and values locked,
  86protection is provided for any data in the event of an improper
  87shutdown, and there is support for policy-based execution/verification.
  88This provides a more stable measurement and a higher assurance of
  89system configuration and initial state than would be otherwise
  90possible.  Since the tboot project is open source, source code for
  91almost all parts of the trust chain is available (excepting SMM and
  92Intel-provided firmware).
  94How Does it Work?
  97-  Tboot is an executable that is launched by the bootloader as
  98   the "kernel" (the binary the bootloader executes).
  99-  It performs all of the work necessary to determine if the
 100   platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
 101   processor instruction that initiates the dynamic root of trust.
 103   -  If tboot determines that the system does not support Intel TXT
 104      or is not configured correctly (e.g. the SINIT AC Module was
 105      incorrect), it will directly launch the kernel with no changes
 106      to any state.
 107   -  Tboot will output various information about its progress to the
 108      terminal, serial port, and/or an in-memory log; the output
 109      locations can be configured with a command line switch.
 111-  The GETSEC[SENTER] instruction will return control to tboot and
 112   tboot then verifies certain aspects of the environment (e.g. TPM NV
 113   lock, e820 table does not have invalid entries, etc.).
 114-  It will wake the APs from the special sleep state the GETSEC[SENTER]
 115   instruction had put them in and place them into a wait-for-SIPI
 116   state.
 118   -  Because the processors will not respond to an INIT or SIPI when
 119      in the TXT environment, it is necessary to create a small VT-x
 120      guest for the APs.  When they run in this guest, they will
 121      simply wait for the INIT-SIPI-SIPI sequence, which will cause
 122      VMEXITs, and then disable VT and jump to the SIPI vector.  This
 123      approach seemed like a better choice than having to insert
 124      special code into the kernel's MP wakeup sequence.
 126-  Tboot then applies an (optional) user-defined launch policy to
 127   verify the kernel and initrd.
 129   -  This policy is rooted in TPM NV and is described in the tboot
 130      project.  The tboot project also contains code for tools to
 131      create and provision the policy.
 132   -  Policies are completely under user control and if not present
 133      then any kernel will be launched.
 134   -  Policy action is flexible and can include halting on failures
 135      or simply logging them and continuing.
 137-  Tboot adjusts the e820 table provided by the bootloader to reserve
 138   its own location in memory as well as to reserve certain other
 139   TXT-related regions.
 140-  As part of its launch, tboot DMA protects all of RAM (using the
 141   VT-d PMRs).  Thus, the kernel must be booted with 'intel_iommu=on'
 142   in order to remove this blanket protection and use VT-d's
 143   page-level protection.
 144-  Tboot will populate a shared page with some data about itself and
 145   pass this to the Linux kernel as it transfers control.
 147   -  The location of the shared page is passed via the boot_params
 148      struct as a physical address.
 150-  The kernel will look for the tboot shared page address and, if it
 151   exists, map it.
 152-  As one of the checks/protections provided by TXT, it makes a copy
 153   of the VT-d DMARs in a DMA-protected region of memory and verifies
 154   them for correctness.  The VT-d code will detect if the kernel was
 155   launched with tboot and use this copy instead of the one in the
 156   ACPI table.
 157-  At this point, tboot and TXT are out of the picture until a
 158   shutdown (S<n>)
 159-  In order to put a system into any of the sleep states after a TXT
 160   launch, TXT must first be exited.  This is to prevent attacks that
 161   attempt to crash the system to gain control on reboot and steal
 162   data left in memory.
 164   -  The kernel will perform all of its sleep preparation and
 165      populate the shared page with the ACPI data needed to put the
 166      platform in the desired sleep state.
 167   -  Then the kernel jumps into tboot via the vector specified in the
 168      shared page.
 169   -  Tboot will clean up the environment and disable TXT, then use the
 170      kernel-provided ACPI information to actually place the platform
 171      into the desired sleep state.
 172   -  In the case of S3, tboot will also register itself as the resume
 173      vector.  This is necessary because it must re-establish the
 174      measured environment upon resume.  Once the TXT environment
 175      has been restored, it will restore the TPM PCRs and then
 176      transfer control back to the kernel's S3 resume vector.
 177      In order to preserve system integrity across S3, the kernel
 178      provides tboot with a set of memory ranges (RAM and RESERVED_KERN
 179      in the e820 table, but not any memory that BIOS might alter over
 180      the S3 transition) that tboot will calculate a MAC (message
 181      authentication code) over and then seal with the TPM. On resume
 182      and once the measured environment has been re-established, tboot
 183      will re-calculate the MAC and verify it against the sealed value.
 184      Tboot's policy determines what happens if the verification fails.
 185      Note that the c/s 194 of tboot which has the new MAC code supports
 186      this.
 188That's pretty much it for TXT support.
 191Configuring the System
 194This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
 196In BIOS, the user must enable:  TPM, TXT, VT-x, VT-d.  Not all BIOSes
 197allow these to be individually enabled/disabled and the screens in
 198which to find them are BIOS-specific.
 200grub.conf needs to be modified as follows::
 202        title Linux 2.6.29-tip w/ tboot
 203          root (hd0,0)
 204                kernel /tboot.gz logging=serial,vga,memory
 205                module /vmlinuz-2.6.29-tip intel_iommu=on ro
 206                       root=LABEL=/ rhgb console=ttyS0,115200 3
 207                module /initrd-2.6.29-tip.img
 208                module /Q35_SINIT_17.BIN
 210The kernel option for enabling Intel TXT support is found under the
 211Security top-level menu and is called "Enable Intel(R) Trusted
 212Execution Technology (TXT)".  It is considered EXPERIMENTAL and
 213depends on the generic x86 support (to allow maximum flexibility in
 214kernel build options), since the tboot code will detect whether the
 215platform actually supports Intel TXT and thus whether any of the
 216kernel code is executed.
 218The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
 219Authenticated Code Module.  It is specific to the chipset in the
 220system and can also be found on the Trusted Boot site.  It is an
 221(unencrypted) module signed by Intel that is used as part of the
 222DRTM process to verify and configure the system.  It is signed
 223because it operates at a higher privilege level in the system than
 224any other macrocode and its correct operation is critical to the
 225establishment of the DRTM.  The process for determining the correct
 226SINIT ACM for a system is documented in the SINIT-guide.txt file
 227that is on the tboot SourceForge site under the SINIT ACM downloads.