On Fri, Feb 06, 2026 at 10:36:36AM -0500, Mimi Zohar wrote:
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")
Thanks Mimi, really useful pointers. I think the TPM/SPI chain is a
little bit more tricky (I guess I can just fix the path that works for
me, rather than *any* SPI bus driver), but I'll investigate.
J.
--
Shall I call the United Nations?
This .sig brought to you by the letter W and the number 30
Product of the Republic of HuggieTag
