On Tue, Apr 28, 2026 at 9:21 AM Yeoreum Yun <[email protected]> wrote: > > On Fri, Apr 24, 2026 at 6:49 PM Mimi Zohar <[email protected]> wrote: > > > On Fri, 2026-04-24 at 18:10 -0400, Paul Moore wrote: > > > > (I'm assuming you meant initcall and not syscall above, but if you're > > > > talking about something else, please let me know.) > > > > > > > > Saying that you aren't comfortable moving IMA initialization to > > > > late-sync is inconsistent with allowing IMA initialization to be > > > > deferred to late-sync. Either it is okay to initialize IMA in > > > > late-sync or it isn't. You must pick one. > > > > > > Yes, we're discussing late_initcall and late_initcall_sync. > > > > > > I prefer to look at it as being pragmatic. I'd rather err on the side of > > > caution > > > and not move the syscall to late_initcall_sync, than move it. > > > > If you were truly erring on the side of caution you wouldn't allow > > late-sync initialization without knowing if it was safe or not. > > Determine whether IMA initialization is safe at late-sync. If it is > > safe, move the init to late-sync; if not, keep it at late and figure > > out another mechanism to sync with the TPM availability. If needed, > > you could probably use the LSM notifier to enable the TPM driver to > > signal when it is up and running. > > I don't think LSM notifier wouldn't be good since it a one time > notification for initailisation and it wouldn't tell properly > whehter TPM isn't present in system or present unless functions > ima_init() are rewritten to discern the "TPM deferred" and > "TPM doesn't exist" in the system (e.x) boot-aggregate log creation.
Yes, some work would needed to differentiate between TPM present and TPM absent, the notifier would simply be a mechanism for the TPM driver layer to signal to IMA (and potentially other LSMs if needed?) that the TPM device was initialized and ready. > One question, though. > In the end, for systems where the TPM has already been probed by > late_initcall(), > init_ima() continues to be called at late_initcall(), while the above approach > is introduced for systems where the TPM is not properly initialized by that > point. > > If init_ima(), which used to be called at late_initcall(), > were instead called at late_initcall_sync(), could this break system > integration? > In my view, both late_initcall and late_initcall_sync run during the > do_basic_setup() phase, > so it doesn’t seem like this would cause tampering or affect things like the > creation of the boot-aggregate log. > > Is there any particular reason why init_ima() must be called specifically at > late_initcall()? That is something that you, and the IMA devs need to answer. -- paul-moore.com
