Trusted Boot in Fedora

Miloslav Trmač mitr at
Thu Jun 23 16:15:14 UTC 2011

On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd at> wrote:
> I have done some inventory on this topic, and have some questions.
I'm not really an expert on this... Hopefully someone will correct my mistakes.

> 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 ?
The TPM allows verifying that this kernel (and only this kernel) is
actually running.  An attacker with access to the hard drive ("evil
maid") can modify the code to disable any signature check that would
be done in software (e.t. inside grub); TPM cannot be bypassed this

> 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 ?
All a properly deployed TPM does is, it verifies that a specific
software is running on the system, and if so, it allows the OS to use
some cryptographic keys stored inside the TPM. This could be used for
various things - yes, one of them is DRM. Something more useful is
only allowing a computer into the "secure" company network after the
TPM has testified that it does not have a rootkit running.

Note that none the keys in TPM are not pre-loaded by any distrusted
software company - each TPM generates its own keys.

Also note that the TPM does not, itself, stop any software from
running, or disconnect anything from a network, and so on - this needs
to be done outside of the TPM, using mechanisms that (mostly) already
exist anyway (e.g. a network switch that only connects devices that
authenticate with a password).

(From a practical standpoint, AFAICS it would be _much_ easier to set
up the network access restriction by an IT department than to set up
DRM by a world-wide software vendor - I can't see how would one even
start to build the list of allowed configurations of all
general-purpose computers, which would be necessary for the DRM.)

> Will the TPM allow a third party remote access to the machine ?
Absolutely not.

> Will the TPM be BIOS-configurable (enable/disable) by the user (hardware
> owner) ?
AFAIK it usually is so in existing BIOSes - but if you don't use the
TPM, it really doesn't affect anything; it's just like an unused sound

> How is that tboot blob module secured from tampering ?
It is signed by the CPU/TPM manufacturer (Intel in this case).

> By the virtue of beeing associated with the "root of trust" ?
"Root of trust" in TPM lingo is something different - it's "we know
that the kernel and related software we run has not been tampered
with".  The root of trust is established by the tboot blob, which
should verify the state of all relevant hardware.

> 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 ?
I'm not sure whether it is actually possible to set up LCP so that the
boot doesn't continue at all.  Assuming that it is so...

1) If the LCP did not require a signed kernel, and the attacker has
modified it to require a signed kernel, this is not really different
from an attacker deleting /boot.  If an attacker has root access,
denial of service is the smallest of your problems.

2) If the LCP required a signed kernel, and the attacker has somehow
managed to configure the system to boot a different kernel (without
getting complete root access), then "denial of boot" would be
considered a success - the policy has worked exactly as the sysadmin
configured it.

The big question here is kernel upgrades - there has to be a mechanism
to replace the old "allowed" kernel by a newer version, and I don't
know how that is supposed to work.  And assuming an attacker with root
access, it might be possible for the attacker to use this upgrade
mechanism to let the system boot a modified kernel without violating
the LCP.

>       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 ?;a=tree;f=drivers/char/tpm;h=b9b34d58aa403510fcb8901420fca0b9b03d1d3e;hb=HEAD
seems to contain a few open-source drivers for the hardware. AFAIK
none of the required drivers are binary-only.

More information about the devel mailing list