UKI, Secure Boot, TPM, and firmware upgrade

ectospasm · 2024-01-04 23:20:06

I'm not sure whether this belongs under the Laptop forum, or the Kernel and Hardware forum. Since this could befall a desktop with UKI (Unified Kernel Image), Secure Boot, and a TPM cryptoprocessor, I'm filing it under Kernel & Hardware. Feel free to move if the moderators feel it's warranted.

I installed Arch on my new Lenovo ThinkPad X1 Carbon, 11 gen last week. I actually had to install it twice: the first time I didn't realize upgrading the firmware will modify one of the TPM's PCR registers, and cause the TPM to fail unlocking the LUKS2 volume (I set up the key with systemd-cryptenroll). Like an idiot I didn't take a photo of the recovery key I set up (I was expecting to see a QR code but it didn't show in the Linux console), so when I rebooted after updating the firmware with fwupd I was completely locked out of the system. Reinstalling only took about 20 extra minutes, and when I set up the recovery key the second time I took a photo of it.

Arch has already posted a message that there are new firmware updates available, but I'm loathe to upgrade the firmware since I can't find the proper way to ensure the TPM2 can unlock the LUKS2 volume afterwards. Do I simply identify which key slot the TPM2 is using, and run systemd-cryptenroll again? Or is there some other way to ensure the TPM2 PCR has the right hash once the firmware is updated? Surely I don't have to unlock it with a recovery key first, and then run systemd-cryptenroll once it's been unlocked after the firmware upgrade?

That latter procedure seems to be a chicken versus egg problem, surely there has to be a proper way? I really think this should be documented on the Wiki in a few different places, but I'll do that once I have what I need.

EDIT: systemd-cryptenroll#Trusted_Platform_Module has a Warning that fwupd can do this implicitly, I just need to figure out how. Or maybe I'm reading that wrong, and fwupd simply changes the firmware certificates which invalidates the keys/hash in PCR7, which causes the problem I ran into. I need to see if there's a way to update PCR7 before the new firmware is applied.

So, Googling for "linux fwupd tpm update pcr after firmware upgrade" led me to this request for a fwupd enhancement from none other than Lennart Poettering (THE systemd designer). If I'm reading that correctly, I can use systemd-pcrlock to do this, I just need to determine the proper order of operations, and then test it.

EDIT2: So the manual step is listed in Poettering's initial post in that RFE for fwupd. He's not explicit about the complete order of operations, but I think it would be this:

# fwupdmgr update # DO NOT LET IT REBOOT WHEN PROMPTED!!!
# # ...sign the firmware update EFI executable(s) with sbctl, I had done that previously
# systemd-pcrlock unlock-firmware-code
# systemd-pcrlock make-policy
# systemctl reboot

Poettering's RFE is for fwupd to do this automagically, and there's quite a bit of discussion on it there (no resolution as of yet).

Last edited by ectospasm (2024-01-06 18:45:55)

ectospasm · 2024-01-23 03:02:12

So, I finally built up the courage to actually try this. Unfortunately, there wasn't much to update since I had only done a firmware update in December. I don't think fwupdmgr installed a fwupd.efi executable, so when I rebooted my TPM unlocked my LUKS2 container without issue.

I will wait a few months to wait untl there's another more involved firmware update, and try again.

ectospasm · 2024-01-26 01:21:58

As of right now, systemd-pcrlock does not operate on root LUKS2 volumes. So I'd need that to make it into a systemd release before I can use it for that.

I did check my LUKS2 header with sudo cryptsetup luksDump /dev/nvme0n1p2, and it shows the TPM2 is storing the firmware hash in PCR 7. This stuff is so new I should probably wait a few months before I apply any new firmware updates.

I guess this is what we get being bleeding edge. One of the reasons I don't typically like to be on the absolute bleeding edge, too much waiting for features, functionality, and bugs to be ironed out.

swsnr · 2024-01-26 08:40:49

PCR 7 measures the secure boot state. It shouldn't change on every firmware update, but it can change if the firmware update changes the secure boot configuration. A firmware update would probably not change the PK or KEK, but it will certainly change the dbx from time to time to add revocations in response to vulnerabilities in signed binaries (which happened a few times in the past, see e.g. https://access.redhat.com/articles/5991201 ). It could also change the db, perhaps to enroll hashes of option ROMs, and it might update its built-in vendor db, PK, or KEK defaults and measure these (though those wouldn't be used unless they were enrolled).

In my experience firmware updates seldom change the secure boot state; you might just have been unlucky to catch the one firmware update that does. The next one might not. If you don't mind occasionally using the recovery key and update the LUKS enrollment after a firmware update, you don't need to bother with systemd-pcrlock and TPM policies which are arguably a lot more complex.

If you intend to use systemd-pcrlock, you need to update your LUKS enrollment to bind to the policy file generated by systemd-pcrlock (using "systemd-cryptenroll --tpm2-pcrlock") instead of binding directly to PCR measurements (as "systemd-cryptenroll --tpm2-device=auto" does by default). Depending on the amount of measurements you want to take into account this might come with quite some maintenance churn as you have to carefully update those policies when making changes to the system, meaning you might end up having to use your recovery key more often than you'd like to which you wanted to avoid in the first place.

It's also not a particularly common setup on home machines, I believe; the whole policy locking feature targets appliance/IoT vendors, which usually do not have access to a device to enter a recovery and must ensure that any kind of TPM enrollments keep working across updates and changes of the system configuration ahead of time. As you've probably noticed already this means that there are not many resources around on the internet.

If you really wish to go that way, I recommend you first experiment with this setup in a virtual machine. libvirt supports software TPM and UEFI, and let's you simulate firmware updates and secure boot database changes fairly easily.

ectospasm · 2024-01-27 12:57:49

Thank you for the reply, this actually is inline with my experience. I did update my firmware last week, and it didn't change the Secure Boot state. I did run systemd-pcrlock unlock-firmware-code, followed by the firmware upgade itself, then systemd-pcrlock make-policy. The firmware update did not create the fwupd.efi (or whatever it's called) like it did the last time I upgraded my firmware, so I'm sure that had something to do with it.

The last time I ran fwupdmgr update, it looked like it only upgraded my webcam firmware, so it was exactly as you described. Now that I have my recovery key, and I've used it a couple of times, I could simply re-enroll my TPM and not bother with pcrlock.

zhihuiyuze · 2025-08-08 23:41:36

Now I am wondering whether to enable +11 for my new computer, because I am afraid that my TPM will not be able to decrypt normally after upgrading the Linux kernel. And updating the signature seems to require manual

Lone_Wolf · 2025-08-09 09:45:24

Please don't necro bump.

If you need help or want to discuss further start a new thread and link to this one.

Moderator Note
Closing this old thread.

Arch Linux

#1 2024-01-04 23:20:06

UKI, Secure Boot, TPM, and firmware upgrade

#2 2024-01-23 03:02:12

Re: UKI, Secure Boot, TPM, and firmware upgrade

#3 2024-01-26 01:21:58

Re: UKI, Secure Boot, TPM, and firmware upgrade

#4 2024-01-26 08:40:49

Re: UKI, Secure Boot, TPM, and firmware upgrade

#5 2024-01-27 12:57:49

Re: UKI, Secure Boot, TPM, and firmware upgrade

#6 2025-08-08 23:41:36

Re: UKI, Secure Boot, TPM, and firmware upgrade

#7 2025-08-09 09:45:24

Re: UKI, Secure Boot, TPM, and firmware upgrade

Board footer