diff mbox series

[04/12] certs: Create blacklist keyring earlier

Message ID 3db7a8856833dfcbc4b122301f233828379d67db.1695921657.git.lukas@wunner.de (mailing list archive)
State New
Headers show
Series PCI device authentication | expand

Commit Message

Lukas Wunner Sept. 28, 2023, 5:32 p.m. UTC
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(-)

Comments

Ilpo Järvinen Oct. 3, 2023, 8:37 a.m. UTC | #1
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>
Jonathan Cameron Oct. 3, 2023, 9:10 a.m. UTC | #2
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
>  /*
Wilfred Mallawa Oct. 3, 2023, 10:53 p.m. UTC | #3
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>
>
Dan Williams Oct. 6, 2023, 7:19 p.m. UTC | #4
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>
Alistair Francis Oct. 12, 2023, 2:20 a.m. UTC | #5
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 mbox series

Patch

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
 /*