LUKS unlocking with TPM2 broken on 255-rc3

[SoapGentoo]

systemd version the issue has been seen with

255-rc3

Used distribution

Gentoo

Linux kernel version used

6.1.63-gentoo-dist

CPU architectures issue was seen on

x86_64

Component

No response

Expected behaviour you didn't see

Booting my Gentoo installation with systemd 255-rc3 should automatically unlock the LUKS root and swap volumes using the TPM slot.

Unexpected behaviour you saw

1. systemd never unlocks the LUKS volumes using the TPM, instead prompting for the password directly
2. When rebooting, the kernel panics in libsystemd-shared-255.so

Steps to reproduce the problem

• systemd 255-rc3
• LUKS encrypted root and swap (both are discovered using the discoverable partition GUIDs)
• Using dracut for the initrd and UKI (since in 254, ukify would lead to non-bootable systems), commit 856e7ac
• Downgrading to 254.6 and re-generating the initrd/UKI makes everything work again

Let me know what other kind of logs you need

Additional program output to the terminal or log subsystem illustrating the issue

No response

[poettering]

Please provide logs of the failure. Otherwise this is not actionable to us.

[SoapGentoo]

what logs exactly? the initrd stuff from the journal?

[poettering]

ideally debug logs fromt he failing systemd-cryptsetup invocation.

i.e. boot with systemd.log_level=debug on the kernel cmdline to enable debug logs.

[SoapGentoo]

I've truncated the logs to just before the root switch.
debug.log

[thesamesam]

I'm hitting the same. I can bisect albeit a bit painfully if needed.

I still see:

# systemd-cryptenroll --tpm2-device=list
PATH        DEVICE      DRIVER
/dev/tpmrm0 MSFT0101:00 tpm_crb

And if I try re-enroll:

This PCR set is already enrolled, executing no operation.

[poettering]

So you are using the gpt-auto logic for the rootfs?

The cryptsetup invocation is done via:

/usr/bin/systemd-cryptsetup attach root /dev/gpt-auto-root-luks "" tpm2-measure-pcr=yes

i.e. without tpm2-device=auto or similar as switch. Hence it's not surprising the TPM is not queried...

Are you sure this ever worked? I don't see how this could ever have worked.

We probably should imply tpm2-device=auto switch for gpt-auto cryptsetup devices.

[SoapGentoo]

Yes, this works just fine on 254.6, do you want to see the debug logs for this one too?
What command should I put into dracut to test this with cryptsetup?

[poettering]

Yes, this works just fine on 254.6, do you want to see the debug logs for this one too?

yes

[SoapGentoo]

working-254.log

[poettering]

Oh, I think I understand what's going on. It's this commit which changed behaviour here:

00392b1

It will disable unlocking via token modules if measurement of the root volume key is enabled, because we cannot access the volume key if we use token modules...

Previously, since token support was added to the tree it didn't matter whether tpm2/fido2/pkcs11 support was actually configured in our option string, libcryptsetup would behind our backs try to unlock via a token, because we do a wildcard token unlock. With the above we revert to the old behaviour.

You are relying on that behaviour though, so with the commit above your system is broken.