Re: [RFC] integrity: wait for completion of i2c initialization using late_initcall_sync()

[Mimi Zohar <zohar@linux.ibm.com>]

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@smile.fr/
> > > > > > [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@skf.com>
> > > > > 
> > > > > 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().

> 
> > > 
> > > 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