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

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.

Mimi


> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 5cea53fc36df..1cfae4b83dc5 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -1337,5 +1337,9 @@ DEFINE_LSM(ima) = {
>  	.order = LSM_ORDER_LAST,
>  	.blobs = &ima_blob_sizes,
>  	/* Start IMA after the TPM is available */
> +#ifndef CONFIG_IMA_INIT_LATE_SYNC
>  	.initcall_late = init_ima,
> +#else
> +	.initcall_late_sync = init_ima,
> +#endif
>  };