Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM

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

On Thu, 2026-04-23 at 15:33 +0100, Yeoreum Yun wrote:
> Hi Jonathan,
> 
> > * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links or attachments. *
> > On Thu, Apr 23, 2026 at 02:55:14PM +0100, Yeoreum Yun wrote:
> > > > On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> > > > > On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > > > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > > > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > > Hi Mimi,
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Wed, 2026-04-22 at 17:24 +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.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > > > > > > > > log though TPM device presents in the system.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > > > > > > > > 
> > > > > > > > > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > > > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > > > > > > > > changes (e.g. ima_init_core).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Please just limit the change to just calling ima_init() twice.
> > > > > > > > > > > > 
> > > > > > > > > > > > My concern is that ima_update_policy_flags() will be called
> > > > > > > > > > > > when ima_init() is deferred -- not initialised anything.
> > > > > > > > > > > > though functionally, it might be okay however,
> > > > > > > > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > > > > > > > > works logically.
> > > > > > > > > > > > 
> > > > > > > > > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > > > > > > > > ima_init_core() with some error handling.
> > > > > > > > > > > > 
> > > > > > > > > > > > Am I missing something?
> > > > > > > > > > > 
> > > > > > > > > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > > > > > > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > > > > > > > > > 
> > > > > > > > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > > > > > > > > it by caller of ima_init().
> > > > > > > > > > 
> > > > > > > > > > Only tpm_default_chip() is being called to set the ima_tpm_chip.  On failure,
> > > > > > > > > > instead of going into TPM-bypass mode, return immediately.  There are no calls
> > > > > > > > > > to anything else.  Just call ima_init() a second time.
> > > > > > > > > 
> > > > > > > > > I’m not fully convinced this is sufficient.
> > > > > > > > > 
> > > > > > > > > What I meant is the case where ima_init() fails due to other
> > > > > > > > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
> > > > > > > > 
> > > > > > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > > > > > available at late_initcall.  This would be classified as a bug fix and would be
> > > > > > > > backported.  No other changes should be included in this patch.
> > > > > > > 
> > > > > > > Okay.
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > I’d also like to ask again whether it is fine to call
> > > > > > > > > ima_update_policy_flags() and keep the notifier registered in the
> > > > > > > > > deferred TPM case. While this may be functionally acceptable, it seems
> > > > > > > > > logically questionable to do so when ima_init() has not completed.
> > > > > > > > 
> > > > > > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > > > > > is a TPM or goes into TPM-bypass mode.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > There is also a possibility that a deferred case ultimately fails (e.g.
> > > > > > > > > deferred at late_initcall, but then failing at late_initcall_sync
> > > > > > > > > for another reason, even while entering TPM bypass mode). In that case,
> > > > > > > > > it seems more appropriate to handle this state in the caller of
> > > > > > > > > ima_init(), rather than inside ima_init() itself.
> > > > > > > > 
> > > > > > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > > > > > bypass mode.  Please don't make any other changes to the existing IMA behavior
> > > > > > > > and hide it here behind the late_initcall_sync change.
> > > > > > > 
> > > > > > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > > > > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > > > > > get failed with "TPM-bypass mode".
> > > > > > > 
> > > > > > > I see then, I'll make a patch simpler then.
> > > > > > 
> > > > > > But I think in case of below situation:
> > > > > >  - late_initcall's first ima_init() is deferred.
> > > > > >  - late_initcall_sync try again but failed and try again with
> > > > > >    CONFIG_IMA_DEFAULT_HASH.
> > > > > > 
> > > > > > I would like to sustain init_ima_core to reduce the same code repeat
> > > > > > in late_initcall_sync.
> > > > > 
> > > > > I think what Mimi's proposing is:
> > > > > 
> > > > > If we're in late_initcall, and the TPM isn't available, return
> > > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > > > 
> > > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > > return and nothing, or run through the entire flow, even if the TPM
> > > > > isn't unavailable.
> > > > > 
> > > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > > and b) for the sync mode, if we've already done the init at
> > > > > non-sync.
> > > > 
> > > > Thanks, Jonathan.  That is exactly what I'm suggesting.  Any other changes
> > > > should not be included in this patch.  Since Yeoreum is not hearing me, feel
> > > > free to post a patch.
> > > 
> > > I see. so what you need to is this only
> > > If it looks good to you. I'll send it at v3.
> > 
> > FWIW, I pulled the tpm_default_chip check out a level to account for the
> > extra init you mentioned, and have the following (completely untested or
> > compiled, but gives the approach):
> > 
> > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > index d48bf0ad26f4..88fe105b7f00 100644
> > --- a/include/linux/lsm_hooks.h
> > +++ b/include/linux/lsm_hooks.h
> > @@ -166,6 +166,7 @@ enum lsm_order {
> >   * @initcall_fs: LSM callback for fs_initcall setup, optional
> >   * @initcall_device: LSM callback for device_initcall() setup, optional
> >   * @initcall_late: LSM callback for late_initcall() setup, optional
> > + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> >   */
> >  struct lsm_info {
> >  	const struct lsm_id *id;
> > @@ -181,6 +182,7 @@ struct lsm_info {
> >  	int (*initcall_fs)(void);
> >  	int (*initcall_device)(void);
> >  	int (*initcall_late)(void);
> > +	int (*initcall_late_sync)(void);
> >  };
> >  #define DEFINE_LSM(lsm)							\
> > diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> > index a2f34f2d8ad7..a60dfb8316d8 100644
> > --- a/security/integrity/ima/ima_init.c
> > +++ b/security/integrity/ima/ima_init.c
> > @@ -119,10 +119,6 @@ int __init ima_init(void)
> >  {
> >  	int rc;
> > -	ima_tpm_chip = tpm_default_chip();
> > -	if (!ima_tpm_chip)
> > -		pr_info("No TPM chip found, activating TPM-bypass!\n");
> > -
> >  	rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> >  	if (rc)
> >  		return rc;
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index 1d6229b156fb..b60a85fa803a 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
> >  #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> > -static int __init init_ima(void)
> > +static int __init init_ima(bool sync)
> >  {
> >  	int error;
> > @@ -1247,6 +1247,19 @@ static int __init init_ima(void)
> >  		return 0;
> >  	}
> > +	/* If we found the TPM during our first attempt, nothing further to do */
> > +	if (sync && ima_tpm_chip)
> > +		return 0;
> > +
> > +	ima_tpm_chip = tpm_default_chip();
> > +	if (!ima_tpm_chip && !sync) {
> > +		pr_debug("TPM not available, will try later\n");
> > +		return -EPROBE_DEFER;
> > +	}
> > +
> > +	if (!ima_tpm_chip)
> > +		pr_info("No TPM chip found, activating TPM-bypass!\n");
> > +
> >  	ima_appraise_parse_cmdline();
> >  	ima_init_template_list();
> >  	hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > @@ -1274,6 +1287,16 @@ static int __init init_ima(void)
> >  	return error;
> >  }
> > +static int __init init_ima_late(void)
> > +{
> > +	return init_ima(false);
> > +}
> > +
> > +static int __init init_ima_late_sync(void)
> > +{
> > +	return init_ima(true);
> > +}
> > +
> >  static struct security_hook_list ima_hooks[] __ro_after_init = {
> >  	LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> >  	LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> > @@ -1319,6 +1342,7 @@ DEFINE_LSM(ima) = {
> >  	.init = init_ima_lsm,
> >  	.order = LSM_ORDER_LAST,
> >  	.blobs = &ima_blob_sizes,
> > -	/* Start IMA after the TPM is available */
> > -	.initcall_late = init_ima,
> > +	/* Ensure we start IMA after the TPM is available */
> > +	.initcall_late = init_ima_late,
> > +	.initcall_late_sync = init_ima_late_sync,
> >  };
> > diff --git a/security/lsm_init.c b/security/lsm_init.c
> > index 573e2a7250c4..4e5c59beb82a 100644
> > --- a/security/lsm_init.c
> > +++ b/security/lsm_init.c
> > @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> >   * security_initcall_late - Run the LSM late initcalls
> >   */
> >  static int __init security_initcall_late(void)
> > +{
> > +	return lsm_initcall(late);
> > +}
> > +late_initcall(security_initcall_late);
> > +
> > +/**
> > + * security_initcall_late_sync - Run the LSM late initcalls sync
> > + */
> > +static int __init security_initcall_late_sync(void)
> >  {
> >  	int rc;
> > -	rc = lsm_initcall(late);
> > +	rc = lsm_initcall(late_sync);
> >  	lsm_pr_dbg("all enabled LSMs fully activated\n");
> >  	call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
> >  	return rc;
> >  }
> > -late_initcall(security_initcall_late);
> > +late_initcall_sync(security_initcall_late_sync);
> 
> I'm fine this. but are we talking about "ima_init()" not "init_ima()"?

Having two functions named ima_init() and init_ima() is really confusing.  At
least with this patch, init_ima() will be replaced with init_ima_late() and
init_ima_sync().

> Because of this, I've fixuated and make a long stupid speaking myself.

The commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init()
to rootfs_initcall") patch description was really well written.  I'm really sad
that it needs to be reverted.

The TPM not being initialized before IMA, has been an issue for a really long
time.  Hopefully this patch will safely fix it, not only for you, but for others
as well.

> 
> If this seems good to Mimi, I don't care who send it.
> But If you're going to send this, could you includes 2 and 3 too?

Once this patch is ready, we can create a topic branch to coordinate upstreaming
the remaining patches.

thanks!

Mimi