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