Matthew, On Mon, Feb 6, 2017 at 8:43 AM, Matthew Garrett <mj...@srcf.ucam.org> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
