Root/
Source at commit b05a5adf03613de371c77c3235f7d970d7cd0c71 created 13 years 1 month ago. By Lars-Peter Clausen, NAND: Optimize reading the eec data for the JZ4740 (evil hack) | |
---|---|
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.html |
29 | TRUST2008: |
30 | http://www.trust-conference.eu/downloads/Keynote-Speakers/ |
31 | 3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf |
32 | IDF, Shanghai: |
33 | http://www.prcidf.com.cn/index_en.html |
34 | IDFs 2006, 2007 (I'm not sure if/where they are online) |
35 | |
36 | Trusted Boot Project Overview: |
37 | ============================= |
38 | |
39 | Trusted Boot (tboot) is an open source, pre-kernel/VMM module that |
40 | uses Intel TXT to perform a measured and verified launch of an OS |
41 | kernel/VMM. |
42 | |
43 | It is hosted on SourceForge at http://sourceforge.net/projects/tboot. |
44 | The mercurial source repo is available at http://www.bughost.org/ |
45 | repos.hg/tboot.hg. |
46 | |
47 | Tboot currently supports launching Xen (open source VMM/hypervisor |
48 | w/ TXT support since v3.2), and now Linux kernels. |
49 | |
50 | |
51 | Value Proposition for Linux or "Why should you care?" |
52 | ===================================================== |
53 | |
54 | While there are many products and technologies that attempt to |
55 | measure or protect the integrity of a running kernel, they all |
56 | assume the kernel is "good" to begin with. The Integrity |
57 | Measurement Architecture (IMA) and Linux Integrity Module interface |
58 | are examples of such solutions. |
59 | |
60 | To get trust in the initial kernel without using Intel TXT, a |
61 | static root of trust must be used. This bases trust in BIOS |
62 | starting at system reset and requires measurement of all code |
63 | executed between system reset through the completion of the kernel |
64 | boot as well as data objects used by that code. In the case of a |
65 | Linux kernel, this means all of BIOS, any option ROMs, the |
66 | bootloader and the boot config. In practice, this is a lot of |
67 | code/data, much of which is subject to change from boot to boot |
68 | (e.g. changing NICs may change option ROMs). Without reference |
69 | hashes, these measurement changes are difficult to assess or |
70 | confirm as benign. This process also does not provide DMA |
71 | protection, memory configuration/alias checks and locks, crash |
72 | protection, or policy support. |
73 | |
74 | By using the hardware-based root of trust that Intel TXT provides, |
75 | many of these issues can be mitigated. Specifically: many |
76 | pre-launch components can be removed from the trust chain, DMA |
77 | protection is provided to all launched components, a large number |
78 | of platform configuration checks are performed and values locked, |
79 | protection is provided for any data in the event of an improper |
80 | shutdown, and there is support for policy-based execution/verification. |
81 | This provides a more stable measurement and a higher assurance of |
82 | system configuration and initial state than would be otherwise |
83 | possible. Since the tboot project is open source, source code for |
84 | almost all parts of the trust chain is available (excepting SMM and |
85 | Intel-provided firmware). |
86 | |
87 | How Does it Work? |
88 | ================= |
89 | |
90 | o Tboot is an executable that is launched by the bootloader as |
91 | the "kernel" (the binary the bootloader executes). |
92 | o It performs all of the work necessary to determine if the |
93 | platform supports Intel TXT and, if so, executes the GETSEC[SENTER] |
94 | processor instruction that initiates the dynamic root of trust. |
95 | - If tboot determines that the system does not support Intel TXT |
96 | or is not configured correctly (e.g. the SINIT AC Module was |
97 | incorrect), it will directly launch the kernel with no changes |
98 | to any state. |
99 | - Tboot will output various information about its progress to the |
100 | terminal, serial port, and/or an in-memory log; the output |
101 | locations can be configured with a command line switch. |
102 | o The GETSEC[SENTER] instruction will return control to tboot and |
103 | tboot then verifies certain aspects of the environment (e.g. TPM NV |
104 | lock, e820 table does not have invalid entries, etc.). |
105 | o It will wake the APs from the special sleep state the GETSEC[SENTER] |
106 | instruction had put them in and place them into a wait-for-SIPI |
107 | state. |
108 | - Because the processors will not respond to an INIT or SIPI when |
109 | in the TXT environment, it is necessary to create a small VT-x |
110 | guest for the APs. When they run in this guest, they will |
111 | simply wait for the INIT-SIPI-SIPI sequence, which will cause |
112 | VMEXITs, and then disable VT and jump to the SIPI vector. This |
113 | approach seemed like a better choice than having to insert |
114 | special code into the kernel's MP wakeup sequence. |
115 | o Tboot then applies an (optional) user-defined launch policy to |
116 | verify the kernel and initrd. |
117 | - This policy is rooted in TPM NV and is described in the tboot |
118 | project. The tboot project also contains code for tools to |
119 | create and provision the policy. |
120 | - Policies are completely under user control and if not present |
121 | then any kernel will be launched. |
122 | - Policy action is flexible and can include halting on failures |
123 | or simply logging them and continuing. |
124 | o Tboot adjusts the e820 table provided by the bootloader to reserve |
125 | its own location in memory as well as to reserve certain other |
126 | TXT-related regions. |
127 | o As part of its launch, tboot DMA protects all of RAM (using the |
128 | VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on' |
129 | in order to remove this blanket protection and use VT-d's |
130 | page-level protection. |
131 | o Tboot will populate a shared page with some data about itself and |
132 | pass this to the Linux kernel as it transfers control. |
133 | - The location of the shared page is passed via the boot_params |
134 | struct as a physical address. |
135 | o The kernel will look for the tboot shared page address and, if it |
136 | exists, map it. |
137 | o As one of the checks/protections provided by TXT, it makes a copy |
138 | of the VT-d DMARs in a DMA-protected region of memory and verifies |
139 | them for correctness. The VT-d code will detect if the kernel was |
140 | launched with tboot and use this copy instead of the one in the |
141 | ACPI table. |
142 | o At this point, tboot and TXT are out of the picture until a |
143 | shutdown (S<n>) |
144 | o In order to put a system into any of the sleep states after a TXT |
145 | launch, TXT must first be exited. This is to prevent attacks that |
146 | attempt to crash the system to gain control on reboot and steal |
147 | data left in memory. |
148 | - The kernel will perform all of its sleep preparation and |
149 | populate the shared page with the ACPI data needed to put the |
150 | platform in the desired sleep state. |
151 | - Then the kernel jumps into tboot via the vector specified in the |
152 | shared page. |
153 | - Tboot will clean up the environment and disable TXT, then use the |
154 | kernel-provided ACPI information to actually place the platform |
155 | into the desired sleep state. |
156 | - In the case of S3, tboot will also register itself as the resume |
157 | vector. This is necessary because it must re-establish the |
158 | measured environment upon resume. Once the TXT environment |
159 | has been restored, it will restore the TPM PCRs and then |
160 | transfer control back to the kernel's S3 resume vector. |
161 | In order to preserve system integrity across S3, the kernel |
162 | provides tboot with a set of memory ranges (RAM and RESERVED_KERN |
163 | in the e820 table, but not any memory that BIOS might alter over |
164 | the S3 transition) that tboot will calculate a MAC (message |
165 | authentication code) over and then seal with the TPM. On resume |
166 | and once the measured environment has been re-established, tboot |
167 | will re-calculate the MAC and verify it against the sealed value. |
168 | Tboot's policy determines what happens if the verification fails. |
169 | Note that the c/s 194 of tboot which has the new MAC code supports |
170 | this. |
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