IMA vs TPM (SPI) boot order problems

[Jonathan McDowell <noodles@earth.li>]

I'm seeing an issue with a SPI attached TPM, where it's not coming up 
early enough for IMA to decide there's a TPM available that it can 
measure into. The TPM is definitely present, and by the time we get to 
userspace it's working fine.

This is sort of resurrecting a post from 2024 by Romain, though that 
concerned an i2c TPM:

https://lore.kernel.org/all/9b98d912-ba78-402c-a5c8-154bef8794f7@smile.fr/

There doesn't seem to have actually been a fixed applied, so I tried the 
late_initcall_sync suggestion, but that didn't change things:

[    0.000000] ACPI: TPM2 0x0000004044BCA998 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
[    0.000000] GICv3: 960 SPIs implemented
[    0.000000] GICv3: 320 Extended SPIs implemented
[    0.000447] LSM: initializing lsm=capability,bpf,ima
[    0.394832] Trying to unpack rootfs image as initramfs...
[    0.681134] tegra-qspi NVDA1513:00: Adding to iommu group 1
[    0.681241] tegra-qspi NVDA1513:00: device reset failed
[    0.686925] tpm_tis_spi spi-PRP0001:01: 2.0 TPM (device-id 0x1B, rev-id 22)
[    0.894451] ima: No TPM chip found, activating TPM-bypass!
[    0.894462] ima: Allocated hash algorithm: sha256
[    0.894471] ima: No architecture policies found

This seems to show SPI + the TPM coming up before IMA, but still not in 
a way that makes IMA happy.

Romain, did you solve your issue in some other manner?

J.

-- 
If I want to hear the pitter patter of little feet, I'll put shoes on
my cats.