lkml.org 
[lkml]   [2022]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v1 1/1] certs: Explain the rational to call panic()
On Mon, Mar 21, 2022 at 1:45 PM Mickaël Salaün <mic@digikod.net> wrote:
>
> From: Mickaël Salaün <mic@linux.microsoft.com>
>
> The blacklist_init() function calls panic() for memory allocation
> errors. This change documents the reason why we don't return -ENODEV.
>
> Suggested-by: Paul Moore <paul@paul-moore.com> [1]
> Requested-by: Jarkko Sakkinen <jarkko@kernel.org> [1]
> Link: https://lore.kernel.org/r/YjeW2r6Wv55Du0bJ@iki.fi [1]
> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
> Link: https://lore.kernel.org/r/20220321174548.510516-2-mic@digikod.net
> ---
> certs/blacklist.c | 8 ++++++++
> 1 file changed, 8 insertions(+)

I would suggest changing the second sentence as shown below, but
otherwise it looks good to me.

Reviewed-by: Paul Moore <paul@paul-moore.com>

> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index 486ce0dd8e9c..ac26bcf9b9a5 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -307,6 +307,14 @@ 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 the functionality doesn't load and the

"As a result if the blacklist_init() function fails for any reason the
kernel continues to execute."

> + * kernel continues on executing. 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 signed
> + * modules. If a critical piece of security functionality that users expect to
> + * be present fails to initialize, panic()ing is likely the right thing to do.
> */
> static int __init blacklist_init(void)
> {

--
paul-moore.com

\
 
 \ /
  Last update: 2022-03-21 19:25    [W:1.202 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site