Grub settings change on every boot (TPM-related)

[cthu1hoo]

I'm not sure if this is an actual bug, and even if this should be reported here, this is more of a request for comments. It's possible that behavior I'm seeing is entirely normal. I apologize if i'm submitting this to the wrong place.

I'm running Fedora Kinoite 36. Just for fun, I've been trying to setup automatic unlocking of a LUKS volume using systemd-cryptenroll on boot.

I did the usual, overlayed tpm2-tools, enabled initramfs, but then I've noticed that some TPM PCRs (specifically 8, which Grub is responsible for) change on every boot, and their values are seemingly cycling between two sets, thus my enrolled PCRs don't apply, and I'm asked my FDE password on boot.

A diff between two TPM event logs shows stuff like this (I'll attach complete event logs, just in case those would be helpful):

   PCRIndex: 8
...
     String: |-
-      grub_cmd: [ 0 = 1 -o 0 = 1 ]
+      grub_cmd: [ 1 = 1 -o 0 = 1 ]

   Event:
     String: |-
-      grub_cmd: set menu_hide_ok=0
+      grub_cmd: set menu_hide_ok=1

I'm seeing this behavior on several different PCs so it doesn't seem hardware related.

Over several reboots and power-cycles it seems that those options are cycling between two sets of values. So I need to keep at least two sets of TPM PCRs enrolled because one would be chosen on each reboot.

This significantly contributes to overall fragility of TPM auto unlock, because to keep things reasonably secure you need to add PCR 8/9 to the set which means you need to re-enroll the volume on every kernel/initramfs change. And I can't really exclude PCR 8 while enrolling either because, among other things, it includes hashed kernel cmdline.

I haven't been able to figure out why this happens, I suppose this depends on the result of previous boot.

So, my question is, is this how this is supposed to work? In my opinion unless there were actual configuration changes or system updates, PCR sets should stay constant, much like PCRs 0-7, which firmware is responsible for, don't change on their own. So Grub changing its own configuration on every boot seems like a bug. Is it possible to disable this behavior, if it is by design?

Thanks in advance for any help.

eventlog_20220520-0923.txt
eventlog_20220520-0934.txt

Edit: it seems that this behavior is connected to 1) me pressing or not pressing a key on boot and 2) previous boot being successful, as described here: https://ask.fedoraproject.org/t/how-to-disable-grub2-menu-auto-hide/14242/2

Edit2: so far I had to do the following to prevent grub environment being changed at runtime which seems to be what's causing it, not sure if its enough:

# i dunno when this fires, and i would be fine with "0", but just in case...
sudo systemctl mask grub-boot-indeterminate.service

# this fires 2 minutes after user login
sudo ln -s /dev/null /etc/systemd/user/timers.target.wants/grub-boot-success.timer

# this also needs to be disabled
sudo ln -s /dev/null /etc/systemd/user/timers.target.wants/grub-boot-indeterminate.timer

I'm posting about it here in hopes this helps someone else dealing with TPM.

[travier]

Thanks a lot for the investigation. This looks like something that should be fixed.

[travier]

From side investigation, this is very unlikely to ever get fixed. GRUB mesures its entire config into the TPM + all actions taken interactively and the config just changes too much between versions to be useful as a measurement. Binding against it is thus not a great experience. We'll have to wait until we can switch to systemd-boot.

The work for system-boot is tracked in #404.

I'll close this issue given that it is unlikely to be fixed. The workarounds in the first message should help those interested.