> On Fri, 2026-05-08 at 10:06 +0100, Yeoreum Yun wrote:
>
> > > The kernel selftests caused the measurements between late_initcall and
> > > late_initcall_sync. After disabling all of the kernel selftests, there
> > > weren't
> > > any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted
> > > in
> > > measurements. (I didn't try re-enabling any of the other selftests.)
> > >
> > > CONFIG_FIPS_SIGNATURE_SELFTEST=y
> > > CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
> > > CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y
> >
> > Thanks for shraring this ;)
> >
> > I found the reason for those mesaurements. Those come from the
> > request_module() and usermode-thread generates them while handling module
> > loading request for crypto-x962(ecdsa-nist-p256).
> > Since it's not a real kernel module,
> > I confirmed file measurements between late_initcall and
> > late_initcall_sync are gone for modeprobe with below change:
> >
> > @@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
> > */
> > static int ima_kernel_module_request(char *kmod_name)
> > {
> > if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
> > return -EINVAL;
> >
> > + if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
> > + (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
> > + return -EINVAL;
> > +
> > return 0;
> > }
> >
> > Though this is the only request_module() call between
> > late_initcall and late_initcall_sync, but I also confirmed there're
> > request_modules() call before ima initalisation before "late_initcall":
> >
> > /*
> > * NOTE: kmod_name is printed on ima_kernel_module_request()
> > */
> >
> > // This is called from module_init(stm_core_init) -> device_initcall()
> > // which is in driver/hwtracing/stm/core.c (built-in)
> > [ 1.421986] ima: kmod_name: stm_p_basic
> > ...
> > [ 1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
> > [ 1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
> > ...
> > [ 1.452029] ima: kmod_name: crypto-cbc(aes)
> > [ 1.465321] ima: kmod_name: crypto-cbc(aes)-all
> > ...
> > [ 1.467845] Key type encrypted registered
> > [ 1.467848] AppArmor: AppArmor sha256 policy hashing enabled
> >
> > // IMA is initailised at late_initcall level.
> > [ 1.467850] ima: [init_ima_late:1336]
> >
> > If IMA should care request_module() from kernel before IMA init,
> > I think there is no way to solve except queuing those events
> > (kernel_load_data/kernel_load_post_data and open for module binary etc.)
> > though it breaks "measure before use" principle since IMA couldn't
> > measure at that time.
> >
> > But if you don't care about those things -- some events happend before
> > IMA init, I think your suggestion -- controlling the init time of ima_init()
> > via a Kconfig option is good and ignoring some usermodehelper request
> > including request_module() before IMA initialisation upto user by that
> > option.
>
> Thank you for the complete analysis. The early measurements before the TPM is
> initialized is a problem that needs to be addressed. As to whether the
> solution
> will require queueing is yet to be determined. (Roberto has some thoughts on
> addressing it.) This discussion makes it clear that simply delaying IMA
> initialization by moving it from late_initcall to late_initcall_sync could
> miss
> measurements. That said, exposing it as an opt-in Kconfig for those who
> accept
> the risk is a sensible pragmatic compromise.
I think once we address ealry measurements before intialising TPM,
It doesn't matter when IMA is initialissed since they're considered as
ealry measurements anyway.
BTW, I'm not sure whether we should take pragmatic compromise first to
support deferred TPM initialisation or solving it together via solution
of ealry measurements (whatever it is) in now.
--
Sincerely,
Yeoreum Yun
