From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E472DDBB for ; Tue, 3 Oct 2023 09:10:51 +0000 (UTC) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S0BpC1Mm1z6K60k; Tue, 3 Oct 2023 17:09:07 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 3 Oct 2023 10:10:42 +0100 Date: Tue, 3 Oct 2023 10:10:41 +0100 From: Jonathan Cameron To: Lukas Wunner CC: Bjorn Helgaas , David Howells , David Woodhouse , Herbert Xu , "David S. Miller" , Alex Williamson , , , , , , , , David Box , Dan Williams , Dave Jiang , "Li, Ming" , Zhi Wang , Alistair Francis , Wilfred Mallawa , Alexey Kardashevskiy , Tom Lendacky , Sean Christopherson , Alexander Graf Subject: Re: [PATCH 04/12] certs: Create blacklist keyring earlier Message-ID: <20231003101041.00006511@Huawei.com> In-Reply-To: <3db7a8856833dfcbc4b122301f233828379d67db.1695921657.git.lukas@wunner.de> References: <3db7a8856833dfcbc4b122301f233828379d67db.1695921657.git.lukas@wunner.de> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500005.china.huawei.com (7.191.163.240) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected On Thu, 28 Sep 2023 19:32: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 Indeed seems like it needs to be before subsys_initcall so whilst it feels a bit weird to do it in one named arch, I guess that's the best choice available. Reviewed-by: Jonathan Cameron > --- > 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 > /*