Talk:Systemd-cryptenroll

TPM: implicit update of PCR7(+??) with fwupd

There is a warning under section 5.3 for TPM which suggests fwupd can be configured to update the PCR7 (and any related registers) implicitly when the firmware is scheduled for upgrade. The external link is to a systemd TODO list, and it's hard to tell if this is available in systemd-cryptenroll yet.

When I was installing this new laptop, I ran into an issue where the TPM2 module would not unlock my LUKS2 volume containing my root Btrfs subvolume because a PCR (I think it was PCR7) did not match the current hash of the firmware after I had run fwupdmgr update and rebooted. Like an idiot I didn't take a photo of the recovery key, and I couldn't unlock the system after the firmware update. Luckily reinstalling from scratch only took about 20 more minutes, but I'm loath to try to upgrade this laptop's firmware again until I have a solution (I see there are already new firmware updates to apply). Ectospasm (talk) 17:31, 6 January 2024 (UTC)

Really sorry to hear this and I hope you had backups. Yes, the solution is to not bind disk encryption to PCR 7 and systemd plans to change this some time in the future in favor of binding to signatures of PCR values with either pcrlock policies or signed public key based policies. Currently, there's an open issue about this on fwupd for hooking firmware updates to systemd-pcrlock, which should prevent situations like yours from happening. Until that issue is resolved, I imagine binding pcrlock policies to disk encryption will be withheld so that leaves you with the latter--signed public key based policies based on measured boot states. For more detail about these policies please read the systemd-cryptenroll man page or watch Lennart's talk on Linux & TPMs. Nu4425 (talk) 01:44, 7 January 2024 (UTC)

Thankfully, this was a new installation and I wasn't at the point of needing backups (I hadn't restored anything from my other systems yet). I actually found that fwupd RFE on my own, and at the top Lennart mentions what we can do now, though doesn't explicitly delineate all the steps. I'm thinking I can do this:

• # fwupdmgr update (I must be sure not to reboot when prompted)
• # sbctl sign --save /path/to/fwupd/file.efi
• # systemd-pcrlock unlock-firmware-code
• # systemd-pcrlock make-policy

Then reboot. Does that order of operations look correct? Should I unlock the firmware code before updating? Since pcrlock is so new, it's difficult to find any guides on this. Ectospasm (talk) 15:09, 7 January 2024 (UTC)

The order of those operations look correct, as long as you do not make the policy before the firmware update. To quote a section of the man page: "If a firmware update is applied this data will be out-of-date and any access policy generated from it will no longer pass. It is thus recommended to invoke unlock-firmware-code before doing a firmware update, followed by make-policy to refresh the policy". Of course, this doesn't just apply to the unlock-firmware-code command. Therefore, if you want to follow it per the man page, I believe you'd first unlock the policy, update the firmware then make a new policy

Personally though, on my system, I haven't tried binding any secrets to a pcrlock policy and will wait until it's not experimental. Even if it wasn't, for some reason, systemd-pcrlock is unable to recognize a lot of the measurements in my TPM event log so I wouldn't be able to make a strong policy for anything Nu4425 (talk) 20:40, 7 January 2024 (UTC)

So maybe the order of operations should be this:

# systemd-pcrlock unlock-firmware-code

# fwupdmgr update # be sure *NOT* to reboot when prompted

# sbctl sign --save /path/to/fwupd/file.efi

# systemd-pcrlock make-policy

I guess in order for this to work make-policy needs to anticipate what changes will be made when the computer is rebooted; I'll have to test this out and see how I fare.

Ectospasm (talk) 00:28, 13 January 2024 (UTC)

And this worked! I didn't have previous pcrlock files in place, so unlock-firmware-code didn't really have anything to do. I updated the firmware, with --no-reboot-check. It looked like I only had one component of my laptop firmware updated, and fwupdmgr didn't appear to say I needed to reboot. I rebooted anyway, and my TPM unlocked my LUKS2 container no problem!

I'll go ahead and update this wiki article. It remains to be seen whether a more involved firmware update will have the same results, but I think this is promising! Ectospasm (talk) 02:54, 23 January 2024 (UTC)

Oh, I see. I don't think I ran the sbctl step, I didn't see fwupdmgr install the fwupd.efi file, so that may have been why my TPM unlocked my LUKS2 container. Ectospasm (talk) 02:57, 23 January 2024 (UTC)

I'm glad that you weren't locked out this time. To clarify though, you're binding the pcrlock policy to your system and not a storage device? Because you shouldn't be able decrypt your system as encryption for the root filesystem hasn't been merged yet unless you built systemd with that pull request? If you didn't, then this leaves me to believe that you were successful because you probably chose not to bind to PCR 7 anymore. Nu4425 (talk) 05:53, 23 January 2024 (UTC)

Honestly I don't really understand much about this at all. The output of make-policy did appear to skip over PCR 7; the output (I wish I had saved it) did indeed look like it excluded that PCR.

I also noticed there are a bunch of pcrlock-related services, I haven't enabled or started any of those. Do I need to worry about those for now? Ectospasm (talk) 10:44, 23 January 2024 (UTC)

If you had forgotten, you can review and verify the options you specified at enrollment by examining the dumped output of your LUKS2 header. If you do not see PCR 7, I believe that's probably why. Also, no, I believe you don't need to worry about those services until encryption for the root fs has been merged. Currently, only external storage devices should be supported, so if you have any to spare you can experimenting with systemd-pcrlock on them. Nu4425 (talk) 00:57, 24 January 2024 (UTC)

Ahh, OK. So since this LUKS2 container is for my root subvolume (and subvolumes underneath), using systemd-pcrlock had no effect. I will check out the LUKS2 header, as when I ran into the problem back when I first installed this laptop the TPM balked since the firmware upgrade invalidated the digest in PCR7.

I'm not totally convinced the firmware update from yesterday actually did anything, since the only firmware update was for my webcam. Lenovo has been emailing me pretty regularly with firmware updates for Win10 and Win11, but my guess is they haven't gotten to LVFS yet. Ectospasm (talk) 03:41, 24 January 2024 (UTC)