Re: [PATCH] ima: debugging late_initcall_sync measurements

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

On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> 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?
> > 
> > Your question is hypothetical ...
> 
> <heavy eye roll>
> 
> > ... as the TPM isn't deferred, so IMA doesn't go into
> > TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
> > measurement list records.  So moving the initcall to late_initcall_sync would
> > cause a regression.
> 
> Let me rephrase to make the question clear - how do you plan to handle a 
> system where you lose measurements by waiting until late-sync, but the TPM 
> is not available at the late initcall.

There have been suggestions to queue the IMA measurements, but that goes against
the "measure before use" principle. The solution is not to defer IMA
initialization for all systems, but to differentiate the boot_aggregate record
(boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
relative to IMA's initcall.  IMA's job is simply to collect and provide the
measurement list.  Based on the attestation service policy, the attestation
service will decide whether a measurement list containing boot_aggregate_late is
acceptable.

Mimi