* [QUESTION] move load_uefi_certs() and keyring initcall to earlier initcall
@ 2026-05-14 13:36 Yeoreum Yun
2026-05-20 16:02 ` Yeoreum Yun
0 siblings, 1 reply; 2+ messages in thread
From: Yeoreum Yun @ 2026-05-14 13:36 UTC (permalink / raw)
To: linux-kernel, linux-integrity, keyrings, linux-security-module
Cc: zohar, roberto.sassu, ardb, jarkko, dhowells, dwmw2, serge,
jmorris, paul, sami.mujawar, pierre.gondois
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?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [QUESTION] move load_uefi_certs() and keyring initcall to earlier initcall
2026-05-14 13:36 [QUESTION] move load_uefi_certs() and keyring initcall to earlier initcall Yeoreum Yun
@ 2026-05-20 16:02 ` Yeoreum Yun
0 siblings, 0 replies; 2+ messages in thread
From: Yeoreum Yun @ 2026-05-20 16:02 UTC (permalink / raw)
To: linux-kernel, linux-integrity, keyrings, linux-security-module
Cc: zohar, roberto.sassu, ardb, jarkko, dhowells, dwmw2, serge,
jmorris, paul, sami.mujawar, pierre.gondois
> 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-20 16:02 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-14 13:36 [QUESTION] move load_uefi_certs() and keyring initcall to earlier initcall Yeoreum Yun
2026-05-20 16:02 ` Yeoreum Yun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox