Back to home page




0001 Intel(R) TXT Overview:
0002 =====================
0004 Intel's technology for safer computing, Intel(R) Trusted Execution
0005 Technology (Intel(R) TXT), defines platform-level enhancements that
0006 provide the building blocks for creating trusted platforms.
0008 Intel TXT was formerly known by the code name LaGrande Technology (LT).
0010 Intel TXT in Brief:
0011 o  Provides dynamic root of trust for measurement (DRTM)
0012 o  Data protection in case of improper shutdown
0013 o  Measurement and verification of launched environment
0015 Intel TXT is part of the vPro(TM) brand and is also available some
0016 non-vPro systems.  It is currently available on desktop systems
0017 based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
0018 Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
0019 PM45, and GS45 Express chipsets.
0021 For more information, see
0022 This site also has a link to the Intel TXT MLE Developers Manual,
0023 which has been updated for the new released platforms.
0025 Intel TXT has been presented at various events over the past few
0026 years, some of which are:
0027       LinuxTAG 2008:
0029       TRUST2008:
0031           3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
0032       IDF, Shanghai:
0034       IDFs 2006, 2007 (I'm not sure if/where they are online)
0036 Trusted Boot Project Overview:
0037 =============================
0039 Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
0040 uses Intel TXT to perform a measured and verified launch of an OS
0041 kernel/VMM.
0043 It is hosted on SourceForge at
0044 The mercurial source repo is available at
0045 repos.hg/tboot.hg.
0047 Tboot currently supports launching Xen (open source VMM/hypervisor
0048 w/ TXT support since v3.2), and now Linux kernels.
0051 Value Proposition for Linux or "Why should you care?"
0052 =====================================================
0054 While there are many products and technologies that attempt to
0055 measure or protect the integrity of a running kernel, they all
0056 assume the kernel is "good" to begin with.  The Integrity
0057 Measurement Architecture (IMA) and Linux Integrity Module interface
0058 are examples of such solutions.
0060 To get trust in the initial kernel without using Intel TXT, a
0061 static root of trust must be used.  This bases trust in BIOS
0062 starting at system reset and requires measurement of all code
0063 executed between system reset through the completion of the kernel
0064 boot as well as data objects used by that code.  In the case of a
0065 Linux kernel, this means all of BIOS, any option ROMs, the
0066 bootloader and the boot config.  In practice, this is a lot of
0067 code/data, much of which is subject to change from boot to boot
0068 (e.g. changing NICs may change option ROMs).  Without reference
0069 hashes, these measurement changes are difficult to assess or
0070 confirm as benign.  This process also does not provide DMA
0071 protection, memory configuration/alias checks and locks, crash
0072 protection, or policy support.
0074 By using the hardware-based root of trust that Intel TXT provides,
0075 many of these issues can be mitigated.  Specifically: many
0076 pre-launch components can be removed from the trust chain, DMA
0077 protection is provided to all launched components, a large number
0078 of platform configuration checks are performed and values locked,
0079 protection is provided for any data in the event of an improper
0080 shutdown, and there is support for policy-based execution/verification.
0081 This provides a more stable measurement and a higher assurance of
0082 system configuration and initial state than would be otherwise
0083 possible.  Since the tboot project is open source, source code for
0084 almost all parts of the trust chain is available (excepting SMM and
0085 Intel-provided firmware).
0087 How Does it Work?
0088 =================
0090 o  Tboot is an executable that is launched by the bootloader as
0091    the "kernel" (the binary the bootloader executes).
0092 o  It performs all of the work necessary to determine if the
0093    platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
0094    processor instruction that initiates the dynamic root of trust.
0095    -  If tboot determines that the system does not support Intel TXT
0096       or is not configured correctly (e.g. the SINIT AC Module was
0097       incorrect), it will directly launch the kernel with no changes
0098       to any state.
0099    -  Tboot will output various information about its progress to the
0100       terminal, serial port, and/or an in-memory log; the output
0101       locations can be configured with a command line switch.
0102 o  The GETSEC[SENTER] instruction will return control to tboot and
0103    tboot then verifies certain aspects of the environment (e.g. TPM NV
0104    lock, e820 table does not have invalid entries, etc.).
0105 o  It will wake the APs from the special sleep state the GETSEC[SENTER]
0106    instruction had put them in and place them into a wait-for-SIPI
0107    state.
0108    -  Because the processors will not respond to an INIT or SIPI when
0109       in the TXT environment, it is necessary to create a small VT-x
0110       guest for the APs.  When they run in this guest, they will
0111       simply wait for the INIT-SIPI-SIPI sequence, which will cause
0112       VMEXITs, and then disable VT and jump to the SIPI vector.  This
0113       approach seemed like a better choice than having to insert
0114       special code into the kernel's MP wakeup sequence.
0115 o  Tboot then applies an (optional) user-defined launch policy to
0116    verify the kernel and initrd.
0117    -  This policy is rooted in TPM NV and is described in the tboot
0118       project.  The tboot project also contains code for tools to
0119       create and provision the policy.
0120    -  Policies are completely under user control and if not present
0121       then any kernel will be launched.
0122    -  Policy action is flexible and can include halting on failures
0123       or simply logging them and continuing.
0124 o  Tboot adjusts the e820 table provided by the bootloader to reserve
0125    its own location in memory as well as to reserve certain other
0126    TXT-related regions.
0127 o  As part of its launch, tboot DMA protects all of RAM (using the
0128    VT-d PMRs).  Thus, the kernel must be booted with 'intel_iommu=on'
0129    in order to remove this blanket protection and use VT-d's
0130    page-level protection.
0131 o  Tboot will populate a shared page with some data about itself and
0132    pass this to the Linux kernel as it transfers control.
0133    -  The location of the shared page is passed via the boot_params
0134       struct as a physical address.
0135 o  The kernel will look for the tboot shared page address and, if it
0136    exists, map it.
0137 o  As one of the checks/protections provided by TXT, it makes a copy
0138    of the VT-d DMARs in a DMA-protected region of memory and verifies
0139    them for correctness.  The VT-d code will detect if the kernel was
0140    launched with tboot and use this copy instead of the one in the
0141    ACPI table.
0142 o  At this point, tboot and TXT are out of the picture until a
0143    shutdown (S<n>)
0144 o  In order to put a system into any of the sleep states after a TXT
0145    launch, TXT must first be exited.  This is to prevent attacks that
0146    attempt to crash the system to gain control on reboot and steal
0147    data left in memory.
0148    -  The kernel will perform all of its sleep preparation and
0149       populate the shared page with the ACPI data needed to put the
0150       platform in the desired sleep state.
0151    -  Then the kernel jumps into tboot via the vector specified in the
0152       shared page.
0153    -  Tboot will clean up the environment and disable TXT, then use the
0154       kernel-provided ACPI information to actually place the platform
0155       into the desired sleep state.
0156    -  In the case of S3, tboot will also register itself as the resume
0157       vector.  This is necessary because it must re-establish the
0158       measured environment upon resume.  Once the TXT environment
0159       has been restored, it will restore the TPM PCRs and then
0160       transfer control back to the kernel's S3 resume vector.
0161       In order to preserve system integrity across S3, the kernel
0162       provides tboot with a set of memory ranges (RAM and RESERVED_KERN
0163       in the e820 table, but not any memory that BIOS might alter over
0164       the S3 transition) that tboot will calculate a MAC (message
0165       authentication code) over and then seal with the TPM. On resume
0166       and once the measured environment has been re-established, tboot
0167       will re-calculate the MAC and verify it against the sealed value.
0168       Tboot's policy determines what happens if the verification fails.
0169       Note that the c/s 194 of tboot which has the new MAC code supports
0170       this.
0172 That's pretty much it for TXT support.
0175 Configuring the System:
0176 ======================
0178 This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
0180 In BIOS, the user must enable:  TPM, TXT, VT-x, VT-d.  Not all BIOSes
0181 allow these to be individually enabled/disabled and the screens in
0182 which to find them are BIOS-specific.
0184 grub.conf needs to be modified as follows:
0185         title Linux 2.6.29-tip w/ tboot
0186           root (hd0,0)
0187                 kernel /tboot.gz logging=serial,vga,memory
0188                 module /vmlinuz-2.6.29-tip intel_iommu=on ro
0189                        root=LABEL=/ rhgb console=ttyS0,115200 3
0190                 module /initrd-2.6.29-tip.img
0191                 module /Q35_SINIT_17.BIN
0193 The kernel option for enabling Intel TXT support is found under the
0194 Security top-level menu and is called "Enable Intel(R) Trusted
0195 Execution Technology (TXT)".  It is considered EXPERIMENTAL and
0196 depends on the generic x86 support (to allow maximum flexibility in
0197 kernel build options), since the tboot code will detect whether the
0198 platform actually supports Intel TXT and thus whether any of the
0199 kernel code is executed.
0201 The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
0202 Authenticated Code Module.  It is specific to the chipset in the
0203 system and can also be found on the Trusted Boot site.  It is an
0204 (unencrypted) module signed by Intel that is used as part of the
0205 DRTM process to verify and configure the system.  It is signed
0206 because it operates at a higher privilege level in the system than
0207 any other macrocode and its correct operation is critical to the
0208 establishment of the DRTM.  The process for determining the correct
0209 SINIT ACM for a system is documented in the SINIT-guide.txt file
0210 that is on the tboot SourceForge site under the SINIT ACM downloads.