Hi Mimi,

Le 11/07/2024 à 16:06, Mimi Zohar a écrit :

On Mon, 2024-07-01 at 22:37 -0400, Mimi Zohar wrote:

quoted

Hi Romain,

Please limit the subject line to 70 - 75 characters.


On Mon, 2024-07-01 at 16:58 +0200, Romain Naour wrote:

quoted

quoted

quoted

[1]
https://lore.kernel.org/linux-integrity/9b98d912-ba78-402c-a5c8-154bef8794f7@smile.fr/ (local)
[2]
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1375425/tda4vm-ima-vs-tpm-builtin-driver-boot-order

Signed-off-by: Romain Naour <redacted>

Should this get a Fixes: tag and be also applied to the stable series?

The current behavior can be reproduced on any released kernel (at least since
6.1). But I'm not sure if it should be backported to stable kernels since it
delays the ima/evm initialization at runtime.

With the IMA builtin measurement policy specified on the boot command line
("ima_policy=tcb"), moving init_ima from the late_initcall() to
late_initcall_sync() affects the measurement list order.  It's unlikely, but
possible, that someone is sealing the TPM to PCR-10.  It's probably not a good
idea to backport the change.

An alternative would be to continue using the late_initcall(), but retry on
failure, instead of going directly into TPM-bypass mode.

Indeed, it would be better if the IMA (and EVM) can use something like EPROBE_DEFER.

quoted

As far as I can tell, everything is still being measured and verified, but more
testing is required.

Agree, I'm still evaluating the TPM stack when time allows.

Romain, Paul, another report of IMA going into TPM-bypass mode is here: 
https://github.com/raspberrypi/linux/issues/6217.  Deferring IMA initialization
to late_initcall_sync() did not resolve the problem for them.  Please take a
look at the report.

I don't think that the "mdelay(200)" is really needed when late_initcall_sync()
is used. I guess the issue was the spi driver was not builtin, fixed by:

CONFIG_SPI_DESIGNWARE=y
CONFIG_SPI_DW_MMIO=y

Best regards,
Romain

thanks,

Mimi