From: Alistair Francis <Alistair.Francis@wdc.com>
To: "dwmw2@infradead.org" <dwmw2@infradead.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"helgaas@kernel.org" <helgaas@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"lukas@wunner.de" <lukas@wunner.de>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>
Cc: "zhi.a.wang@intel.com" <zhi.a.wang@intel.com>,
"linuxarm@huawei.com" <linuxarm@huawei.com>,
"dave.jiang@intel.com" <dave.jiang@intel.com>,
"aik@amd.com" <aik@amd.com>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
"ming4.li@intel.com" <ming4.li@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"david.e.box@intel.com" <david.e.box@intel.com>,
Wilfred Mallawa <wilfred.mallawa@wdc.com>,
"seanjc@google.com" <seanjc@google.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"graf@amazon.com" <graf@amazon.com>
Subject: Re: [PATCH 04/12] certs: Create blacklist keyring earlier
Date: Thu, 12 Oct 2023 02:20:22 +0000 [thread overview]
Message-ID: <df8c403791a588b97188bf0465426a270e3a4e6c.camel@wdc.com> (raw)
In-Reply-To: <3db7a8856833dfcbc4b122301f233828379d67db.1695921657.git.lukas@wunner.de>
On Thu, 2023-09-28 at 19:32 +0200, Lukas Wunner wrote:
> The upcoming support for PCI device authentication with CMA-SPDM
> (PCIe r6.1 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: 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:[~2023-10-12 2:20 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 17:32 [PATCH 00/12] PCI device authentication Lukas Wunner
2023-09-28 17:32 ` [PATCH 01/12] X.509: Make certificate parser public Lukas Wunner
2023-10-03 7:57 ` Ilpo Järvinen
2023-10-03 15:13 ` Jonathan Cameron
2023-10-06 18:47 ` Dan Williams
2023-09-28 17:32 ` [PATCH 04/12] certs: Create blacklist keyring earlier Lukas Wunner
2023-10-03 8:37 ` Ilpo Järvinen
2023-10-03 22:53 ` Wilfred Mallawa
2023-10-03 9:10 ` Jonathan Cameron
2023-10-06 19:19 ` Dan Williams
2023-10-12 2:20 ` Alistair Francis [this message]
2023-09-28 17:32 ` [PATCH 03/12] X.509: Move certificate length retrieval into new helper Lukas Wunner
2023-10-02 16:44 ` Jonathan Cameron
2023-10-03 8:31 ` Ilpo Järvinen
2023-10-06 19:15 ` Dan Williams
2024-03-04 6:57 ` Lukas Wunner
2024-03-04 19:19 ` Dan Williams
2023-09-28 17:32 ` [PATCH 02/12] X.509: Parse Subject Alternative Name in certificates Lukas Wunner
2023-10-03 8:31 ` Ilpo Järvinen
2023-10-03 22:52 ` Wilfred Mallawa
2023-10-03 15:14 ` Jonathan Cameron
2023-10-06 19:09 ` Dan Williams
2023-09-28 17:32 ` [PATCH 05/12] crypto: akcipher - Support more than one signature encoding Lukas Wunner
2023-10-02 16:59 ` Jonathan Cameron
2023-10-06 19:23 ` Dan Williams
2023-10-07 14:46 ` Lukas Wunner
2023-09-28 17:32 ` [PATCH 06/12] crypto: ecdsa - Support P1363 " Lukas Wunner
2023-10-02 16:57 ` Jonathan Cameron
2023-09-28 17:32 ` [PATCH 07/12] spdm: Introduce library to authenticate devices Lukas Wunner
2023-10-03 10:35 ` Ilpo Järvinen
2024-02-09 20:32 ` Lukas Wunner
2024-02-12 11:47 ` Ilpo Järvinen
2024-03-20 8:33 ` Lukas Wunner
2023-10-03 14:39 ` Jonathan Cameron
2023-10-12 3:26 ` Alistair Francis
2023-10-12 4:37 ` Damien Le Moal
2023-10-12 7:16 ` Lukas Wunner
2023-10-12 15:09 ` Jonathan Cameron
2024-02-04 17:25 ` Lukas Wunner
2024-02-05 10:07 ` Jonathan Cameron
2023-10-06 20:34 ` Dan Williams
2023-09-28 17:32 ` [PATCH 08/12] PCI/CMA: Authenticate devices on enumeration Lukas Wunner
2023-10-03 14:47 ` Jonathan Cameron
2023-10-05 20:10 ` Bjorn Helgaas
2023-09-28 17:32 ` [PATCH 09/12] PCI/CMA: Validate Subject Alternative Name in certificates Lukas Wunner
2023-10-03 15:04 ` Jonathan Cameron
2023-10-05 14:04 ` Lukas Wunner
2023-10-05 20:09 ` Bjorn Helgaas
2023-09-28 17:32 ` [PATCH 10/12] PCI/CMA: Reauthenticate devices on reset and resume Lukas Wunner
2023-10-03 15:10 ` Jonathan Cameron
2023-09-28 17:32 ` [PATCH 11/12] PCI/CMA: Expose in sysfs whether devices are authenticated Lukas Wunner
2023-10-03 9:04 ` Ilpo Järvinen
2023-10-03 15:28 ` Jonathan Cameron
2023-10-05 20:20 ` Bjorn Helgaas
2023-09-28 17:32 ` [PATCH 12/12] PCI/CMA: Grant guests exclusive control of authentication Lukas Wunner
2023-10-03 9:12 ` Ilpo Järvinen
2023-10-03 15:40 ` Jonathan Cameron
2023-10-03 19:30 ` Lukas Wunner
2023-10-05 20:34 ` Bjorn Helgaas
2023-10-06 9:30 ` Jonathan Cameron
2023-10-18 19:58 ` Dan Williams
2023-10-19 7:58 ` Alexey Kardashevskiy
2023-10-24 17:04 ` Dan Williams
2023-10-09 10:52 ` Alexey Kardashevskiy
2023-10-09 14:02 ` Lukas Wunner
2023-10-06 16:06 ` [PATCH 00/12] PCI device authentication Dan Williams
2023-10-07 10:04 ` Lukas Wunner
2023-10-09 11:33 ` Jonathan Cameron
2023-10-09 13:49 ` Lukas Wunner
2023-10-10 4:07 ` Alexey Kardashevskiy
2023-10-10 8:19 ` Lukas Wunner
2023-10-10 12:53 ` Alexey Kardashevskiy
2023-10-11 16:57 ` Jonathan Cameron
2023-10-12 3:00 ` Alexey Kardashevskiy
2023-10-12 15:15 ` Jonathan Cameron
2023-10-11 16:42 ` Jonathan Cameron
2023-10-12 9:15 ` Lukas Wunner
2023-10-12 11:18 ` Alexey Kardashevskiy
2023-10-12 15:25 ` Jonathan Cameron
2023-10-12 13:13 ` Samuel Ortiz
2023-10-12 15:32 ` Jonathan Cameron
2023-10-13 5:03 ` Samuel Ortiz
2023-10-13 11:45 ` Alexey Kardashevskiy
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=df8c403791a588b97188bf0465426a270e3a4e6c.camel@wdc.com \
--to=alistair.francis@wdc.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=alex.williamson@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=david.e.box@intel.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=graf@amazon.com \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=keyrings@vger.kernel.org \
--cc=kvm@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=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=wilfred.mallawa@wdc.com \
--cc=zhi.a.wang@intel.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).