linux-kernel - [RFC v2 04/20] certs: Create blacklist keyring earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250227030952.2319050-5-alistair@alistair23.me>
Date: Thu, 27 Feb 2025 13:09:36 +1000
From: Alistair Francis <alistair@...stair23.me>
To: linux-cxl@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	lukas@...ner.de,
	linux-pci@...r.kernel.org,
	bhelgaas@...gle.com,
	Jonathan.Cameron@...wei.com,
	rust-for-linux@...r.kernel.org,
	akpm@...ux-foundation.org
Cc: boqun.feng@...il.com,
	bjorn3_gh@...tonmail.com,
	wilfred.mallawa@....com,
	aliceryhl@...gle.com,
	ojeda@...nel.org,
	alistair23@...il.com,
	a.hindborg@...nel.org,
	tmgross@...ch.edu,
	gary@...yguo.net,
	alex.gaynor@...il.com,
	benno.lossin@...ton.me,
	Dan Williams <dan.j.williams@...el.com>,
	Alistair Francis <alistair.francis@....com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Subject: [RFC v2 04/20] certs: Create blacklist keyring earlier

From: Lukas Wunner <lukas@...ner.de>

The upcoming support for PCI device authentication with CMA-SPDM
(PCIe r6.2 sec 6.31) requires parsing X.509 certificates upon
device enumeration, which happens in a subsys_initcall().

Parsing X.509 certificates accesses the blacklist keyring:
x509_cert_parse()
  x509_get_sig_params()
    is_hash_blacklisted()
      keyring_search()

So far the keyring is created much later in a device_initcall().  Avoid
a NULL pointer dereference on access to the keyring by creating it one
initcall level earlier than PCI device enumeration, i.e. in an
arch_initcall().

Signed-off-by: Lukas Wunner <lukas@...ner.de>
Reviewed-by: Dan Williams <dan.j.williams@...el.com>
Reviewed-by: Wilfred Mallawa <wilfred.mallawa@....com>
Reviewed-by: Alistair Francis <alistair.francis@....com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
---
 certs/blacklist.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/certs/blacklist.c b/certs/blacklist.c
index 675dd7a8f07a..34185415d451 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -311,7 +311,7 @@ static int restrict_link_for_blacklist(struct key *dest_keyring,
  * Initialise the blacklist
  *
  * The blacklist_init() function is registered as an initcall via
- * device_initcall().  As a result if the blacklist_init() function fails for
+ * arch_initcall().  As a result if the blacklist_init() function fails for
  * any reason the kernel continues to execute.  While cleanly returning -ENODEV
  * could be acceptable for some non-critical kernel parts, if the blacklist
  * keyring fails to load it defeats the certificate/key based deny list for
@@ -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);
+arch_initcall(blacklist_init);
 
 #ifdef CONFIG_SYSTEM_REVOCATION_LIST
 /*
-- 
2.48.1