IMA vs TPM (SPI) boot order problems

IMA vs TPM (SPI) boot order problems

[Jonathan McDowell]

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.

Re: IMA vs TPM (SPI) boot order problems

[Mimi Zohar]

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/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.

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

Re: IMA vs TPM (SPI) boot order problems

[Jonathan McDowell]

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/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.
>
>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