Suse

Posted Aug 7, 2025 11:07 UTC (Thu) by claudex (subscriber, #92510)
In reply to: Suse by leromarinvit
Parent article: Don't fear the TPM

Do you have some link or documentation about it ? Because for me, it's seem to be a hard requirement for using the TPM to auto unseal Luks partitions and guarantee the security of the platform. Without it, if the system ask me for the unseal key, I don't know if it was tampered with a kernel cmdline modification (for example), or if there was an initrd update before the reboot that I missed. Maybe I missing something but there is no easy way to find out during the boot. (Of course, it is something improbable to be a direct security vulnerability, but it could allow to disable LSM for example).

If we can put the values during the upgrade, that mean that if I have to put Luks passphrase, there is something I should be investigating (or for common users, to signal to the IT team), because it shouldn't happen under normal condition.

Suse

Posted Aug 8, 2025 0:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

It's very obtuse. The TLDR is that you need to use UKIs (Unified Kernel Images) that incorporate the kernel, command line options, and the initrd in one verified binary.

Suse

Posted Aug 13, 2025 7:06 UTC (Wed) by cyphar (subscriber, #110703) [Link] (6 responses)

This feature works using UKIs (Unified Kernel Images), which bundle the UEFI boot stub, kernel image, permitted command-line(s), optionally an initrd, and some other resources. This produces a single PE binary that can be signed as a bundle and verified. The idea is for the UKI to be produced by the vendor of your kernel updates, and because there isn't an initrd that is being re-generated on the users' machine, you therefore can predict the PCR values that will be loaded when booting it -- so when updating the updater can rebind your TPM-sealed LUKS keys to the new PCR values.

This doesn't require changing the PCR values you bind your TPM-sealed keys to (if you already do this today) -- in fact, it allows you to require more PCR values for your LUKS key to be unsealed because more of the boot chain is predictable and it avoids the kinds of attacks you mention.

Suse

Posted Aug 13, 2025 7:55 UTC (Wed) by claudex (subscriber, #92510) [Link] (5 responses)

I don't understand why the UKI is needed. This allow to have a known value. But why can't it work with a classic initrd with the value computed on the host where it is generated ?

Suse

Posted Aug 13, 2025 8:02 UTC (Wed) by leromarinvit (subscriber, #56850) [Link] (3 responses)

This is also how I understand systemd-pcrlock's manpage:

lock-kernel-initrd FILE, unlock-kernel-initrd
Generates/removes a .pcrlock file based on a kernel initrd cpio archive. This is useful for predicting measurements the Linux kernel makes to PCR 9 ("kernel-initrd"). Do not use for systemd-stub(7) UKIs, as the initrd is combined dynamically from various sources and hence does not take a single input, like this command.
This writes/removes the file /var/lib/pcrlock.d/720-kernel-initrd.pcrlock/generated.pcrlock.
Added in version 255.

But like I said, I wasn't able to try it out, so I'm not really qualified to say if it works that way.

Suse

Posted Aug 13, 2025 8:35 UTC (Wed) by claudex (subscriber, #92510) [Link] (2 responses)

Thanks, I didn't know this tool. I'll try it and report my finding if I obtain meaningful result (positive of negative).

Suse

Posted Aug 15, 2025 15:46 UTC (Fri) by claudex (subscriber, #92510) [Link] (1 responses)

I'll understand better the challenge. I have grub on the system where I checked, and this mean that all the parsed config is an event for the PCR8. With things like:

> Raw: grub_cmd: [ xy = xy ]\000
> Raw: grub_cmd: insmod all_video\000
> Raw: grub_cmd: set gfxpayload=keep\000

So it'll be challenging for a program to predict it. However, it should works to script it since I know what should change, so I'll try to predict it for my system. But it can't be easily done without UKI at a distribution level, even with the hash of the initrd.

Suse

Posted Aug 15, 2025 22:24 UTC (Fri) by leromarinvit (subscriber, #56850) [Link]

Yes, GRUB will measure every action it takes, which makes measured boot challenging (see e.g. https://github.com/fedora-silverblue/issue-tracker/issues...). I gather that's at least part of the reason SUSE switched to systemd-boot (for MicroOS at least), which is more predictable in this regard.

Suse

Posted Aug 14, 2025 5:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> I don't understand why the UKI is needed.

It simplifies the checking logic. You just need to verify one binary that has everything and then chainload into it. With classic initrd you also need to measure it (and the kernel cmdline).