3

I recently installed Ubuntu on an old SSD, as I wanted to test out some software on a different OS. After installing Ubuntu (using debootstrap, arch-chroot and apt), my EFI's NVRAM boot order got messed up, and the TPM2 will not now automatically unlock my Arch root and swap partitions. I am prompted to enter a recovery key or password.

So, I know I need to update the PCR registers in the TPM. But I have a couple of questions:

  • How should I replace the entries in the old TPM2 PCR slots, instead of adding new ones?
  • Can someone explain why the TPM chip now fails to unlock my partitions, and what I should try and avoid doing again in future?

My primary OS is Arch Linux, set up following a couple of articles:

systemd-boot is used as bootloader.

Two dm-crypt partitions are unlocked with the TPM at boot:

  • root
  • swap (allows for suspend and resume).

After installing Ubuntu, both the root and swap volumes would not unlock with the TPM.

How to invalidate the TPM PCR Registers

One thing I realised that I'd done incorrectly done was to install Ubuntu (into /media/ubuntu) before mounting /efi onto /media/ubuntu/boot/efi. So, after first installing Ubuntu with debootstrap, I then ran:

  • mount --bind /efi /media/ubuntu/boot/efi
  • arch-chroot /media/ubuntu
  • apt install grub-efi-amd64 (This removes grub-pc)
  • grub-install

So, I now have one /efi partition, an encrypted /boot partition for Arch Linux, and the Ubuntu partition has a /boot folder. (There's a Windows bootloader too, so yeah, it's a mess...)

