Hi Mimi, Le 11/07/2024 à 16:06, Mimi Zohar a écrit : > On Mon, 2024-07-01 at 22:37 -0400, Mimi Zohar wrote: >> Hi Romain, >> >> Please limit the subject line to 70 - 75 characters. >> >> >> On Mon, 2024-07-01 at 16:58 +0200, Romain Naour wrote: >>>>> [1] >>>>> https://lore.kernel.org/linux-integrity/9b98d912-ba78-402c-a5c8-154bef8794f7@xxxxxxxx/ >>>>> [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 <romain.naour@xxxxxxx> >>>> >>>> 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. >> >> 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 >