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. 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. I'm also guessing a two stage init process, e.g. some in late_initcall() and some in late_initcall_sync(), doesn't make much sense here, but that could be one other thing to consider if some IMA tasks must be done in late_initcall(). -- paul-moore.com
