Message-ID: <CAPp5cGTcRGp3z=xbA1svxLYz1LC74_AQrTPSXNmACPRYrpporg@mail.gmail.com>
Date:   Fri, 17 Nov 2023 14:56:53 +0100
From:   Alessandro Carminati <alessandro.carminati@...il.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] Modules: Introduce boot-time module signature flexibility

Hello Luis,

Thanks a lot for sharing your thoughts about this topic.

Il giorno gio 16 nov 2023 alle ore 18:35 Luis Chamberlain
<mcgrof@...nel.org> ha scritto:
>
> On Thu, Sep 14, 2023 at 11:27:38AM +0000, Alessandro Carminati (Red Hat) wrote:
> > This commit introduces a novel boot argument parameter that provides an
> > advanced level of control over the verification of module signatures
> > during the initial stages of booting. With this enhancement, we gain the
> > capability to postpone the verification of module signatures to after
> > intrd stage is finished.
> >
> > Given that bootloader-provided artifacts are commonly employed
> > post-verification,
>
> Is such a thing expressed with a kernel config? If so then shouldn't
> this be default for those uses cases?
>

I've hesitated to propose this as the default behavior for a few reasons:
The current patch doesn’t include a check for the secure boot chain being
enabled.
>From what I've learned, confirming secure boot mode on UEFI systems,
especially on non x86 targets, lacks a standardized method.
Considering this, I've chosen to leave the decision to users who can
specify a command-line argument during kernel boot.

Implementing a new feature as default in the kernel might face resistance
and seem intrusive.
To avoid potential conflicts, I lean towards letting users choose to opt
into this feature.

Additionally, It’s essential to acknowledge that not all kernels involve an
initrd phase.
Embedded systems often differ in their use of an initrd compared to traditional
Linux distributions.
Enforcing this feature by default might not align with the preferences of
the embedded systems community.
I'm open to investing time in proposing conditions that might pave the way for
this feature to become default if certain conditions are met.

> > Signed-off-by: Alessandro Carminati (Red Hat) <alessandro.carminati@...il.com>
> > ---
> >  include/linux/module.h  |  4 +++
> >  kernel/module/main.c    | 14 ++++++-----
> >  kernel/module/signing.c | 56 +++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 68 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index a98e188cf37b..9899aeac43b0 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -34,6 +34,10 @@
> >
> >  #define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
> >
> > +#ifdef CONFIG_MODULE_SIG
> > +extern int module_sig_check_wait;
> > +#endif
>
> Please add under is_module_sig_enforced. That's one new line Vs 3 new ones.
>
> I see the code which skips module signature verification and the knobs
> but I don't see the code which complete the promise to do the actual
> signature verification post initrd / initramfs state. What gives?

My initial intention wasn't centered around providing an automated solution.
Instead, I envisioned a design where users could manually restore module
verification during a specific point in their init scripts.

It might be plausible to restore module verification when the rootfs is
remounted. However, this seems limiting rather than advantageous.

To offer users maximum flexibility, I considered a solution involving a
sysfs file as a control mechanism.

The objective of the RFC I sent out is to gather opinions on this feature.
Understanding what people think about it is very welcome. In this context,
the question arises: would it be better to have an automated solution that
restores the module signature verification automatically?

>
>   Luis

Powered by blists - more mailing lists