I had my auto unlocking being broken for a long time. Tried to fix it without success. TPM2 unlock just didn't work. After playing with BIOS settings (clearing secure boot keys and etc) it suddenly started working. Problem is - i'd expect it to fail.

cryptsetup luksDump header.img
…
Tokens:
  0: systemd-tpm2
        tpm2-hash-pcrs:   0+7
…

and while playing with BIOS secure boot settings I was monitoring PCR 7 with

each boot this value changed (because I've changed secure boot setting in BIOS), yet each time disk was auto unlocked. I've read wiki and articles and know that TPM and LUKS is problematic, but this look utterly unsafe. What is going on?

Last edited by avi9526 (2026-06-05 16:48:33)

TPM != secure boot

secureboot: regular x509 chain just to verify signature of the chain up to the kernel to the systems root key
TPM: a device to meassure and compare a systems state
they both usually work independent of eachother

enable secureboot without proper chain just causes the boot to fail - while the tpm isn't affected by this as it more or less just checks: "hey, is this still the hardware as last time - and is it unmodified?"
I don't know if "is secureboot enabled?" can even be meassured for tpm auto-unlock - but it likely isn't in any default

I have identified the problem. It appears that I have created it myself. You can notice that I use a detached luks header, but since /boot is not properly available at the time of unlocking the copy of the header must be built into initramfs image. So any change to actual header require "mkinitcpio" afterwards.

sbctl status
…
    Setup Mode:     ✓ Disabled
    Secure Boot:    ✓ Enabled
…

systemd-cryptenroll --wipe-slot=tpm2 Header.img
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 Header.img
mkinitcpio -p linux…
reboot
…
PROFIT

Now LUKS auto unlock works when secure boot enabled and not does not work when secure boot altered (disabled, keys changed, etc)

Header being built into initramfs means I cannot use PCR9 that hashes initrd image, because I need to store hash of initrd inside initrd, which is practically impossible. Shame.

Last edited by avi9526 (2026-06-05 16:48:24)

I will take a look, thnx

Separate header is somehow pleasant to me:
1) it is easy to backup and fallback, there is 3 backups of header lying in my /boot
2) it is unix-way - as it is file
3) it corresponds to idea that data must be separated from non-data
4) such encryption could be removed/enrolled in the raw way due to the fact that encrypted data is aligned to un-encrypted data [https://unix.stackexchange.com/a/130998/67899]
5) it could be argued that encrypted partition without header is no more than just random data, actual situation depends on how close the government soldering iron to your backdoor

Last edited by avi9526 (Today 20:03:37)