IMA does not detect TPM while using RPi 5

[Mangelmesa]

Describe the bug

IMA seems to not detect the TPM on boot on the RPi 5, and therefore the message "No TPM chip found, activating TPM-bypass!" is displayed. The same building configuration for the kernel and a RPi 4 does not produce the error, and IMA is capable of extending the PCRs of the TPM. Looks like some merged fixes like #5003 do not solve this issue.

Steps to reproduce the behaviour

Modify the Kernel by adding support for the IMA module (using ima-sig as default template and SHA256 as the hash algorithm), set the TPM module as built in: Device Drivers --->Character devices ---> -*- TPM Hardware Support ---> <*> TPM Interface Specification 1.3 Interface / TPM 2.0 FIFO Interface - (SPI), as well as the SPI: Device Drivers --->[*] SPI support ---><*> BCM2835 SPI controller. Build and copy the kernel to the SD card. Add dtparam=spi=on and dtoverlay=tpm-slb9670 to /boot/firmware/config.txt, add ima_policy=tcb to /boot/firmware/cmdline.txt. Finally, add an IMA policy. After a reboot, the expected behavior is to see some value in boot_aggregate given that the TPM is connected. However, all zeroes is obtained in this case, as if it does not exist:

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2024-03-15
OS and version: Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f19ee211ddafcae300827f953d143de92a5c6624, stage5

Firmware version: 30cc5f37 (release) (embedded)

Kernel version: 6.6.31-v8-16k+ #2 SMP PREEMPT Fri Jun 7 10:41:54 CEST 2024 aarch64 GNU/Linux

Logs

Obtained running dmesg | grep IMA and dmesg | grep TPM:
[ 0.397724] ima: No TPM chip found, activating TPM-bypass!
[ 1.970687] systemd[1]: systemd 252.22-1-deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[ 4.445048] tpm_tis_spi spi0.1: 2.0 TPM (device-id 0x1D, rev-id 54)
[ 1.868523] systemd[1]: Successfully loaded the IMA custom policy /etc/ima/ima-policy.
[ 1.970687] systemd[1]: systemd 252.22-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[ 2.416665] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.

Additional context

No response

[ReportedUser]

Hello!
I'm encountering the same problem. Any update?

I'm using LetsTrust TPM and adapted the Infineon remote attestation for RPi 5. I assume it's the same @Mangelmesa followed.
I'm attempting to resolve the issue with information from this thread. Has the problem with the clock that @mimizohar talked about at 14:04 on February 26th, 2019 been solved?

Hi Ard, thank you for responding. The clk not being initialized early enough has been a problem for years. Because of the clk not being initialized, the TPM initialization is deferred, causing IMA to go into TPM-bypass mode.

Thank you in advance, and even if a solution is not provided, direction on what actions can be taken would be greatly appreciated!

[Mangelmesa]

Hello @ReportedUser!
Unfortunately it is still not working for us. We suppose that there may be a problem with the new RP1 chip that controls the GPIO, as it is working without any problems in a RPi4 following the same instructions you mentioned. Other things we've tried during this time:

1. Use a TPM over I2C to see if this one could be initiated earlier but that didn't work either.
2. Also tried using the Ubuntu 24 image that is available for the RPi5, but there is still the TPM Bypass.

Our idea now is to try and delay the loading of the IMA module to try and give some time for the TPM to load properly, but we don't have much hope for it to work. Any help from anyone more versed in the Linux kernel is appreciated.

[mimizohar]

Hi @Mangelmesa, @ReportedUser,

There was a recent request to move the late_initcall(init_ima) to the late_initcall_sync(init_ima). Refer to https://lore.kernel.org/linux-integrity/[email protected]/. Does that solve the problem with IMA going into TPM-bypass mode for you?

To be on the safe side, I suggested trying at late_initcall(init_ima) and on failure trying again on late_initcall_sync(init_ima).

[Mangelmesa]

Hi @mimizohar,

We recompiled the kernel replacing the original late_initcall(init_ima); with late_initcall_sync(init_ima) in the ima_main.c file, as the link you provided suggested. The result is still the same: IMA bypasses the TPM. See the attached image for the diagnostic messages. Thanks for the help, and let's hope we can fix it!

[ReportedUser]

Hello @mimizohar and Mangelmesa!

I've also tried replacing late_initcall(init_ima) with late_initcall_sync(init_ima) in the ima_main with no luck.

Done a different test trying to do a loop (desperation) so it tries again later on, had the same results.

Thanks a lot to both of you for the help and information sharing!

[mimizohar]

I know it's obvious, but could you make sure that the TPM is builtin to the kernel, not as a kernel module.

[ReportedUser]

Don't worry about asking any question!
Most of the times the obvious things are the ones missed.

<*> TPM Interface Specification 1.3 Interface / TPM 2.0 FIFO Interface - (SPI)

Also tried with CONFIG_TCG_TIS=y.

Thanks for your time!

[Mangelmesa]

I've attached the .config file from our RPi5. I suppose that @ReportedUser will have more or less the same configuration that has been based on this documentation. Apart from this configuration now, we've tried using the TPM via I2C but the result is still the same.

[ReportedUser]

Hello @Mangelmesa, @mimizohar !

I believe I've managed to make it work, I'm going to check what change was the one that made it work and I'll give you an update.

Just thought it would be worth notifying you!

[ReportedUser]

Hi! Sorry for the wait,

That's what I tried:

First, followed Infineon remote attestation instructions doing the corresponding changes for the raspberry pi 5.

Then, the changes made so IMA is launched before the TPM were:

Inside .config:
CONFIG_SPI_DESIGNWARE=y
CONFIG_SPI_DW_MMIO=y

Inside security/integrity/ima/ima_main.c added a delay at the beginning of the init_ima function (I believe it could be made with less time) and changed late_initcall(init_ima) to late_initcall_sync(init_ima):

#include <linux/delay.h>

...

static int __init init_ima(void)
{
int error;

mdelay(200);
...
}

late_initcall_sync(init_ima);

Also, as I'm using a LetsTrust TPM I had to add:

{ "attpm20p", (unsigned long)tpm_tis_spi_probe },

To the drivers/char/tpm/tpm_tis_spi_main.c

@Mangelmesa tell me if it works for you!
Also, if @mimizohar believes there is something that could be done better, don't hesitate to tell me and I'll try it!

[Mangelmesa]

Hello @ReportedUser,

Thanks to your instructions it is working as intended now! I've attached a screenshot where it can be seen that IMA is now able to access the TPM and extend the boot_aggregate. I will close this issue now, hope that this is a semi-permanent fix and that it doesn't break in the future. Thanks again for providing your solution :)

[mimizohar]

Hello @ReportedUser, @Mangelmesa,

Thanks to your instructions it is working as intended now! I've attached a screenshot where it can be seen that IMA is now able to access the TPM and extend the boot_aggregate. I will close this issue now, hope that this is a semi-permanent fix and that it doesn't break in the future. Thanks again for providing your solution :)

Thank you for finding a temporary solution.

Mimi

[mimizohar]

Hello @ReportedUser, @Mangelmesa,

As per https://lore.kernel.org/linux-integrity/[email protected]/, please make sure these Kconfig options are builtin:
CONFIG_SPI_DESIGNWARE=y
CONFIG_SPI_DW_MMIO=y