About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / intel_txt.txt


Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 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.
Hide Line Numbers


About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog