Lines Matching refs:the
6 provide the building blocks for creating trusted platforms.
8 Intel TXT was formerly known by the code name LaGrande Technology (LT).
15 Intel TXT is part of the vPro(TM) brand and is also available some
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,
22 This site also has a link to the Intel TXT MLE Developers Manual,
23 which has been updated for the new released platforms.
25 Intel TXT has been presented at various events over the past few
55 measure or protect the integrity of a running kernel, they all
56 assume the kernel is "good" to begin with. The Integrity
60 To get trust in the initial kernel without using Intel TXT, a
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
74 By using the hardware-based root of trust that Intel TXT provides,
76 pre-launch components can be removed from the trust chain, DMA
79 protection is provided for any data in the event of an improper
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
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
99 - Tboot will output various information about its progress to the
100 terminal, serial port, and/or an in-memory log; the output
103 tboot then verifies certain aspects of the environment (e.g. TPM NV
105 o It will wake the APs from the special sleep state the GETSEC[SENTER]
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
114 special code into the kernel's MP wakeup sequence.
116 verify the kernel and initrd.
117 - This policy is rooted in TPM NV and is described in the tboot
119 create and provision the policy.
124 o Tboot adjusts the e820 table provided by the bootloader to reserve
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'
132 pass this to the Linux kernel as it transfers control.
133 - The location of the shared page is passed via the boot_params
135 o The kernel will look for the tboot shared page address and, if 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
142 o At this point, tboot and TXT are out of the picture until a
144 o In order to put a system into any of the sleep states after a TXT
146 attempt to crash the system to gain control on reboot and steal
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
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
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
175 Configuring the System:
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
193 The kernel option for enabling Intel TXT support is found under the
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
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.