Comment by XorNot

I don't see anything explicit on those pages about solving this problem though?

Like with my current clevis luks setup, which I somewhat random have to regen, I'm bound to PCR 0, 1, 2, 3, 4, 7, 8 and 9.

From https://uapi-group.org/specifications/specs/linux_tpm_pcr_re... that gives me:

0 - Core system firmware executable code

1 - Core system firmware data/host platform configuration; typically contains serial and model numbers

2 - Extended or pluggable executable code; includes option ROMs on pluggable hardware

3 - Extended or pluggable firmware data; includes information about pluggable hardware

4 - Boot loader and additional drivers; binaries and extensions loaded by the boot loader

7 - SecureBoot state

8 - Commands and kernel command line

9 - All files read (including kernel image)

Now the problem is, 8 and 9 I would argue are the most important (since technically 7 probably covers everything else in that list?), whereas my kernel and initrd are not encrypted and my command line can just be edited (but normally wouldn't need to be). But I can't find anyway to get grub, from a booted system, to simulate the output of those values so I can pre-seal the LUKS volume with the new values.

So in practice, I just always need to remember my password (bad) which means there's no way to make a reasonable assessment of system integrity on boot if I get prompted (I'd argue also the UI experience here isn't good: if I'm being prompted for a password, that clevis boot script should output what changed at what level - i.e. if secure boot got turned off, or my UEFI firmware changed on me when I'm staying in a hotel, maybe I shouldn't unlock that disk).