grub's os-probe doesn't detect my Arch Linux install, so I had to get back in by pressing F11 at early boot and selecting Linux Boot Manager. At this point, systemd asks me to enter the unlock password or recovery key for my root partition. (I have both currently, so getting in isn't an issue, unless and until I reboot remotely).

My setup

I've put down quite a lengthy list of diagnostic commands, which should be pretty helpful for anyone diagnosing something similar in future (me included, no doubt!)

Update: The TPM was enrolled to unlock the encrypted partition on PCR 7, like so:

# Install the TPM tools pacman -S tpm2-tools # Check the name of the kernel module for our TPM systemd-cryptenroll --tpm2-device=list # Generate a recovery key (not mandatory but strongly recommended) systemd-cryptenroll --recovery-key /dev/gpt-auto-root-luks # Generate a key in the TPM2 and add it to a key slot in the LUKS device systemd-cryptenroll --tpm2-device=auto /dev/gpt-auto-root-luks --tpm2-pcrs=7 # This is the command to use later, to remove the (insecure) initial password #systemd-cryptenroll /dev/gpt-auto-root-luks --wipe-slot=password

My partition tables are quite busy:

$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 238.5G 0 disk ├─sdb1 8:17 0 128G 0 part /media/ubuntu ├─sdb2 8:18 0 110G 0 part └─sdb3 8:19 0 527M 0 part nvme0n1 259:0 0 931.5G 0 disk ├─nvme0n1p1 259:1 0 100M 0 part ├─nvme0n1p2 259:2 0 16M 0 part ├─nvme0n1p3 259:3 0 165.4G 0 part ├─nvme0n1p4 259:4 0 507M 0 part ├─nvme0n1p5 259:5 0 1G 0 part ├─nvme0n1p6 259:6 0 32G 0 part │ └─swap 254:1 0 32G 0 crypt [SWAP] ├─nvme0n1p7 259:7 0 227G 0 part │ └─root 254:0 0 227G 0 crypt / └─nvme0n1p8 259:8 0 505.5G 0 part └─data 254:3 0 505.5G 0 crypt /var/lib/docker /media/data $ sudo fdisk -l /dev/nvme0n1 /dev/sdb Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Samsung SSD 980 PRO 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Device Start End Sectors Size Type /dev/nvme0n1p1 2048 206847 204800 100M EFI System (/efi) /dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved /dev/nvme0n1p3 239616 347119443 346879828 165.4G Microsoft basic data (Win 10) /dev/nvme0n1p4 347119616 348157951 1038336 507M Windows recovery environment /dev/nvme0n1p5 348157952 350255103 2097152 1G Linux extended boot (/boot) /dev/nvme0n1p6 350255104 417363967 67108864 32G Linux swap /dev/nvme0n1p7 417363968 893417471 476053504 227G Linux root (x86-64) (/) /dev/nvme0n1p8 893417472 1953523711 1060106240 505.5G Linux filesystem (/media/data) Disk /dev/sdb: 238.47 GiB, 256060514304 bytes, 500118192 sectors Disk model: M4-CT256M4SSD2 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 268437503 268435456 128G 83 Linux (/media/ubuntu) /dev/sdb2 * 268437504 499035680 230598177 110G 7 HPFS/NTFS/exFAT /dev/sdb3 499036160 500115455 1079296 527M 27 Hidden NTFS WinRE

Secure Boot is installed, but not enabled:

$ sbctl status Installed: ✓ sbctl is installed Owner GUID: 1fd4cb4a-55ff-42f6-8dbb-285bfedf56de Setup Mode: ✓ Disabled Secure Boot: ✗ Disabled Vendor Keys: microsoft

My boot logs showing kernel command line and TPM related entries (showing it's loaded early):

$ sudo journalctl -k --grep='Command line|tpm|TPM' Aug 30 06:10:03 archlinux kernel: Command line: initcall_blacklist=acpi_cpufreq_init amd_pstate=passive nvidia_drm.modeset=1 nvidia_drm.fbdev=1 ip=:::::eth0:dhcp Aug 30 06:10:03 archlinux kernel: efi: ACPI=0xbd440000 ACPI 2.0=0xbd440014 TPMFinalLog=0xbd40a000 SMBIOS=0xbde22000 SMBIOS 3.0=0xbde21000 MEMATTR=0xb7f14018 ESRT=0xb7f14898 RNG=0xbcd38f18 INITRD=0xb6d12f18 TPMEvent> Aug 30 06:10:03 archlinux kernel: ACPI: TPM2 0x00000000BCD50000 00004C (v04 ALASKA A M I 00000001 AMI 00000000) Aug 30 06:10:03 archlinux kernel: ACPI: Reserving TPM2 table memory at [mem 0xbcd50000-0xbcd5004b] Aug 30 06:10:03 archlinux kernel: tpm_crb MSFT0101:00: Disabling hwrng Aug 30 06:10:03 archlinux systemd[1]: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +K> Aug 30 06:10:03 archlinux systemd[1]: Starting TPM PCR Barrier (initrd)... Aug 30 06:13:19 ryzenbeast systemd[1]: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +> Aug 30 06:13:19 ryzenbeast systemd[1]: Expecting device /dev/tpm0... Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on TPM PCR Measurements. Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on Make TPM PCR Policy. Aug 30 06:13:19 ryzenbeast systemd[1]: Starting TPM PCR Machine ID Measurement... Aug 30 06:13:19 ryzenbeast systemd[1]: Starting Early TPM SRK Setup...

Kernel Modules and Hooks:

# mkinitcpio.conf MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm) HOOKS=(base systemd autodetect microcode modconf keyboard keymap consolefont sd-vconsole block sd-tinyssh encryptssh sd-encrypt filesystems resume fsck)

LUKS header key slots:

$ sudo systemd-cryptenroll /dev/disk/by-partlabel/archlinux SLOT TYPE 0 password 1 recovery 2 tpm2 $ sudo systemd-cryptenroll /dev/disk/by-partlabel/swap SLOT TYPE 0 password 1 tpm2

Signed files:

$ sbctl verify Verifying file database and EFI images in /efi... ✓ /boot/EFI/Linux/arch-linux-fallback.efi is signed ✓ /boot/EFI/Linux/arch-linux.efi is signed ✗ /efi/EFI/Boot/bootx64.efi is not signed (this became signed after running `bootctl install`) ✓ /efi/EFI/systemd/systemd-bootx64.efi is signed ✓ /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed is signed ✗ /efi/EFI/GRUB/grubx64.efi is not signed ✗ /efi/EFI/Manjaro/grubx64.efi is not signed ✗ /efi/EFI/Microsoft/Boot/Resources/bootres.dll is not signed ✗ /efi/EFI/Microsoft/Boot/Resources/en-US/bootres.dll.mui is not signed ✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/bootmgfw.efi is not signed ✗ /efi/EFI/Microsoft/Boot/bootmgr.efi is not signed ✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/cs-CZ/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/da-DK/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/de-DE/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/el-GR/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/en-US/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/en-US/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/en-US/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/es-ES/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fi-FI/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/fr-FR/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/hu-HU/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/it-IT/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ja-JP/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_10df.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_10ec.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_1137.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_14e4.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_15b3.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_1969.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_19a2.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_1af4.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_02_8086.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_07_1415.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kd_0C_8086.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kdnet_uart16550.dll is not signed ✗ /efi/EFI/Microsoft/Boot/kdstub.dll is not signed ✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ko-KR/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/memtest.efi is not signed ✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/nb-NO/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/nl-NL/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pl-PL/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-BR/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/pt-PT/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/qps-ploc/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/ru-RU/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/sv-SE/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/tr-TR/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-CN/memtest.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgfw.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgr.efi.mui is not signed ✗ /efi/EFI/Microsoft/Boot/zh-TW/memtest.efi.mui is not signed ✗ /efi/EFI/ubuntu/grubx64.efi is not signed

Systemd measurements

$ sudo /usr/lib/systemd/systemd-measure status # PCR[11] kernel-boot 11:sha1=<SHA1SUM> 11:sha256=<SHA256SUM> # PCR[12] kernel-config (NOT SET!) 12:sha1=0000000000000000000000000000000000000000 12:sha256=0000000000000000000000000000000000000000000000000000000000000000 # PCR[13] sysexts (NOT SET!) 13:sha1=0000000000000000000000000000000000000000 13:sha256=0000000000000000000000000000000000000000000000000000000000000000 
$ sudo /usr/lib/systemd/systemd-measure calculate --current --bank=sha1 --bank=sha256 # PCR[11] Phase <enter-initrd> 11:sha1=<SHA1SUM_2> 11:sha256=<SHA256SUM_2> # PCR[11] Phase <enter-initrd:leave-initrd> 11:sha1=<SHA1SUM_3> 11:sha256=<SHA256SUM_3> # PCR[11] Phase <enter-initrd:leave-initrd:sysinit> 11:sha1=<SHA256SUM_4> 11:sha256=<SHA256SUM_4> # PCR[11] Phase <enter-initrd:leave-initrd:sysinit:ready> 11:sha1=<SHA256SUM_5> 11:sha256=<SHA256SUM_5>

Test opening the root partition with TPM

$ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7 Failed to unseal secret using TPM2: Operation not permitted Enter passphrase for /dev/nvme0n1p7:

Current PCR slots

$ systemd-analyze pcrs NR NAME SHA256 0 platform-code <SHA256> 1 platform-config <SHA256> 2 external-code <SHA256> 3 external-config <SHA256> 4 boot-loader-code <SHA256> 5 boot-loader-config <SHA256> 6 host-platform <SHA256> 7 secure-boot-policy <SHA256> 8 - 0000000000000000000000000000000000000000000000000000000000000000 9 kernel-initrd <SHA256> 10 ima 0000000000000000000000000000000000000000000000000000000000000000 11 kernel-boot <SHA256> 12 kernel-config 0000000000000000000000000000000000000000000000000000000000000000 13 sysexts 0000000000000000000000000000000000000000000000000000000000000000 14 shim-policy 0000000000000000000000000000000000000000000000000000000000000000 15 system-identity <SHA256> 16 debug 0000000000000000000000000000000000000000000000000000000000000000 17 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 18 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 19 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 20 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 21 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 22 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 23 application-support 0000000000000000000000000000000000000000000000000000000000000000

Adding a new TPM entry

I know I can add a new TPM entry and delete the old one with the following command:

# Enroll TPM (again). $ sudo systemd-cryptenroll --tpm2-device=auto /dev/nvme0n1p7` 🔐 Please enter current passphrase for disk /dev/nvme0n1p7: New TPM2 token enrolled as key slot 3. # List LUKS unlock slots on my root partition. $ sudo systemd-cryptenroll /dev/nvme0n1p7 SLOT TYPE 0 password 1 recovery 2 tpm2 3 tpm2 # Wipe the old tpm2 entry $ sudo systemd-cryptenroll /dev/nvme0n1p7 --wipe-slot=2 Wiped slot 2. # Test I can open it $ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7 $

Update: System Journal Entries

I checked journalctl -u systemd-cryptsetup@root to see if I can hunt down some more info before and after the first failed boot.

On a successful boot:

Aug 27 09:46:02 archlinux systemd[1]: Starting Cryptography Setup for root... Aug 27 09:46:02 archlinux systemd-cryptsetup[407]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks. Aug 27 09:46:02 archlinux systemd-cryptsetup[407]: Automatically discovered security TPM2 token unlocks volume. Aug 27 09:46:04 archlinux systemd-cryptsetup[407]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256). Aug 27 09:46:04 archlinux systemd[1]: Finished Cryptography Setup for root.

On the next, failed boot:

Aug 28 08:09:52 archlinux systemd[1]: Starting Cryptography Setup for root... Aug 28 08:09:52 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks. Aug 28 08:09:52 archlinux systemd-cryptsetup[403]: Automatically discovered security TPM2 token unlocks volume. Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: Failed to unseal secret using TPM2: Operation not permitted Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: No valid TPM2 token data found. Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking. Aug 28 08:10:21 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks. Aug 28 08:10:24 archlinux systemd-cryptsetup[403]: Failed to activate with specified passphrase. (Passphrase incorrect?) Aug 28 08:10:30 archlinux systemd-cryptsetup[403]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks. Aug 28 08:10:33 archlinux systemd-cryptsetup[403]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256). Aug 28 08:10:33 archlinux systemd[1]: Finished Cryptography Setup for root.

