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: http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) 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 http://www.trustedcomputinggroup.org/files/resource_files/ACD19914-1D09-3519-ADA64741A1A15795/mainP1DPrev103.zip - Part 2 - Structures of the TPM http://www.trustedcomputinggroup.org/files/resource_files/8D3D6571-1D09-3519-AD22EA2911D4E9D0/mainP2Structrev103.pdf - Part 3 - Commands http://www.trustedcomputinggroup.org/files/static_page_files/ACD28F6C-1D09-3519-AD210DC2597F1E4C/mainP3Commandsrev103.pdf 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 platform).] 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 usage). 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 ? Regards -- 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
