On Fri, 2026-02-06 at 10:37 +0000, Jonathan McDowell wrote:
> 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.
Here's an example with really well written patch descriptions, that was
upstreamed:
746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to
rootfs_initcall")
Mimi