Seeing mention of PCR15 here, explained in man systemd-cryptenroll as:

systemd-cryptsetup(8) optionally measures the volume key of activated LUKS volumes into this PCR. systemd-pcrmachine.service(8) measures the machine-id(5) into this PCR. [email protected](8) measures mount points, file system UUIDs, labels, partition UUIDs of the root and /var/ filesystems into this PCR.

It would appear that these measurements would have changed by (re-)formatting a partition and would be enough to corrupt this PCR register...

Overhanging Questions

Now I've looked into fixing this and effectively have done, I have questions!

  • What caused the TPM slot value to become incorrect?
    • If I update Ubuntu's kernel or initrd, will it happen again?
  • How to prevent this from happening again?
  • I see systemd introduced a pcrlock tool in November 2023, but (I think) it is still experimental and I don't fully understand it, nor do I know if it would help. Would it?
  • Update: How should I update PCR 15 after formatting a partition?
Improve this question
4
  • Which of those TPM PCRs did you actually use for the cryptsetup key slot? Commented Sep 1, 2024 at 7:27
  • PCR 7, only. I've updated my answer to include the TPM2 enrolment commands :) Commented Sep 2, 2024 at 6:34
  • 1
    Note that "failures" like this can be caused by tampering (by hacker or someone with physical access). As a general rule you should not simply boot a system where the TPM refuses to unseal due to PCR mismatches. Better to ensure that boot options, kernel, initramfs... have not been modified. Commented Sep 2, 2024 at 10:00
  • Indeed, that's a very good point! Boot options are easy to check, but how should one go about checking the kernel and initramfs haven't been modified maliciously, given the PCR mismatch? File modified times? The TPM event log doesn't appear to capture timestamps (twobit.org/2016/05/31/tpm2-uefi-measurements-and-event-log), so it's difficult to see what and when caused a PCR measurement to change? Commented Sep 3, 2024 at 7:39

