Re: [PATCH] ima: debugging late_initcall_sync measurements

On Thu, 2026-05-07 at 10:10 +0200, Roberto Sassu wrote:
> On Wed, 2026-05-06 at 22:25 -0400, Mimi Zohar wrote:
> > On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> > > On May 5, 2026 9:57:23 PM Mimi Zohar <[email protected]> wrote:
> > > > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > > > 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?
> > > > 
> > > > 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.
> 
> Agreed on no violation of the measure and load principle.
> 
> But also the two boot_aggregate solution does not work. If there are
> measurements before boot_aggregate_late, they can corrupt the system
> without noticing, and the corrupted system would emit the
> boot_aggregate measurement (non-late) to pass verification.

This is a risk management issue. The conservative option is to continue
initializing IMA only at late_initcall, as we have been doing, and accept the
late TPM initialization limitation. The alternative is to also allow IMA to
initialize at late_initcall_sync, controlled by a Kconfig option, so that
existing systems are unaffected while systems with late TPM initialization can
opt in to boot_aggregate_late support.

Mimi