Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, hch@lst.de,
	gregkh@linuxfoundation.org, graf@amazon.com, lukas@wunner.de,
	wufan@linux.microsoft.com, brauner@kernel.org,
	jsperbeck@google.com, ardb@kernel.org,
	linux-crypto@vger.kernel.org, linux-kbuild@vger.kernel.org,
	keyrings@vger.kernel.org, Jeremy Linton <jeremy.linton@arm.com>
Subject: [RFC 2/5] KEYS/certs: Start the builtin key and cert system earlier
Date: Tue, 15 Oct 2024 17:22:32 -0500	[thread overview]
Message-ID: <20241015222235.71040-3-jeremy.linton@arm.com> (raw)
In-Reply-To: <20241015222235.71040-1-jeremy.linton@arm.com>

This exists at the moment to assure that the module signature checking
logic can be utilized before the initramfs is mounted.

Assuming we want to use the built in keys as well as MOK's to validate
an init image, is just moving this stuff earlier in the boot process
the right choice?

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
 certs/blacklist.c                        | 2 +-
 certs/system_keyring.c                   | 4 ++--
 crypto/asymmetric_keys/asymmetric_type.c | 2 +-
 crypto/asymmetric_keys/x509_public_key.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/certs/blacklist.c b/certs/blacklist.c
index 675dd7a8f07a..e644dd4cfc2b 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -356,7 +356,7 @@ static int __init blacklist_init(void)
 /*
  * Must be initialised before we try and load the keys into the keyring.
  */
-device_initcall(blacklist_init);
+fs_initcall(blacklist_init);
 
 #ifdef CONFIG_SYSTEM_REVOCATION_LIST
 /*
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 9de610bf1f4b..81a86418cb00 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -260,7 +260,7 @@ static __init int system_trusted_keyring_init(void)
 /*
  * Must be initialised before we try and load the keys into the keyring.
  */
-device_initcall(system_trusted_keyring_init);
+subsys_initcall(system_trusted_keyring_init);
 
 __init int load_module_cert(struct key *keyring)
 {
@@ -293,7 +293,7 @@ static __init int load_system_certificate_list(void)
 
 	return x509_load_certificate_list(p, size, builtin_trusted_keys);
 }
-late_initcall(load_system_certificate_list);
+fs_initcall_sync(load_system_certificate_list);
 
 #ifdef CONFIG_SYSTEM_DATA_VERIFICATION
 
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 43af5fa510c0..a0607e8cdafc 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -681,5 +681,5 @@ static void __exit asymmetric_key_cleanup(void)
 	unregister_key_type(&key_type_asymmetric);
 }
 
-module_init(asymmetric_key_init);
+subsys_initcall(asymmetric_key_init);
 module_exit(asymmetric_key_cleanup);
diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index 8409d7d36cb4..391db5f1ede6 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -246,7 +246,7 @@ static void __exit x509_key_exit(void)
 	unregister_asymmetric_key_parser(&x509_key_parser);
 }
 
-module_init(x509_key_init);
+fs_initcall(x509_key_init);
 module_exit(x509_key_exit);
 
 MODULE_DESCRIPTION("X.509 certificate parser");
-- 
2.46.0


  parent reply	other threads:[~2024-10-15 22:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15 22:22 [RFC 0/5] Another initramfs signature checking set Jeremy Linton
2024-10-15 22:22 ` [RFC 1/5] initramfs: Add initramfs signature checking Jeremy Linton
2024-10-15 22:22 ` Jeremy Linton [this message]
2024-10-15 22:22 ` [RFC 3/5] initramfs: Use existing module signing infrastructure Jeremy Linton
2024-10-15 22:22 ` [RFC 4/5] sign-file: Add -i option to sign initramfs images Jeremy Linton
2024-10-15 22:22 ` [RFC 5/5] initramfs: Enforce initramfs signature Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241015222235.71040-3-jeremy.linton@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=brauner@kernel.org \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jsperbeck@google.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=wufan@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox