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. Mimi
