How Does it Work?
=================
o Tboot is an executable that is launched by the bootloader as the "kernel"
(the binary the bootloader executes).
o It performs all of the work necessary to determine if the platform supports
Intel TXT and, if so, executes the GETSEC[SENTER] processor instruction
that initiates the dynamic root of trust.
- If tboot determines that the system does not support Intel TXT or is not
configured correctly (e.g. the SINIT AC Module was incorrect), it will
directly launch the kernel with no changes to any state.
- Tboot will output various information about its progress to the terminal,
serial port, and/or an in-memory log; the output locations can be configured
with a command line switch.
o The GETSEC[SENTER] instruction will return control to tboot and tboot then
verifies certain aspects of the environment (e.g. TPM NV lock, e820 table
does not have invalid entries, etc.).
o It will wake the APs from the special sleep state the GETSEC[SENTER]
instruction had put them in and place them into a wait-for-SIPI state.
- Because the processors will not respond to an INIT or SIPI when in the
TXT environment, it is necessary to create a small VT-x guest for the
APs. When they run in this guest, they will simply wait for the
INIT-SIPI-SIPI sequence, which will cause VMEXITs, and then disable VT
and jump to the SIPI vector. This approach seemed like a better choice
than having to insert special code into the kernel's MP wakeup sequence.
o Tboot then applies an (optional) user-defined launch policy to verify the
kernel and initrd.
- This policy is rooted in TPM NV and is described in the tboot project.
The tboot project also contains code for tools to create and provision
the policy.
- Policies are completely under user control and if not present then any
kernel will be launched.
- Policy action is flexible and can include halting on failures or simply
logging them and continuing.
o Tboot adjusts the e820 table provided by the bootloader to reserve its own
location in memory as well as to reserve certain other TXT-related regions.
o As part of it's launch, tboot DMA protects all of RAM (using the VT-d PMRs).
Thus, the kernel must be booted with 'intel_iommu=on' in order to remove this
blanket protection and use VT-d's page-level protection.
o Tboot will populate a shared page with some data about itself and pass this
to the Linux kernel as it transfers control.
- The location of the shared page is passed via the boot_params struct as
a physical address.
o The kernel will look for the tboot shared page address and, if it exists,
map it.
o As one of the checks/protections provided by TXT, it makes a copy of the VT-d
DMARs in a DMA-protected region of memory and verifies them for correctness.
The VT-d code will detect if the kernel was launched with tboot and use this
copy instead of the one in the ACPI table.
o At this point, tboot and TXT are out of the picture until a shutdown (S<n>)
o In order to put a system into any of the sleep states after a TXT launch,
TXT must first be exited. This is to prevent attacks that attempt to crash
the system to gain control on reboot and steal data left in memory.
- The kernel will perform all of its sleep preparation and populate the
shared page with the ACPI data needed to put the platform in the desired
sleep state.
- Then the kernel jumps into tboot via the vector specified in the shared
page.
- Tboot will clean up the environment and disable TXT, then use the
kernel-provided ACPI information to actually place the platform into the
desired sleep state.
- In the case of S3, tboot will also register itself as the resume vector.
This is necessary because it must re-establish the measured environment
upon resume. Once the TXT environment has been restored, it will
restore the TPM PCRs and then transfer control back to the kernel's S3
resume vector.
In order to preserve system integrity across S3, the kernel provides tboot
with a set of memory ranges (kernel code/data/bss, S3 resume code, and AP
trampoline) that tboot will calculate a MAC (message authentication code)
over and then seal with the TPM. On resume and once the measured environment
has been re-established, tboot will re-calculate the MAC and verify it
against the sealed value. Tboot's policy determines what happens if the
verification fails.
That's pretty much it for TXT support.
Configuring the System:
======================
This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSes
allow these to be individually enabled/disabled and the screens in which
to find them are BIOS-specific.
grub.conf needs to be modified as follows:
title Linux 2.6.30-rc4 w/ tboot
root (hd0,0)
kernel /tboot.gz logging=serial,vga,memory
module /vmlinuz-2.6.30-rc4 intel_iommu=on ro root=LABEL=/
rhgb console=ttyS0,115200 3
module /initrd-2.6.30-rc4.img
module /Q35_SINIT_17.BIN
The kernel option for enabling Intel TXT support is found under the
Security top-level menu and is called "Enable Intel(R) Trusted Execution
Technology (TXT)". It is marked as EXPERIMENTAL and depends only on the
generic x86 support (to allow maximum flexibility in kernel build
options) and CONFIG_DMAR, since the tboot code will detect whether the
platform actually supports Intel TXT and thus whether any of the kernel
code is executed.
The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
Authenticated Code Module. It is specific to the chipset in the system
and can also be found on the Trusted Boot site. It is a firmware module
digitally signed by Intel that is used as part of the DRTM process to
verify and configure the system. It is signed because it operates at a
higher privilege level in the system than any other macrocode and its
correct operation is critical to the establishment of the DRTM. The
process for determining the correct SINIT ACM for a system is documented
in the SINIT-guide.txt file that is on the tboot SourceForge site under
the SINIT ACM downloads.
TODOs:
=====
This patch implements the basic TXT support as described above. There
will be additional patches sent to add functionality and improve the
security of the launched kernel. Some of those tasks are:
o S3 dynamic memory and userspace integrity protection
The current patch only provides memory integrity protection of the kernel
code and static data. Complete S3 protection requires providing integrity
over userspace and kernel dynamic data as well.
We have this implemented for 64b builds and are working out some issues on 32b.
o BIOS call scrubbing
One of the goals of TXT is to reduce the TCB by eliminating pre-kernel code from
the trust boundary. This includes BIOS (with the exception of SMM). We will see
how many of the BIOS calls can be eliminated on a TXT boot and whether the remainder
of BIOS-provided code and data can be measured or "protected" (e.g. validate ACPI
pointers before using).
This information is also contained in the file
Documentation/intel_txt.txt (in the patch).
We welcome your comments and suggestions and genuinely value your feedback.
Joseph Cihula
Shane Wang
Intel Corp.
Is there a summary of what has changes from RFC v4 ?
Alan
> From: Alan Cox [mailto:[email protected]]
> Sent: Tuesday, June 23, 2009 2:11 AM
>
> Is there a summary of what has changes from RFC v4 ?
- The monolithic patch was broken into four patches that represent discrete functionality (boot and build, reboot/halt shutdown, Sx shutdown, forcing DMAR on). An appropriate (and more descriptive) patch description was added to each patch.
- Small stylistic cleanups (capitalization, comment wording, whitespace, etc.).
- The code in hwsleep.c that populated the tboot ACPI structures was moved into its own function in tboot.c.
- Use pr_warning(), pr_info(), pr_debug().
- Moved some #include's from the middle of tboot.c to the top.
- Changed the memory type of the tboot shared page from E820_UNUSABLE to E820_RESERVED (really a change to tboot, but requires a change here in the checking code).
And the new patches that I'm about to send have notes in the top indicating their changes from the previous versions.
Joe
On Mon, Jun 22, 2009 at 05:41:26PM -0700, Joseph Cihula wrote:
> The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
> Authenticated Code Module. It is specific to the chipset in the system
> and can also be found on the Trusted Boot site. It is a firmware module
> digitally signed by Intel that is used as part of the DRTM process to
> verify and configure the system.
This seems a little disingenious. Firmware isn't typically loaded by grub
into main memory and executed by the host processor.
so, is this all worthless without the binary blob ?
"trust us, it's signed by intel" doesn't make me feel more secure.
Dave
On 06/23/2009 05:04 PM, Cihula, Joseph wrote:
>> From: Alan Cox [mailto:[email protected]] Sent: Tuesday,
>> June 23, 2009 2:11 AM
>>
>> Is there a summary of what has changes from RFC v4 ?
>
> - The monolithic patch was broken into four patches that represent
> discrete functionality (boot and build, reboot/halt shutdown, Sx
> shutdown, forcing DMAR on). An appropriate (and more descriptive)
> patch description was added to each patch.
>
> - Small stylistic cleanups (capitalization, comment wording,
> whitespace, etc.).
>
> - The code in hwsleep.c that populated the tboot ACPI structures was
> moved into its own function in tboot.c.
>
> - Use pr_warning(), pr_info(), pr_debug().
>
> - Moved some #include's from the middle of tboot.c to the top.
>
> - Changed the memory type of the tboot shared page from
> E820_UNUSABLE to E820_RESERVED (really a change to tboot, but
> requires a change here in the checking code).
>
> And the new patches that I'm about to send have notes in the top
> indicating their changes from the previous versions.
So it still requires a giant binary blob to be loaded into main
memory to be executed by the main CPU with full privileges (or
plausibly even more lattitude than kernel normally has), right?
--
Peter
Dave Jones wrote:
> On Mon, Jun 22, 2009 at 05:41:26PM -0700, Joseph Cihula wrote:
>
> > The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
> > Authenticated Code Module. It is specific to the chipset in the system
> > and can also be found on the Trusted Boot site. It is a firmware module
> > digitally signed by Intel that is used as part of the DRTM process to
> > verify and configure the system.
>
> This seems a little disingenious. Firmware isn't typically loaded by grub
> into main memory and executed by the host processor.
>
> so, is this all worthless without the binary blob ?
>
> "trust us, it's signed by intel" doesn't make me feel more secure.
how's that different from your normal bios ?
On Wed, Jun 24, 2009 at 01:37:49PM -0700, Arjan van de Ven wrote:
> Dave Jones wrote:
> > On Mon, Jun 22, 2009 at 05:41:26PM -0700, Joseph Cihula wrote:
> >
> > > The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
> > > Authenticated Code Module. It is specific to the chipset in the system
> > > and can also be found on the Trusted Boot site. It is a firmware module
> > > digitally signed by Intel that is used as part of the DRTM process to
> > > verify and configure the system.
> >
> > This seems a little disingenious. Firmware isn't typically loaded by grub
> > into main memory and executed by the host processor.
> >
> > so, is this all worthless without the binary blob ?
> >
> > "trust us, it's signed by intel" doesn't make me feel more secure.
>
> how's that different from your normal bios ?
well..
AFAICS, this code exists solely to enable a binary blob. We don't do that
for the BIOS. Even for blobs like ACPI, we at least have documentation on
the opcodes/data structures.
Also, if they're the same as you claim, why isn't the blob just included as
part of the BIOS ?
Dave
On Wed, Jun 24, 2009 at 01:37:49PM -0700, Arjan van de Ven wrote:
> Dave Jones wrote:
>> This seems a little disingenious. Firmware isn't typically loaded by grub
>> into main memory and executed by the host processor.
>>
>> so, is this all worthless without the binary blob ?
>>
>> "trust us, it's signed by intel" doesn't make me feel more secure.
>
> how's that different from your normal bios ?
BIOSes can typically be replaced with trusted code. Is the source to the
ACMs available? Is there any way for the owner of the machine to
substitute their key for Intel's?
--
Matthew Garrett | [email protected]
> > "trust us, it's signed by intel" doesn't make me feel more secure.
>
> how's that different from your normal bios ?
I've yet to see grub load my bios 8)
Alan
Let me try to unify and respond to the couple of branches of this thread:
> From: Alan Cox [mailto:[email protected]]
> Sent: Wednesday, June 24, 2009 3:50 PM
>
> > > "trust us, it's signed by intel" doesn't make me feel more secure.
> >
> > how's that different from your normal bios ?
>
> I've yet to see grub load my bios 8)
and
> From: Dave Jones [mailto:[email protected]]
> Sent: Wednesday, June 24, 2009 1:51 PM
>
> On Wed, Jun 24, 2009 at 01:37:49PM -0700, Arjan van de Ven wrote:
> > Dave Jones wrote:
> > > On Mon, Jun 22, 2009 at 05:41:26PM -0700, Joseph Cihula wrote:
> > >
> > > > The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
> > > > Authenticated Code Module. It is specific to the chipset in the system
> > > > and can also be found on the Trusted Boot site. It is a firmware module
> > > > digitally signed by Intel that is used as part of the DRTM process to
> > > > verify and configure the system.
> > >
> > > This seems a little disingenious. Firmware isn't typically loaded by grub
> > > into main memory and executed by the host processor.
> > >
> > > so, is this all worthless without the binary blob ?
> > >
> > > "trust us, it's signed by intel" doesn't make me feel more secure.
> >
> > how's that different from your normal bios ?
>
> well..
>
> AFAICS, this code exists solely to enable a binary blob. We don't do that
> for the BIOS. Even for blobs like ACPI, we at least have documentation on
> the opcodes/data structures.
>
> Also, if they're the same as you claim, why isn't the blob just included as
> part of the BIOS ?
I would actually liken the SINIT AC module more to microcode than to BIOS. If you look at the Intel(R) TXT measured launch flow (e.g. see http://www.xen.org/files/summit_3/Xen_support_for_LaGrande_Technology.pdf), SINIT is executed by the SENTER microcode and the software that executed the SENTER instruction doesn't get control again until after SINIT finishes executing (and SINIT is executing in a special CPU mode that only microcode can create).
Microcode patches, while not loaded by a bootloader, *are* contained in most OSes (as well as the BIOS). And the TXT architecture allows for an OEM to include SINIT in the BIOS flash (or a special HDD partition, etc.), but desktop BIOS flash space is usually very constrained and none of the OEMs have chosen to do this. But even if they had, just like most BIOSes include a microcode patch, there is still value in system software being able to provide an updated version so that users don't have to re-flash their BIOS just to get the new module.
Joe
> > well..
> >
> > AFAICS, this code exists solely to enable a binary blob. We don't do that
> > for the BIOS. Even for blobs like ACPI, we at least have documentation on
> > the opcodes/data structures.
> >
> > Also, if they're the same as you claim, why isn't the blob just included as
> > part of the BIOS ?
>
> I would actually liken the SINIT AC module more to microcode than to BIOS. If you look at the Intel(R) TXT measured launch flow (e.g. see http://www.xen.org/files/summit_3/Xen_support_for_LaGrande_Technology.pdf), SINIT is executed by the SENTER microcode and the software that executed the SENTER instruction doesn't get control again until after SINIT finishes executing (and SINIT is executing in a special CPU mode that only microcode can create).
>
> Microcode patches, while not loaded by a bootloader, *are* contained in most OSes (as well as the BIOS). And the TXT architecture allows for an OEM to include SINIT in the BIOS flash (or a special HDD partition, etc.), but desktop BIOS flash space is usually very constrained and none of the OEMs have chosen to do this. But even if they had, just like most BIOSes include a microcode patch, there is still value in system software being able to provide an updated version so that users don't have to re-flash their BIOS just to get the new module.
>
There's additional problem with this: if Intel is bought by Microsoft
(or chinese government) next year, it may create & sign evil blob that
will subvert security of sinit. That's pretty unique/dangerous. (Maybe
FBI can get special signed version?)
While I mostly have to trust Intel from 2007, this expects me to trust
intel from 2021, too. Sounds dangerous.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html