* Measurements during boot
@ 2012-07-05 8:05 Nicholas Psomas
2012-07-07 9:05 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 4+ messages in thread
From: Nicholas Psomas @ 2012-07-05 8:05 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4789 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Measurements during boot
@ 2012-07-05 7:04 Nicholas Psomas
0 siblings, 0 replies; 4+ messages in thread
From: Nicholas Psomas @ 2012-07-05 7:04 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2108 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-07 9:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-05 8:05 Measurements during boot Nicholas Psomas
2012-07-07 9:05 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-07-07 9:24 ` Nicholas Psomas
-- strict thread matches above, loose matches on Subject: below --
2012-07-05 7:04 Nicholas Psomas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.