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