[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TPM support status ?

From: Emmanuel Fleury
Subject: TPM support status ?
Date: Wed, 19 Aug 2009 13:00:43 +0200
User-agent: Mozilla-Thunderbird (X11/20090701)

Dear all,

I know this is a quite sensitive topic and I'm really not willing to
start a new flame-war about it. I just want to know the exact status of
it and what is the (official) position of the GRUB team on the TPM support.

Last discussion about the TPM issue was in February (see: and
it ended up with a kind of statu quo.

I just propose to expose the consequences of TPM support for GRUB, first
in a technical point of view and then on an ethical one. Then, I hope
the GRUB team will write his official position on the TPM support.

1) Technical Aspects

>From a purely technical point of view, the TPM support in GRUB is about
the "Trusted Boot" with a partial support and a full one.

Partial support means that GRUB is able to (TPM commands are taken from
"Part 3 - Commands", see further for references):

1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of
the kernel that is intended to be loaded.

2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
SHA-1 digest.

3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
of a previous (safe) boot. We assume that the previous link of the chain
of trust (BIOS?) has already checked that GRUB hasn't been tampered
before starting it.

If this part fail, GRUB should stop here and tell the user that the
kernel has been tampered. If everything went ok, GRUB get back to the
usual way...

A full support of TPM means that GRUB should also be able to ask to a
remote authority if the content of the PCR is still ok... Technically,
it would be stupid to include a full TCP/IP stack (or whatever network
protocol) into GRUB, so it would be much more realistic to just leave it
to the OS and only pass the needed data to it.

[Note: I have to admit that I don't see how to deal properly with this
full support as you somehow need to rely on some links of the chain of
trust that may have been tampered. Implementing this step may require
quite a lot of thinking (and personally, I don't think it worth it...
but it's only my humble opinion).]

For the TPM specifications see:

- Part 1 - Design Principles

- Part 2 - Structures of the TPM

- Part 3 - Commands

2) Ethical Aspects

Ok, lets end here with the technical point of view and consider now the
ethical point of view.

The core of the problem with TPM has been nicely summed up by Robert
Millan in the last thread about it:

« If there was a device that behaves like a TPM except remote
attestation is not possible (e.g. by one of the means described above),
I wouldn't object to it, and I think the GNU project wouldn't either,
but then referring to that as "TPM" is misleading. »

Indeed, let us imagine one moment that GRUB has a full support of TPM
(meaning what I've stated before plus remote attestation).

Firms will be able to use GRUB to lock down a computer to a specific
software suite. Being able to remotely add (or revoke) at will some of
its customers. Which is quite close to the "treacherous computing"
described by Stallman...

The only thing users can do, would be to install a new BIOS, totally
reformat the hard-drive and install his own OS.

[Note that, according to the TPM specifications, it is always possible
to clear the TPM without password under physical presence assertion
(TPM_ForceClear command, Part 3, p.29) and thus the user will also be
able to use the TPM (if you are ok to loose all the data stored on the

On the other hand, there is a quite high step between the partial
support that I've described before and the full support with remote
attestation... (and users may require this partial support for their own

Now, the question whether one shouldn't support a technology because it
may lead to evil usage is something that should be solved inside the
GRUB team (and I believe that the GRUB team has already solved this
question out).

3) GRUB Team Position ?

So, what is the official position of the GRUB team about TPM ? Did it
change since February ?

Emmanuel Fleury

Programs must be written for people to read,
and only incidentally for machines to execute.
  -- Abelson & Sussman, SICP, preface to the first edition

reply via email to

[Prev in Thread] Current Thread [Next in Thread]