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