What specific measurements does TrustedGRUB2 make?

[mtahmed]

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: #2, I gather:

• PCR 8 First sector of TrustedGRUB2 kernel (diskboot.img): This is easy to do: dd if=/dev/sdX bs=512 skip=1 count=1 | sha1sum and then PCR8 = sha1sum( 0000000000000000000000000000000000000000 || SHA1 from command above ).
• PCR 9 TrustedGRUB2 kernel (core.img): This is the part that I am confused about - I am not sure how to get the size of core.img and how many bytes to read to use for the sha1sum. Help would be appreciated!
• PCR 10 Everything that is loaded from disk (grub2-modules, Linux-kernel, initrd, ntldr, etc.) // TODO: fonts, themes, locales: For this, I will follow your advice and build the modules into the core.img so that it's measured in PCR 9 above.
• PCR 11 contains all commandline arguments from scripts (e.g. grub.cfg) and those entered in the shell: For this, I assume if there is only one menuentry in grub.cfg, then I can just hash all the strings except the 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 and TrustedGRUB2 are making the same measurements.

Thanks a lot for being so helpful! 😄

[neusdan]

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

[mtahmed]

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.)

[neusdan]

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 ?

[mtahmed]

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 insmods etc. Will load_video be included in the hashing chain? How about if ... then ... else statements?

[neusdan]

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.

[mtahmed]

Is there a way to get some debug output to see what commands are executed on boot?

[mtahmed]

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?

[neusdan]

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.

[mtahmed]

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

• Control structures: [ -f ... ] [ -z ... ], [ ] etc. Doesn't measure if, else, then etc.
• Env commands: set foobar=myfoobar, loadenv etc.
• The whole submenu commands: 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 commands
• insmod commands
• search commands
• echo commands

So I suggest following changes to measuring commands:

• Do not measure [ ... ] commands.
• Do not measure 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! 😄

[neusdan]

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 ;-)