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/[email protected]/
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.
