On Thu, 2024-08-01 at 12:12 +0200, Romain Naour wrote:

Hi Mimi,

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

quoted

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.

Yes, "something like EPROBE_DEFER" sounds like the right direction.  Depending
on the environment, the TPM initialization delay might be acceptable and not
introduce an integrity gap.

For now let's start with just late_initcall() and late_initcall_sync().  If the
TPM hasn't been initialized, not all of ima_init() needs to be deferred to
late_initcall_sync().

quoted

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.

quoted

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

Good to know.

thanks,

Mimi