blob: f40a1f030019d46867d79e0c3f2b4ce58a854545 [file] [log] [blame]
Joseph Cihula31625342009-06-30 19:30:59 -07001Intel(R) TXT Overview:
2=====================
3
4Intel's technology for safer computing, Intel(R) Trusted Execution
5Technology (Intel(R) TXT), defines platform-level enhancements that
6provide the building blocks for creating trusted platforms.
7
8Intel TXT was formerly known by the code name LaGrande Technology (LT).
9
10Intel TXT in Brief:
11o Provides dynamic root of trust for measurement (DRTM)
12o Data protection in case of improper shutdown
13o Measurement and verification of launched environment
14
15Intel TXT is part of the vPro(TM) brand and is also available some
16non-vPro systems. It is currently available on desktop systems
17based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
18Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
19PM45, and GS45 Express chipsets.
20
21For more information, see http://www.intel.com/technology/security/.
22This site also has a link to the Intel TXT MLE Developers Manual,
23which has been updated for the new released platforms.
24
25Intel TXT has been presented at various events over the past few
26years, 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
38Trusted Boot Project Overview:
39=============================
40
41Trusted Boot (tboot) is an open source, pre- kernel/VMM module that
42uses Intel TXT to perform a measured and verified launch of an OS
43kernel/VMM.
44
45It is hosted on SourceForge at http://sourceforge.net/projects/tboot.
46The mercurial source repo is available at http://www.bughost.org/
47repos.hg/tboot.hg.
48
49Tboot currently supports launching Xen (open source VMM/hypervisor
50w/ TXT support since v3.2), and now Linux kernels.
51
52
53Value Proposition for Linux or "Why should you care?"
54=====================================================
55
56While there are many products and technologies that attempt to
57measure or protect the integrity of a running kernel, they all
58assume the kernel is "good" to begin with. The Integrity
59Measurement Architecture (IMA) and Linux Integrity Module interface
60are examples of such solutions.
61
62To get trust in the initial kernel without using Intel TXT, a
63static root of trust must be used. This bases trust in BIOS
64starting at system reset and requires measurement of all code
65executed between system reset through the completion of the kernel
66boot as well as data objects used by that code. In the case of a
67Linux kernel, this means all of BIOS, any option ROMs, the
68bootloader and the boot config. In practice, this is a lot of
69code/data, much of which is subject to change from boot to boot
70(e.g. changing NICs may change option ROMs). Without reference
71hashes, these measurement changes are difficult to assess or
72confirm as benign. This process also does not provide DMA
73protection, memory configuration/alias checks and locks, crash
74protection, or policy support.
75
76By using the hardware-based root of trust that Intel TXT provides,
77many of these issues can be mitigated. Specifically: many
78pre-launch components can be removed from the trust chain, DMA
79protection is provided to all launched components, a large number
80of platform configuration checks are performed and values locked,
81protection is provided for any data in the event of an improper
82shutdown, and there is support for policy-based execution/verification.
83This provides a more stable measurement and a higher assurance of
84system configuration and initial state than would be otherwise
85possible. Since the tboot project is open source, source code for
86almost all parts of the trust chain is available (excepting SMM and
87Intel-provided firmware).
88
89How Does it Work?
90=================
91
92o Tboot is an executable that is launched by the bootloader as
93 the "kernel" (the binary the bootloader executes).
94o 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.
104o 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.).
107o 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.
117o 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.
126o 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.
129o 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.
133o 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.
137o The kernel will look for the tboot shared page address and, if it
138 exists, map it.
139o 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.
144o At this point, tboot and TXT are out of the picture until a
145 shutdown (S<n>)
146o 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
172That's pretty much it for TXT support.
173
174
175Configuring the System:
176======================
177
178This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
179
180In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSes
181allow these to be individually enabled/disabled and the screens in
182which to find them are BIOS-specific.
183
184grub.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
193The kernel option for enabling Intel TXT support is found under the
194Security top-level menu and is called "Enable Intel(R) Trusted
195Execution Technology (TXT)". It is marked as EXPERIMENTAL and
196depends on the generic x86 support (to allow maximum flexibility in
197kernel build options), since the tboot code will detect whether the
198platform actually supports Intel TXT and thus whether any of the
199kernel code is executed.
200
201The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
202Authenticated Code Module. It is specific to the chipset in the
203system 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
205DRTM process to verify and configure the system. It is signed
206because it operates at a higher privilege level in the system than
207any other macrocode and its correct operation is critical to the
208establishment of the DRTM. The process for determining the correct
209SINIT ACM for a system is documented in the SINIT-guide.txt file
210that is on the tboot SourceForge site under the SINIT ACM downloads.