Closed mtahmed closed 8 years ago
For PCR 8 and PCR 9 have a look in the Wiki
PCR 10: yes, that would be the easiest.
PCR 11: yes, that should work.
Feel free to ask if you have more questions
I tried to compute the PCR 8 and worked perfectly the sha1sum of the dump matched the measurement values in /sys/kernel/security/tpm0/ascii_bios_measurements
and the final hash (with 0s) matched the one in /sys/class/misc/tpm0/device/pcrs
.
For PCR 9, however, dd if=/dev/sdX bs=1 skip=1020 count=2 | hexdump -d
gives the output
0000000 00057
0000002
And the output of sudo dd if=/dev/sda bs=512 skip=2 count=57 | sha1sum
does not match the output from the ascii_bios_measurements table and the final hash (with 0s) doesn't match the pcrs
output from above. Maybe the size is incorrect? Or maybe the place I get the size from is not correct? Not sure and any help would be great!
(Please note though that I haven't yet built the modules into core.img.)
I can confirm that precomputation of PCR 9 does not work as described in the Wiki. I think thik this is related to the HP workaround introduced in version 1.2.1. Could you please try if it works with version 1.2.0 ?
It works with v1.2.0! Would it be possible to have a compile-time option to enable the HP workarounds (or vice-versa, to disable them)? That way I won't be stuck with an older version. If you prefer, I could do the work involved if you could help me along the way.
And thanks for all the help so far! I am going to try it with the modules built-in and I am going to try PCR 11 next which be some trial and error. Just to double-check, what TrustedGRUB2 does is it chain-hashes all the commands it executes, correct? If so, there's for example a load_video
function call and then that function does a few insmod
s etc. Will load_video
be included in the hashing chain? How about if ... then ... else
statements?
Glad to hear that it is working with v1.2.0.
Disabling the workaround in default mode is already on my todo list: #18
I also try to lookup how to do the precomputation in case the workaround is activated.
Just to double-check, what TrustedGRUB2 does is it chain-hashes all the commands it executes, correct?
Yes, exactly. Hopefully i have some time in the future to write a tool that automatically precomputes the PCR for a given grub.cfg
If so, there's for example a load_video function call and then that function does a few insmods etc. Will load_video be included in the hashing chain? How about if ... then ... else statements?
Only the commands that are executed are measured. load_video
is a function in your grub.cfg and not a grub_command? Then this shouldn't be measured. Only the insmod
commands. For if ... then ... else
only the commands in the code path that is executed will be measured.
Is there a way to get some debug output to see what commands are executed on boot?
Also, would it be simpler to just measure grub.cfg? Are there any downsides to it? Is that the case that user might execute other commands besides the ones executed in grub.cfg?
Is there a way to get some debug output to see what commands are executed on boot?
If you define TGRUB_DEBUG
you can see what commands are measured. The measurement of commands is done here
Thats probably too fast therefore you should add an sleep with grub_sleep()
Also, would it be simpler to just measure grub.cfg? Are there any downsides to it? Is that the case that user might execute other commands besides the ones executed in grub.cfg?
I'm not really sure about this. You could measure grub.cfg but that does not mean that everything is actually executed in there. So i felt safer to measure at least additionally all commands that are executed.
I tried your suggestion of defining TGRUB_DEBUG
and using grub_sleep()
and it seems TrustedGRUB2 is measuring a lot more than we thought e.g. control structures, set ...
commands, whole submenu commands etc. More examples
[ -f ... ]
[ -z ... ]
, [ ]
etc. Doesn't measure if
, else
, then
etc.set foobar=myfoobar
, loadenv
etc.submenu foobar --id abcd { menuentry ... { ... }
etc. Since these tend to be longer than 1024 bytes, it seems it cuts it off at the 1024-byte mark which makes it even harder to pre-compute these values.setparams
commandsinsmod
commandssearch
commandsecho
commandsSo I suggest following changes to measuring commands:
[ ... ]
commands.submenu ...
commands.This change should be fairly straightforward from reading the code and I can send a pull request if you think you will accept it.
Thanks for all the help so far! :smile:
I'm fine with that change. One remark: if there is a command between those [ ... ]
, this command should be measured of course. If this is even possible, i'm not sure.
Looking forward to your PR ;-)
I am using
tpm-luks
to store keys in the TPM NVRAM and the initramfs has a module (provided by tpm-luks) which retrieves the key from TPM and mounts the LUKS partition using that key. These keys can also be sealed using the TPM and are only retrievable if the TPM is in the correct state.The issue is that when I upgrade the kernel etc., the PCR states will change on next boot and I won't be able to unseal the data. So my question is, what specific things does TrustedGRUB2 measure that I can measure using
tpm-luks
kernel update hook so that the key can be reasealed using the correct PCR states?In particular, from the question here: https://github.com/Sirrix-AG/TrustedGRUB2/issues/2, I gather:
dd if=/dev/sdX bs=512 skip=1 count=1 | sha1sum
and thenPCR8 = sha1sum( 0000000000000000000000000000000000000000 || SHA1 from command above )
.menuentry
string itself? This assumption is from reading the TrustedGRUB2 code so I am not 100% sure - would appreciate if you could confirm!And of course I can easily verify this on the machine to make sure that
tpm-luks
andTrustedGRUB2
are making the same measurements.Thanks a lot for being so helpful! :smile: