Trusted Boot project in F16

JB jb.1234abcd at
Thu Jun 23 12:10:53 UTC 2011


The Trusted Boot topic/thread was started on Fedora dev list, with the purpose
of discussing it before planned F16 implementation.

They ask for input, and we would like to discuss it with them, before they
bless us with the project implementation.

I tried to subscribe to Fedora dev list, but there is no response, none.
Is that a technical problem ? Are they afraid of their own community members ?
Come on, I just wanted to have tete a tete with you :-)

So I decided to post it on F16 test list to give people a heads-up.

The Intel Trusted Platform consists of two components:
- Trusted Platform Module (TPM) chip
  A hardware component, consisting of cryptographic processor and secure
- Trusted Boot 
  A software component, open-source and partially close-source (?) components,
  in Fedora packages.
  # yum install tboot
  tboot            i686         20110429-1.fc15     fedora         355 k
  Installing for dependencies:
  trousers         i686         0.3.6-1.fc15        fedora         279 k

Trusted Boot is a mechanism by which a pre-kernel/VMM module (that uses Intel
Trusted Execution Technology (Intel TXT)) performs a measured (pre-identified)
and verified launch of an OS kernel/VMM.

First, the obvious questions.

Why do you need Trusted Boot mechanism to ensure that identified and origin-
verified Linux kernel is booted ?
Why signing a kernel (a la GPG) is not good enough to verify its origin at
boot time ?

Now, regarding the Trusted Boot solution.

The obvious question:
why does an open-source distro like Fedora (but also Red Hat) want to
philosophically accept and technically support this solution ?

Will the TPM allow a third party remote access to the machine ?

Will the TPM be BIOS-configurable (enable/disable) by the user (hardware
owner) ?
If so, how will that impact the kernel selection in boot process (tboot
enable/disable) ?

How is that tboot blob module secured from tampering ?
By the virtue of beeing associated with the "root of trust" ?

If the Launch Control Policy can be created and modified by the user, then
what prevents an attacker from impersonating the usersysadmin, modifying
the policy, and causing a denial-of-boot or unintended-boot attack ?

There is more that this project implements (root of trust, etc).

Ref: tcsd(8)
Can that "root of trust" be compromised by TSS applications or any other
means (e.g. through tools provided by this project) ?

Ref: tcsd(8)
       tcsd is compatible with the IBM Research TPM device driver available
       from and the TPM device driver
       available from

Are these drivers open-source ? Is TPM device driver open-source ?

Well, you know what to ask about ...


Angela GHEORGHIU - Puccini - La Bohème - Si mi chiamano Mimi

More information about the test mailing list