Based on kernel version 4.15. Page generated on 2018-01-29 10:00 EST.
1 ===================== 2 Intel(R) TXT Overview 3 ===================== 4 5 Intel's technology for safer computing, Intel(R) Trusted Execution 6 Technology (Intel(R) TXT), defines platform-level enhancements that 7 provide the building blocks for creating trusted platforms. 8 9 Intel TXT was formerly known by the code name LaGrande Technology (LT). 10 11 Intel TXT in Brief: 12 13 - Provides dynamic root of trust for measurement (DRTM) 14 - Data protection in case of improper shutdown 15 - Measurement and verification of launched environment 16 17 Intel TXT is part of the vPro(TM) brand and is also available some 18 non-vPro systems. It is currently available on desktop systems 19 based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell 20 Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45, 21 PM45, and GS45 Express chipsets. 22 23 For more information, see http://www.intel.com/technology/security/. 24 This site also has a link to the Intel TXT MLE Developers Manual, 25 which has been updated for the new released platforms. 26 27 Intel TXT has been presented at various events over the past few 28 years, some of which are: 29 30 - LinuxTAG 2008: 31 http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html 32 33 - TRUST2008: 34 http://www.trust-conference.eu/downloads/Keynote-Speakers/ 35 3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf 36 37 - IDF, Shanghai: 38 http://www.prcidf.com.cn/index_en.html 39 40 - IDFs 2006, 2007 41 (I'm not sure if/where they are online) 42 43 Trusted Boot Project Overview 44 ============================= 45 46 Trusted Boot (tboot) is an open source, pre-kernel/VMM module that 47 uses Intel TXT to perform a measured and verified launch of an OS 48 kernel/VMM. 49 50 It is hosted on SourceForge at http://sourceforge.net/projects/tboot. 51 The mercurial source repo is available at http://www.bughost.org/ 52 repos.hg/tboot.hg. 53 54 Tboot currently supports launching Xen (open source VMM/hypervisor 55 w/ TXT support since v3.2), and now Linux kernels. 56 57 58 Value Proposition for Linux or "Why should you care?" 59 ===================================================== 60 61 While there are many products and technologies that attempt to 62 measure or protect the integrity of a running kernel, they all 63 assume the kernel is "good" to begin with. The Integrity 64 Measurement Architecture (IMA) and Linux Integrity Module interface 65 are examples of such solutions. 66 67 To get trust in the initial kernel without using Intel TXT, a 68 static root of trust must be used. This bases trust in BIOS 69 starting at system reset and requires measurement of all code 70 executed between system reset through the completion of the kernel 71 boot as well as data objects used by that code. In the case of a 72 Linux kernel, this means all of BIOS, any option ROMs, the 73 bootloader and the boot config. In practice, this is a lot of 74 code/data, much of which is subject to change from boot to boot 75 (e.g. changing NICs may change option ROMs). Without reference 76 hashes, these measurement changes are difficult to assess or 77 confirm as benign. This process also does not provide DMA 78 protection, memory configuration/alias checks and locks, crash 79 protection, or policy support. 80 81 By using the hardware-based root of trust that Intel TXT provides, 82 many of these issues can be mitigated. Specifically: many 83 pre-launch components can be removed from the trust chain, DMA 84 protection is provided to all launched components, a large number 85 of platform configuration checks are performed and values locked, 86 protection is provided for any data in the event of an improper 87 shutdown, and there is support for policy-based execution/verification. 88 This provides a more stable measurement and a higher assurance of 89 system configuration and initial state than would be otherwise 90 possible. Since the tboot project is open source, source code for 91 almost all parts of the trust chain is available (excepting SMM and 92 Intel-provided firmware). 93 94 How Does it Work? 95 ================= 96 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. 102 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. 110 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. 117 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. 125 126 - Tboot then applies an (optional) user-defined launch policy to 127 verify the kernel and initrd. 128 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. 136 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. 146 147 - The location of the shared page is passed via the boot_params 148 struct as a physical address. 149 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. 163 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. 187 188 That's pretty much it for TXT support. 189 190 191 Configuring the System 192 ====================== 193 194 This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels. 195 196 In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSes 197 allow these to be individually enabled/disabled and the screens in 198 which to find them are BIOS-specific. 199 200 grub.conf needs to be modified as follows:: 201 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 209 210 The kernel option for enabling Intel TXT support is found under the 211 Security top-level menu and is called "Enable Intel(R) Trusted 212 Execution Technology (TXT)". It is considered EXPERIMENTAL and 213 depends on the generic x86 support (to allow maximum flexibility in 214 kernel build options), since the tboot code will detect whether the 215 platform actually supports Intel TXT and thus whether any of the 216 kernel code is executed. 217 218 The Q35_SINIT_17.BIN file is what Intel TXT refers to as an 219 Authenticated Code Module. It is specific to the chipset in the 220 system 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 222 DRTM process to verify and configure the system. It is signed 223 because it operates at a higher privilege level in the system than 224 any other macrocode and its correct operation is critical to the 225 establishment of the DRTM. The process for determining the correct 226 SINIT ACM for a system is documented in the SINIT-guide.txt file 227 that is on the tboot SourceForge site under the SINIT ACM downloads.