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

On Thu, 2026-04-23 at 18:02 +0100, Jonathan McDowell wrote:
> > > > > > 
> > > > > > 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):
> > 
> > Thanks, Jonathan!  It looks good.  Similarly untested/compiled.
> 
> FWIW, it does compile.
> 
> > Emitting a message on failure to initialize IMA at late_initcall is good, but
> > the attestation service won't know.  Could you somehow differentiate between the
> > late_initcall and late_initcall_sync boot_aggregate records?
> 
> Are you thinking "boot_aggregate" and "boot_aggregate_late" or similar 
> as the "filename" on the entries, just so it's clear when we did the 
> init in the log, or something else?

Perfect!

Mimi