init: wait for the TPM before extending PCR 11 - #434

issue #431

Before unsealing a signed TPM2 token bound to PCR 11, booster extends PCR 11 with "enter-initrd". That step opened /dev/tpmrm0 without waiting for it. When the TPM driver is a module and the disk driver is built in (NVMe on most distribution kernels), booster finds the disk before the TPM exists. The extend then fails with "stat /dev/tpmrm0: no such file or directory" and booster falls back to the passphrase prompt.

The same error was fixed for regular TPM2 tokens in 2022, by waiting up to 3 seconds for the tpmrm uevent at the start of the unseal. The PCR 11 extend was added later and runs before the unseal, so it never got that wait.

Changes:

• Wait for the TPM once, at the start of systemd-tpm2 token handling. The wait covers the PCR 11 extend and both unseal paths, and runs before the PIN prompt. If no TPM appears, the token fails there without asking for a PIN.
• Skip the wait when /dev/tpmrm0 already exists. A built-in driver creates the device before booster listens for uevents, so the event never arrives and every TPM2 unlock waited out the full 3 seconds. A 2023 report bisected this stall to the 2022 change.

Testing:

• TestSystemdTPM2SignedPolicyModularTPM boots the Void Linux test kernel, which builds tpm_tis as a module and NVMe in, with the disk on NVMe. It stops at the passphrase prompt on master and unlocks with this branch. A virtio-scsi disk does not reproduce the bug, because its driver loads at the same time as tpm_tis.
• Two unit tests run the token handler against swtpm. One starts the TPM late and checks that PCR 11 was extended. The other never starts it and checks that the token fails before a PIN prompt. The existing TPM2, clevis TPM and crypttab integration tests pass, and their logs no longer show "no tpm devices found after 3 seconds".