grub-devel
[Top][All Lists]
Advanced

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

Re: Support for TPM measurements on UEFI systems


From: Jon McCune
Subject: Re: Support for TPM measurements on UEFI systems
Date: Mon, 6 Feb 2017 09:53:57 -0800

Matthew,

On Mon, Feb 6, 2017 at 8:43 AM, Matthew Garrett <address@hidden> wrote:
On Sun, Feb 05, 2017 at 01:28:20PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> See verify.h for the interface. Obviously if you need changes in the API,
> please say.

I think that's a starting point, but it doesn't seem sufficient for some
of the cases I care about. For instance, measuring boot state isn't just
about the files that are read - we also need to measure the commands
that grub runs

I'm not sure about measuring the commands that GRUB runs. GRUB's config file is a shell-like language, and measuring that file should give a pretty good indication of its behavior. In the grey area between "what is code?" and "what is data?", making the case that grub.cfg is code seems feasible, which greatly simplifies the work of whatever verifies attestations or binds/seals data. Although, implementations for these two don't really seem to be in conflict so maybe GRUB could be configured one way or the other.

(I'm coming at this from the perspective of "gathering golden measurements by just-run-it-and-see considered harmful".)
 
and the command line passed to the kernel, for instance.

Agreed.
 
Ideally we'd also have more context available in order to make a better
decision about which PCR to measure something into,

This is definitely interesting. Re: the scenario above, files could get measured into one place. Commands executed could get measured into another.
 
but I can't think of
a good way to do that simply by hooking open. That also seems to make it
difficult to implement a handler that should only be verifying some
objects - for instance, a UEFI secure boot handler only wants to verify
the kernel (or something that's chainloaded) and ignore everything else.


Best,
-Jon

 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

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