> Hi all,
>
> Recently, I've found possible module load failure via
> request_module() in device_initcall() for absent of certificate loaded by
> load_uefi_certs() in below exemplary case:
>
> - MokListTrustedRT is created.
> - one module is signed with trust-chain with one cert of MokListRT and
> contained in initramfs.
> - loading the above module in device_initcall() get failure since
> relavent certs didn't loaded yet -- load_uefi_certs() is called at
> late_inicall()
>
> I don't think calling request_module() in the initcall is not a problem
> if it's after root_initcall (from device_initcall) where initrd
> population is requested when I see the commit e7cb072eb988
> ("init/initramfs.c: do unpacking asynchronously").
>
> IOW, to address this -- signature verification failure for late loading
> of certificates, It seems to movce load_uefi_certs() or other relevant
> init functions requires to move to "rootfs_initcall()".
>
> Unfortunately, Moving the load_uefi_certs() doesn't seems easy because
> keyring infrastructure is initailised at device_initcall() via
> relevant init functions.
>
> So, I would like to introduce two initcalls macro which using pre-exist
> initcall macro to address above situation --
>
> - keyring_initcall() (which is wrapper of subsys_initcall()).
> - cert_initcall() (which is wrapper of rootfs_initcall()).
>
> so that for init functions which initalise keyring infrastructure,
> for example, the function where calls keyring_alloc() like:
> - system_trusted_keyring_init()
> - blacklist_init()
> - machine_keyring_init()
> - platform_keyring_init()
> - ima_mok_init()
>
> to be replaced from device_initcall() to subsys_initcall() with
> keyring_initcall()
>
> and for functions which load certificates or late init relevant keyring
> like:
> - load_system_certificate_list()
> - load_uefi_certs()
> - load_powerpc_certs()
> - load_ipl_certs()
> - big_key_init()
> - init_root_keyring()
> - init_trusted()
> - init_encrypted()
>
> to be called from late_initcall() to rootfs_initcall() with cert_initcall().
>
> Am I missing something, or is there perhaps a better idea?
>
I'd appreciate it if someone could let me know whether I might be
missing something.
Thanks!
--
Sincerely,
Yeoreum Yun