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
