Hi,

I'm currently looking to add support to grub2 to provide code/data
measurement to the TPM on supported PC's (if you want more information on
this topic, google search "root of trust for reporting", otherwise I'm
happy to explain in a further post or email).  I've begun writing some
interfaces to the hardware (TPM), but was wondering what the best way of
structuring this entire operation might be.  To make my current goal clear,
I'm only beginning with the multiboot module as a starting point (but it
would be preferable if it was generic enough to be widely useable in any
loader modules), and I'm currently aiming for the boot loader to be used in
a PXE environment, so am not concerned in measuring separate stages (my
understanding for PXE at the moment is that everything is compiled together
into a single image which is downloaded and measured from a server by a PXE
boot rom, I don't intend to download separate grub modules afterwards).

No matter how I look at it, I feel that the only possible solution will be
one which edits the loader code to insert a call which measures the kernel
and module (initrd, not grub modules) code, just before boot.  Is it
worthwhile however hooking it in such a way that a user could create a line
such as:

measure multiboot /path/to/kernel kernel-cmd-line-args
measure module /path/to/module

or:

measure
multiboot /path/to/kernel kernel-cmd-line-args
module /path/to/module

as opposed to the usual configuration which is just:

multiboot /path/to/kernel kernel-cmd-line-args
module /path/to/module

in their grub.cfg.  Otherwise I could just hard code the measurement
process into the multiboot loader process, possibly making it optional at
compile time with a #define?

Thanks in advance for your time and input.

Nick
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to