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/[email protected]/ [0] > > Link: > > https://lore.kernel.org/all/[email protected]/ > > [1] > > Suggested-by: Mimi Zohar <[email protected]> > > Reviewed-by: Mimi Zohar <[email protected]> > > Signed-off-by: Yeoreum Yun <[email protected]> > > --- > > 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