1 Answer 1

Reset to default
4

So, I know I need to update the PCR registers in the TPM

It works the opposite way. The boot process updates PCR registers to represent current system state, while your LUKS keyslot (sealed by the TPM, but actually stored within the LUKS header on disk) is bound to a specific "expected" PCR value.

Secure Boot is installed, but not enabled

Then binding to PCR 7 doesn't do you any good, as it is the PCR that represents Secure Boot state only, so without SB it doesn't protect you against state changes (e.g. an unsigned kernel remains possible to tamper with).

The keyslot is still bound to the physical hardware, yes, but that's an inherent property of the TPM sealing operation – you'd get the same effect even without PCR binding.

What caused the TPM slot value to become incorrect?

There are two general causes:

  1. The SRK (storage root key) stored in the TPM has been replaced.

  2. The policy that was specified during sealing no longer matches reality, e.g. if the data was sealed to specific raw PCR values, the live PCRs no longer match expected ones.

Case #1 is, in theory, very unlikely to happen without a full TPM clear, but...I have a vague recollection of certain changes in a very recent systemd version that changed how the EC SRK was generated.

(TPM2 SRKs are generated deterministically from seed+template, so whereas an RSA SRK is generated once and stored, an EC SRK can be generated on the fly. If I recall correctly, earlier systemd versions used to provide a not-quite-standard template that resulted in a different SRK compared to later versions.)

