On Thu, 2026-04-23 at 18:02 +0100, Jonathan McDowell wrote: > > > > > > > > > > > > I think what Mimi's proposing is: > > > > > > > > > > > > If we're in late_initcall, and the TPM isn't available, return > > > > > > immediately with an error (the EPROBE_DEFER?), don't do any init. > > > > > > > > > > > > If we're in late_initcall_sync, either we're already initialised, > > > > > > so do > > > > > > return and nothing, or run through the entire flow, even if the TPM > > > > > > isn't unavailable. > > > > > > > > > > > > So ima_init() just needs to know a) if it's in the sync or non-sync > > > > > > mode > > > > > > and b) for the sync mode, if we've already done the init at > > > > > > non-sync. > > > > > > > > > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other > > > > > changes > > > > > should not be included in this patch. Since Yeoreum is not hearing > > > > > me, feel > > > > > free to post a patch. > > > > > > > > I see. so what you need to is this only > > > > If it looks good to you. I'll send it at v3. > > > > > > FWIW, I pulled the tpm_default_chip check out a level to account for the > > > extra init you mentioned, and have the following (completely untested or > > > compiled, but gives the approach): > > > > Thanks, Jonathan! It looks good. Similarly untested/compiled. > > FWIW, it does compile. > > > Emitting a message on failure to initialize IMA at late_initcall is good, > > but > > the attestation service won't know. Could you somehow differentiate > > between the > > late_initcall and late_initcall_sync boot_aggregate records? > > Are you thinking "boot_aggregate" and "boot_aggregate_late" or similar > as the "filename" on the entries, just so it's clear when we did the > init in the log, or something else?
Perfect! Mimi
