Re: [PATCH] ima: debugging late_initcall_sync measurements

On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <[email protected]> wrote:
> On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <[email protected]> wrote:
> > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > exist, your reply suggests that using an initcall based IMA init
> > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > deferred TPM initialization could happen later, yes?
> > >
> > > Well yeah.  The TPM could be configured as a module, but that scenario is not of
> > > interest.  That's way too late.  The case being addressed in this patch set is
> > > when the TPM driver tries to initialize at device_initcall, returns
> > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > ordering within an initcall is not supported, this patch attempts to initialize
> > > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> >
> > Okay, so from a TPM initialization perspective you are satisfied with
> > a late-sync IMA initialization, yes?
>
> No. On some architectures moving IMA initialization from the late_initcall to
> late_initcall_sync does not miss any measurement records. However, as previously
> mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> records[1].  So no, only if the TPM is not initialized by late_initcall, should
> IMA retry at late_initcall_sync.

What do you do in the PowerVM LPAR when the TPM is not avaiable at
late initcall and you have to defer IMA initialization until
late-sync?

-- 
paul-moore.com