Case #2 depends on what PCRs were used. Each PCR is a rolling hash of specific events that the firmware (or bootloader, or sometimes the OS) writes to an in-memory log; functionally like a Git commit log. The event log can be read from Windows or Linux, e.g. using "tcg-log-parser".

For PCR 7, the only measurements should be 1) whether Secure Boot is enabled at all, 2) the current state of all the Secure Boot variables (PK/KEK/db/dbx), and 3) the specific db entries used to validate every signed file.

(The latter means that PCR 7 will distinguish Windows and non-Windows boot files, or MS-signed vs custom-signed boot files, so you can actually keep the MS UEFI CA active without it compromising your custom-signed system.)

It's possible that the Secure Boot state changed by Windows or Linux installing a new dbx list (revoked bootloader signatures) through fwupd or Windows Update. But only traveling back in time and getting a before/after comparison of the full event log would give you a definite answer. (Or, if you boot Windows often, it keeps a stash of event log archives somewhere in C:\Windows.)

If I update Ubuntu's kernel or initrd, will it happen again?

Depends on the PCR binding – it should not happen with PCR 7 as long as the Secure Boot configuration doesn't change.

On the other hand, e.g. using PCR 4 (which contains events recording the exact hashes of the bootloader and vmlinuz) or PCR 11 (which contains a hash of the initrd) would make it break after every kernel update; this is why systemd invented its "signed PCR" feature for example.

I see systemd introduced a pcrlock tool in November 2023, but (I think) it is still experimental and I don't fully understand it, nor do I know if it would help. Would it?

As above, depends on the PCR bindings. Pcrlock is supposed to predict future PCR values and do the equivalent of re-sealing the LUKS keyslot against them (but with more indirection), so e.g. if you were using PCR 4+11 for exact kernel hashes, it would need to be run after each upgrade to re-seal against the new kernel.

(Since the PCRs are hashes of an event log, it's possible to read and "replay" the same log in memory, feeding each event to SHA256() the same way a TPM would – but upon encountering e.g. the "vmlinuz.efi hash" entry, substitute its value with the hash of the new kernel.)

I've never used systemd-pcrlock (though I've written my own tool that does a similar thing for PCR 4), but it seems like it would help if you did the job of integrating it to your system upgrade process; as with many systemd-related things recently, it's probably slightly over-engineered and very much aimed at distributions making fully-sealed packages, rather than end-users.

Improve this answer
4
  • Oh I see, you are right. Looks like other documentation I've read in the past was wrong. There's a good discussion of it here: superuser.com/a/1731263/112499 Commented Sep 2, 2024 at 10:46
  • 1
    @PhilipCouling Well, it's not entirely wrong, as TPMs have some general-purpose NVRAM and I've seen one earlier "LUKS TPM" project use it before LUKS2 added the extra header space for tokens. But the systemd implementation doesn't do that, and neither does BitLocker for that matter – they both treat the TPM as mostly read-only; almost all other TPM uses (like "storing" SSH keys) likewise have the host store the protected data. (Partly because the capacity and write endurance of TPM NVRAM are not that high, partly because it has nameless slots and OS cooperation in dualboot is difficult.) Commented Sep 2, 2024 at 11:14
  • Thanks for this @u1686_grawity. I investigated my logs some more (journalctl | grep -i 'systemd-cryptsetup\|tpm and hunted down when the TPM stopped unsealing the root partition. PCR 15 (system-identity) comes up a lot; I'll add some info to my question... Commented Sep 3, 2024 at 8:12
  • Marking your answer as correct as Case #2 kind of covers it. I don't remember specifying PCR 15, though... Commented Sep 3, 2024 at 9:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.