Re: [PATCH v6 2/4] security: ima: introduce IMA_INIT_LATE_SYNC option

[Yeoreum Yun <yeoreum.yun@arm.com>]

On Mon, Jun 08, 2026 at 01:40:00PM -0400, Mimi Zohar wrote:
> On Fri, 2026-06-05 at 15:43 +0100, Yeoreum Yun wrote:
> > To generate the boot_aggregate log in the IMA subsystem with
> > TPM PCR values, the TPM driver must be built as built-in and
> > must be probed before the IMA subsystem is initialized.
> > 
> > However, when the TPM device operates over the FF-A protocol using
> > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > the tpm_crb_ffa device — an FF-A device that provides the communication
> > interface to the tpm_crb driver — has not yet been probed.
> > 
> > To ensure the TPM device operating over the FF-A protocol with
> > the CRB interface is probed before IMA initialization,
> > the following conditions must be met:
> > 
> > 1. The corresponding ffa_device must be registered,
> >    which is done via ffa_init().
> > 
> > 2. The tpm_crb_driver must successfully probe this device via
> >    tpm_crb_ffa_init().
> > 
> > 3. The tpm_crb driver using CRB over FF-A can then
> >    be probed successfully. (See crb_acpi_add() and
> >    tpm_crb_ffa_init() for reference.)
> > 
> > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init()
> > are all registered with device_initcall, which means
> > crb_acpi_driver_init() may be invoked before ffa_init() and
> > tpm_crb_ffa_init() are completed.
> > 
> > When this occurs, probing the TPM device is deferred.
> > However, the deferred probe can happen after the IMA subsystem
> > has already been initialized, since IMA initialization is performed
> > during late_initcall, and deferred_probe_initcall() is performed
> > at the same level.
> > 
> > And the similar situation is reported on TPM devices attached on SPI
> > bus[0].
> > 
> > To resolve this, introduce IMA_INIT_LATE_SYNC option to initialise
> > IMA at late_inicall_sync so that IMA is initialized with the TPM
> > device probed deferred.
> > 
> > When this option is enabled, modules that access files in the
> > initramfs through usermode helper calls such as request_module()
> > during initcall must not be built-in. Otherwise, IMA may miss
> > measuring those files [1].
> > 
> > Link: https://lore.kernel.org/all/aYXEepLhUouN5f99@earth.li/ [0]
> > Link: https://lore.kernel.org/all/2b3782398cc17ce9d355490a0c42ebce9120a9ae.camel@linux.ibm.com/ [1]
> > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> >  security/integrity/ima/Kconfig    | 10 ++++++++++
> >  security/integrity/ima/ima_main.c |  4 ++++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 862fbee2b174..75f71401fba3 100644
> > --- a/security/integrity/ima/Kconfig
> > +++ b/security/integrity/ima/Kconfig
> > @@ -332,4 +332,14 @@ config IMA_KEXEC_EXTRA_MEMORY_KB
> >  	  If set to the default value of 0, an extra half page of memory for those
> >  	  additional measurements will be allocated.
> >  
> > +config IMA_INIT_LATE_SYNC
> > +	bool "Initialise IMA at late_initcall_sync"
> > +	default n
> > +	help
> > +	  This option initialises IMA at late_initcall_sync for platforms
> > +	  where TPM device probing is deferred.
> > +	  When this option is enabled, modules that access files in the
> > +	  initramfs through usermode helper calls such as request_module()
> > +	  during initcall must not be built-in. Otherwise, IMA may miss
> > +	  file measurements for them.
> >  endif
> 
> I fixed the merge conflict with the "ima: Exporting and deleting IMA measurement
> records from kernel memory" patch set.  These patches are now queued in next-
> integrity-testing awaiting Paul's Ack.

Thanks!

[...]

-- 
Sincerely,
Yeoreum Yun