On Fri, 2026-04-24 at 17:08 -0400, Paul Moore wrote: > On Fri, Apr 24, 2026 at 4:58 PM Mimi Zohar <[email protected]> wrote: > > On Fri, 2026-04-24 at 16:15 -0400, Paul Moore wrote: > > > On Fri, Apr 24, 2026 at 1:57 AM Yeoreum Yun <[email protected]> wrote: > > > > > On Thu, Apr 23, 2026 at 2:13 PM Yeoreum Yun <[email protected]> > > > > > wrote: > > > > > > > > > > > > Sounds good. Once the patch is posted, I’ll review it as well. > > > > > > Sorry again for the noise, and thanks for your patience ;) > > > > > > > > > > My apologies for not getting a chance to look at this patchset sooner. > > > > > > > > > > This seems like an obvious, perhaps even stupid, question, but I have > > > > > to ask: if IMA can be properly initialized via late_initcall_sync(), > > > > > why not simply do the initialization in late_initcall_sync() and drop > > > > > the late_initcall() initialization? > > > > > > > > > > Does any IMA functionality suffer if initialization waits until > > > > > late_initcall_sync()? If so, it seems non-critical if waiting until > > > > > _sync() is acceptable, as it appears in these patches/comments. > > > > > > > > This is the way first patch did, and here is some discussion for this > > > > (Might you have seen, but in case of you missed): > > > > - > > > > https://lore.kernel.org/all/[email protected]/ > > > > > > Thanks for the pointer. > > > > > > Unfortunately, my concern remains the same: it's either "safe" to > > > initialize IMA at late_initcall_sync() or it isn't. Attempting to > > > initialize IMA twice seems both odd and wrong. > > > > Agreed. However, IMA should be initialized as soon as the TPM becomes > > available, not delayed. > > > > In patch 2/4 patch description, Jonathan describes the reasoning: > > > > Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM > > devices) are not reliably available during the initcall_late stage, > > resulting in a log error: > > > > ima: No TPM chip found, activating TPM-bypass! > > > > and no measurements into the TPM by IMA. We can avoid this by doing IMA > > init in the initcall_late_sync stage, after the drivers have completed > > their init + registration. > > > > Rather than do this everywhere, and needlessly delay the initialisation > > of IMA when there is no need to do so, we continue to try to initialise > > at the earlier stage, only deferring to the later point if the TPM is > > not available yet. > > Once again, that heavily implies that it is safe to initialize IMA in > late-sync. > > Put another way, what breaks if IMA's initialization is delayed to > late-sync? If the answer is nothing, just move the initialization to > late-sync. However, if something *is* broken and we are just doing > this because of TPM delays at boot, this patchset just creates > additional problems and we need a different solution. I can't > envision a scenario where it makes sense to attempt initialization > twice. > > > > I understand the need to ensure that the TPM is available, but if it > > > isn't safe to wait to initialize IMA at late_initcall_sync() then it > > > would seem like this is a bad option and we need another mechanism to > > > synchronize IMA with TPM devices. If it is safe to initalize IMA in > > > late_initcall_sync(), just do that and be done with it. > > > > Within the same initcall level there is no way of ordering the > > initialization. > > Yeorum attempted to address the ordering issue in commit 0e0546eabcd6 > > ("firmware: arm_ffa: Change initcall level of ffa_init() to > > rootfs_initcall"), > > which is being reverted in this patch set. > > > > Ordering within an initcall level needs to be fixed, but for now retrying at > > late_initcall_sync works for some, hopefully most, cases. > > That's not a good answer. Ignoring the TPM issue for a moment, can > you confirm that moving IMA's initialization to late-sync is safe? If > not, why is this approach being considered?
I'm not seeing any measurements between late_initcall and late_initcall_sync. Based on this very limited testing, I don't feel comfortable to actually move the syscall, but can see adding support to allow IMA initialization to be deferred. Mimi
