| Message ID | 3db7a8856833dfcbc4b122301f233828379d67db.1695921657.git.lukas@wunner.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | PCI device authentication | expand |
On Thu, 28 Sep 2023, 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> > --- > 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 > /* > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On Thu, 28 Sep 2023 19:32:32 +0200 Lukas Wunner <lukas@wunner.de> 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> 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 <Jonathan.Cameron@huawei.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 > /*
On Tue, 2023-10-03 at 11:37 +0300, Ilpo Järvinen wrote: > On Thu, 28 Sep 2023, 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> > > --- > > 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 > > /* > > > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> >
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> I was going to comment on s/blacklist/blocklist/, but the coding-style recommendation is relative to new usage. Reviewed-by: Dan Williams <dan.j.williams@intel.com>
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 > /*
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 /*
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> --- certs/blacklist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)