On Mon, 6 Feb 2017, 18:55 Jon McCune <jonmcc...@google.com> wrote: > 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. > Independently of this, it's still useful to have Linux command line to be exposed to verifier if it wants to see it. I can imagine verifier wanting to check Linux command line but not wanting to verify the grub config file.
> > (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 > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
