On Tue, 2024-08-06 at 20:41 -0400, Mimi Zohar wrote: > On Thu, 2024-08-01 at 12:12 +0200, Romain Naour wrote: > > 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. > > 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(). Just a personal opinion. I like the idea of initializing everything as soon as possible, even if there is no TPM. However, in the case where only the kernel image has been measured by the boot loader and one wants measurements with file granularity for the initial ram disk, deferring the TPM PCR extend I think it is not acceptable from the trusted computing point of view. One example would be loading a kernel module while the TPM is still not available, where the kernel module would be able to escape the subsequent measurement later when the TPM becomes available. In this particular case, if there is a measurement policy in place, I would deny any operation matching the policy, until the TPM is available (no defer). If there is really need for allowing something before the TPM is available, I would pass the digest of what it should be allowed by the kernel somehow (e.g. from the boot loader, kernel command line?). In this way, the allowed operations are measured before in the earlier stages of the boot. Roberto > > > > > > > > > > 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 > > Good to know. > > thanks, > > Mimi
