From: Alistair Francis <Alistair.Francis@wdc.com>
To: "dwmw2@infradead.org" <dwmw2@infradead.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"helgaas@kernel.org" <helgaas@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"lukas@wunner.de" <lukas@wunner.de>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>
Cc: "ebiggers@google.com" <ebiggers@google.com>,
"sameo@rivosinc.com" <sameo@rivosinc.com>,
"graf@amazon.com" <graf@amazon.com>,
"jglisse@google.com" <jglisse@google.com>,
"ming4.li@intel.com" <ming4.li@intel.com>,
"gdhanuskodi@nvidia.com" <gdhanuskodi@nvidia.com>,
Wilfred Mallawa <wilfred.mallawa@wdc.com>,
"seanjc@google.com" <seanjc@google.com>,
"ilpo.jarvinen@linux.intel.com" <ilpo.jarvinen@linux.intel.com>,
"jgg@nvidia.com" <jgg@nvidia.com>,
"dlemoal@kernel.org" <dlemoal@kernel.org>,
"david.e.box@intel.com" <david.e.box@intel.com>,
"linuxarm@huawei.com" <linuxarm@huawei.com>,
"dhaval.giani@amd.com" <dhaval.giani@amd.com>,
"aik@amd.com" <aik@amd.com>,
"pgonda@google.com" <pgonda@google.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>
Subject: Re: [PATCH v2 04/18] certs: Create blacklist keyring earlier
Date: Wed, 10 Jul 2024 02:52:59 +0000 [thread overview]
Message-ID: <1ad36e160737794f0f81c386d816e57a7a4b5526.camel@wdc.com> (raw)
In-Reply-To: <8b8a58841c221a85b8e684438237b62d77c7dd69.1719771133.git.lukas@wunner.de>
On Sun, 2024-06-30 at 21:39 +0200, Lukas Wunner wrote:
> 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@wunner.de>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Alistair
> ---
> 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
> /*
next prev parent reply other threads:[~2024-07-10 2:53 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 19:35 [PATCH v2 00/18] PCI device authentication Lukas Wunner
2024-06-30 19:36 ` [PATCH v2 01/18] X.509: Make certificate parser public Lukas Wunner
2024-07-10 2:46 ` Alistair Francis
2024-06-30 19:37 ` [PATCH v2 02/18] X.509: Parse Subject Alternative Name in certificates Lukas Wunner
2024-07-10 2:48 ` Alistair Francis
2024-06-30 19:38 ` [PATCH v2 03/18] X.509: Move certificate length retrieval into new helper Lukas Wunner
2024-07-10 2:49 ` Alistair Francis
2024-07-18 11:04 ` Jonathan Cameron
2024-06-30 19:39 ` [PATCH v2 04/18] certs: Create blacklist keyring earlier Lukas Wunner
2024-07-10 2:52 ` Alistair Francis [this message]
2024-06-30 19:40 ` [PATCH v2 05/18] crypto: akcipher - Support more than one signature encoding Lukas Wunner
2024-06-30 19:41 ` [PATCH v2 06/18] crypto: ecdsa - Support P1363 " Lukas Wunner
2024-06-30 22:10 ` Herbert Xu
2024-07-29 14:27 ` Lukas Wunner
2024-06-30 19:42 ` [PATCH v2 07/18] spdm: Introduce library to authenticate devices Lukas Wunner
2024-06-30 21:29 ` Jeff Johnson
2024-07-08 9:57 ` Alexey Kardashevskiy
2024-07-08 12:54 ` Lukas Wunner
2024-07-09 0:45 ` Alexey Kardashevskiy
2024-07-09 8:49 ` Lukas Wunner
2024-07-09 5:09 ` Dan Williams
2024-07-18 11:42 ` Jonathan Cameron
2024-07-09 15:00 ` Jeff Johnson
2024-07-18 14:24 ` Jonathan Cameron
2024-06-30 19:43 ` [PATCH v2 08/18] PCI/CMA: Authenticate devices on enumeration Lukas Wunner
2024-07-09 18:10 ` Dan Williams
2024-07-09 19:32 ` Lukas Wunner
2024-07-09 23:31 ` Dan Williams
2024-07-11 15:00 ` Lukas Wunner
2024-07-11 17:50 ` Dan Williams
2024-07-12 0:50 ` Damien Le Moal
2024-07-14 8:42 ` Lukas Wunner
2024-07-15 17:21 ` Kees Cook
2024-07-15 18:12 ` Jason Gunthorpe
2024-07-15 20:36 ` Dan Williams
2024-07-15 22:02 ` Jason Gunthorpe
2024-07-15 22:17 ` Damien Le Moal
2024-07-15 23:03 ` Jason Gunthorpe
2024-07-15 23:26 ` Damien Le Moal
2024-07-15 23:42 ` Jason Gunthorpe
2024-07-15 23:57 ` Damien Le Moal
2024-07-16 0:11 ` Jason Gunthorpe
2024-07-16 1:23 ` Dan Williams
2024-07-15 22:50 ` Dan Williams
2024-07-15 23:21 ` Jason Gunthorpe
2024-07-15 23:37 ` Dan Williams
2024-07-15 23:55 ` Jason Gunthorpe
2024-07-16 1:35 ` Dan Williams
2024-07-22 10:19 ` Alexey Kardashevskiy
2024-07-22 12:06 ` Jason Gunthorpe
2024-07-23 4:26 ` Alexey Kardashevskiy
2024-07-23 12:58 ` Jason Gunthorpe
2024-07-15 20:19 ` Dan Williams
2024-07-15 20:08 ` Dan Williams
2024-06-30 19:44 ` [PATCH v2 09/18] PCI/CMA: Validate Subject Alternative Name in certificates Lukas Wunner
2024-07-10 20:35 ` Dan Williams
2024-06-30 19:45 ` [PATCH v2 10/18] PCI/CMA: Reauthenticate devices on reset and resume Lukas Wunner
2024-07-10 3:40 ` Alistair Francis
2024-07-10 23:23 ` Dan Williams
2024-07-18 15:01 ` Jonathan Cameron
2024-06-30 19:46 ` [PATCH v2 11/18] PCI/CMA: Expose in sysfs whether devices are authenticated Lukas Wunner
2024-07-17 23:17 ` Dan Williams
2024-07-18 15:11 ` Jonathan Cameron
2024-06-30 19:47 ` [PATCH v2 12/18] PCI/CMA: Expose certificates in sysfs Lukas Wunner
2024-07-18 2:43 ` Dan Williams
2024-07-18 15:16 ` Jonathan Cameron
2024-07-18 15:19 ` Jonathan Cameron
2024-06-30 19:48 ` [PATCH v2 13/18] sysfs: Allow bin_attributes to be added to groups Lukas Wunner
2024-07-04 10:13 ` Greg Kroah-Hartman
2024-07-12 3:49 ` Alistair Francis
2024-07-18 15:22 ` Jonathan Cameron
2024-06-30 19:49 ` [PATCH v2 14/18] sysfs: Allow symlinks to be added between sibling groups Lukas Wunner
2024-07-04 10:14 ` Greg Kroah-Hartman
2024-07-18 15:36 ` Jonathan Cameron
2024-06-30 19:50 ` [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs Lukas Wunner
2024-07-18 15:56 ` Jonathan Cameron
2024-06-30 19:51 ` [PATCH v2 16/18] spdm: Limit memory consumed by log of received signatures Lukas Wunner
2024-07-18 16:03 ` Jonathan Cameron
2024-06-30 19:52 ` [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain Lukas Wunner
2024-07-18 16:08 ` Jonathan Cameron
2024-06-30 19:53 ` [PATCH v2 18/18] spdm: Allow control of next requester nonce through sysfs Lukas Wunner
2024-07-18 16:11 ` Jonathan Cameron
2024-07-08 9:47 ` [PATCH v2 00/18] PCI device authentication Alexey Kardashevskiy
2024-07-08 13:35 ` Lukas Wunner
2025-02-11 1:30 ` Alexey Kardashevskiy
2025-02-12 16:36 ` Lukas Wunner
2025-05-20 8:35 ` Alexey Kardashevskiy
2025-05-29 5:29 ` Alexey Kardashevskiy
2025-05-29 9:40 ` Lukas Wunner
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=1ad36e160737794f0f81c386d816e57a7a4b5526.camel@wdc.com \
--to=alistair.francis@wdc.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=david.e.box@intel.com \
--cc=dhaval.giani@amd.com \
--cc=dhowells@redhat.com \
--cc=dlemoal@kernel.org \
--cc=dwmw2@infradead.org \
--cc=ebiggers@google.com \
--cc=gdhanuskodi@nvidia.com \
--cc=graf@amazon.com \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jgg@nvidia.com \
--cc=jglisse@google.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lukas@wunner.de \
--cc=ming4.li@intel.com \
--cc=pgonda@google.com \
--cc=sameo@rivosinc.com \
--cc=seanjc@google.com \
--cc=wilfred.mallawa@wdc.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;
as well as URLs for NNTP newsgroup(s).