Re: [ptxdist] [PATCH] kernel: add support for kernel module signing

[Michael Olbrich <m.olbrich@pengutronix.de>]

On Fri, Jul 23, 2021 at 12:17:36PM +0200, Roland Hieber wrote:
> On Wed, Jul 21, 2021 at 10:54:53AM +0200, Michael Olbrich wrote:
> > On Mon, Jul 19, 2021 at 08:30:53PM +0200, Roland Hieber wrote:
> > > Use the code signing role 'kernel-modules' to supply the kernel with the
> > > keys for kernel module signing and additional CAs for the kernel's trust
> > > root. This only works if kernel module signing is enabled in the kernel
> > > config file, so write a short paragraph for the "daily use" chapter in
> > > the docs what has to be considered when using module signing in PTXdist.
> > > 
> > > We can can add CONFIG_MODULE_SIG_KEY in all cases, it is simply ignored
> > > unless CONFIG_MODULE_SIG is also enabled in the kernel config. However,
> > > current kernels don't cope well with an empty CONFIG_SYSTEM_TRUSTED_KEYS
> > > variable, so only add it when the singing provider actually supplies CA
> > > certificates.
> > > 
> > > The cs_get_* functions print undefined strings when the code signing
> > > provider hasn't been installed into sysroot-host yet, which is usually
> > > the case when kernel.make is parsed at PTXdist startup. Therefore, all
> > > variables that make use of need to be evaluated recursively when they
> > > are used ('=' instead of ':='). All other recipes using KERNEL_*
> > > variables already take care of this.
> > > 
> > > Signed-off-by: Roland Hieber <rhi@pengutronix.de>
> > > ---
> > > Note: this depends on "[PATCH v5] ptxd_lib_code_signing: cs_get_ca():
> > > improve error handling", see
> > > https://lore.ptxdist.org/ptxdist/20210715134224.25700-1-rhi@pengutronix.de
> > > ---
> > >  doc/daily_work.inc  | 57 +++++++++++++++++++++++++++++++++++++++++++++
> > >  platforms/kernel.in | 17 ++++++++++++++
> > >  rules/kernel.make   | 14 ++++++++---
> > >  3 files changed, 85 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/doc/daily_work.inc b/doc/daily_work.inc
> > > index 8fe7739aa0c8..2ee6d858f19e 100644
> > > --- a/doc/daily_work.inc
> > > +++ b/doc/daily_work.inc
> > > @@ -123,6 +123,63 @@ To rebuild the kernel:
> > >           package. A ``ptxdist clean kernel`` call will only delete the
> > >           symlinks in the build directory, but not clean the kernel compiled files.
> > >  
> > > +Kernel Module Signing
> > > +---------------------
> > > +
> > > +The Linux kernel can generate crypgraphic signatures for all kernel modules
> > > +during the build process.
> > > +This can ensure that all modules loaded on the target at runtime have been
> > > +built by a trustworthy source.
> > > +
> > > +With the :ref:`code signing infrastructure <code_signing>`, PTXdist can supply
> > > +the kernel's build system with the private key for module signing.
> > > +However, additional settings must be enabled in the kernel config:
> > > +
> > > +* ``CONFIG_MODULE_SIG=y`` ("Module signature verification"):
> > > +  Enable this option for module signing, and to get access to its sub-options.
> > > +* ``CONFIG_MODULE_SIG_ALL=y`` ("Automatically sign all modules"):
> > > +  Enable this option so that the kernel's build system signs the modules during
> > > +  PTXdist's `kernel.install` stage.
> > > +* Additionally, ``CONFIG_MODULE_SIG_FORCE`` ("Require modules to be validly
> > > +  signed") can be useful so that the kernel refuses loading modules with
> > > +  invalid, untrusted, or no signature.
> > > +
> > > +For the full overview, refer to the `kernel's module signing documentation
> > > +<https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html>`_.
> > > +
> > > +PTXdist additionally augments the kernel config with the following config
> > > +options during the `kernel.compile` and `kernel.install` stages:
> > > +
> > > +* ``CONFIG_MODULE_SIG_KEY`` ("File name or PKCS#11 URI of module signing key"):
> > > +  PTXdist supplies the URI from the ``kernel-module`` role of the configured
> > > +  code signing provider.
> > > +  (The code signing provider should use :ref:`cs_set_uri` to set the URI.)
> > > +* ``CONFIG_SYSTEM_TRUSTED_KEYS`` ("Additional X.509 keys for default system keyring"):
> > > +  If the code signing provider added CA certificates to the ``kernel-module``
> > > +  role, PTXdist adds this option to the kernel config to specify those
> > > +  certificates.
> > > +  (The code signing provider should use :ref:`cs_append_ca_from_der`,
> > > +  :ref:`cs_append_ca_from_pem`, or :ref:`cs_append_ca_from_uri` with the
> > > +  ``kernel-module`` role.)
> > 
> > The documentation does not match the code. Here 'kernel-module' is used as
> > role for the trusted keys....
> 
> Ah yes. I also think 'kernel-trusted' is a better name here.
> 
> > > +
> > > +  In some setups this option can be necessary:
> > > +  For example, when using EVM, the EVM key must be issued by a key that is
> > > +  trusted by the kernel.
> > > +  If the same key is used for EVM and module signing (see
> > > +  ``CONFIG_MODULE_SIG_KEY``), *and* if this key is self-signed, no additional
> > > +  trusted CA is necessary because the module signing key is always added to
> > > +  the kernel's trust root.
> > > +  Otherwise, the CA which issued the EVM key must be supplied additionally
> > > +  through this kernel config option.
> > > +
> > > +.. important::
> > > +
> > > +   Also make sure that all necessary crypto algorithms are enabled in the kernel.
> > > +   For example, if your module signing key is signed with an SHA256 hash,
> > > +   you must enable ``CONFIG_CRYPTO_SHA256`` so that the signature can be verified.
> > > +   Otherwise, some older kernels throw a stack trace on boot, and will not load
> > > +   the supplied key material.
> > > +
> > >  Discovering Runtime Dependencies
> > >  --------------------------------
> > >  
> > > diff --git a/platforms/kernel.in b/platforms/kernel.in
> > > index 68899c0f7dcc..d7bff2656fd9 100644
> > > --- a/platforms/kernel.in
> > > +++ b/platforms/kernel.in
> > > @@ -3,6 +3,7 @@
> > >  menuconfig KERNEL
> > >  	bool
> > >  	default y
> > > +	select CODE_SIGNING		if KERNEL_MODULES_SIGN
> > >  	select HOST_U_BOOT_TOOLS	if KERNEL_IMAGE_U || (KERNEL_IMAGE_SIMPLE && ARCH_MICROBLAZE)
> > >  	select HOST_ZSTD		if KERNEL_ZSTD
> > >  	select HOST_XZ			if KERNEL_XZ
> > > @@ -38,6 +39,22 @@ config KERNEL_MODULES_INSTALL
> > >  	prompt "Install modules into /lib/modules"
> > >  	depends on KERNEL_MODULES
> > >  
> > > +config KERNEL_MODULES_SIGN
> > > +	bool
> > > +	depends on KERNEL_MODULES
> > > +	select KERNEL_MODULES_INSTALL
> > > +	select KERNEL_OPENSSL
> > > +	prompt "sign modules"
> > > +	help
> > > +	  If enabled, kernel modules are signed during the install stage with
> > > +	  the key specified by the code signing provider in the "kernel-module"
> > > +	  role. Additionally, the CA specified in the "kernel-module" role is
> > > +	  added to the kernel's trust root.
> > > +
> > > +	  See the section "Kernel module signing" in the "Daily Work" chapter in
> > > +	  the PTXdist manual for use cases and more infos about what needs to be
> > > +	  enabled in the kernel config file.
> > > +
> > >  config KERNEL_VERSION
> > >  	prompt "kernel version"
> > >  	string
> > > diff --git a/rules/kernel.make b/rules/kernel.make
> > > index f43c1bb8de89..750a68efc6fa 100644
> > > --- a/rules/kernel.make
> > > +++ b/rules/kernel.make
> > > @@ -53,18 +53,24 @@ endef
> > >  # check for old kernel modules rules
> > >  KERNEL_MAKEVARS = $(call kernel/deprecated, KERNEL_MAKEVARS)
> > >  
> > > +KERNEL_SIGN_OPT	= \
> > > +	CONFIG_MODULE_SIG_KEY='"$(shell cs_get_uri kernel-modules)"' \
> > > +	$(if $(shell cs_get_ca kernel-trusted), \
> > > +		CONFIG_SYSTEM_TRUSTED_KEYS=$(shell cs_get_ca kernel-trusted))
> > 
> > ... and here 'kernel-trusted' is used to import the CA.
> > 
> > I think the documentation should be changed. From what I understand,
> > trusted keys are useful for more than just module signature verification.
> 
> Yes.
> 
> > And I think this should only be used if PTXCONF_KERNEL_MODULES_SIGN is
> > enabled.
> 
> Hmm. I would add the 'kernel-trusted' lines regardless of whether module
> singing is enabled; it already has a check anyway and is only added if
> there are any CAs, and as you said it is useful for other things besides
> module signing.

Right, of course.

> > > +
> > >  # like kernel-opts but with different CROSS_COMPILE=
> > >  KERNEL_BASE_OPT		:= \
> > >  	$(call kernel-opts, KERNEL,$(KERNEL_CROSS_COMPILE)) \
> > >  	$(call remove_quotes,$(PTXCONF_KERNEL_EXTRA_MAKEVARS))
> > >  
> > >  # Intermediate option. This will be used by kernel module packages.
> > > -KERNEL_MODULE_OPT	:= \
> > > +KERNEL_MODULE_OPT	= \
> > >  	-C $(KERNEL_DIR) \
> > >  	O=$(KERNEL_BUILD_DIR) \
> > > +	$(KERNEL_SIGN_OPT) \
> > 
> > So we have the variable KERNEL_MODULE_OPT (separate from KERNEL_SHARED_OPT)
> > as something that is also used by out-of-tree kernel modules.
> > 
> > I expect, that we don't need CONFIG_SYSTEM_TRUSTED_KEYS here. But we do
> > need CONFIG_MODULE_SIG_KEY to sign those modules, right?
> 
> Yes, I think so too.
> 
> > I don't mind adding both here for simplicity, but I want to make sure that
> > they should be added here at all and not just to KERNEL_SHARED_OPT.
> 
> I think it's best to add module signing and add trusted keys in two
> separate patches, put CONFIG_SYSTEM_TRUSTED_KEYS into KERNEL_BASE_OPT
> (with its if condition), and only have CONFIG_MODULE_SIG_KEY in
> KERNEL_SIGN_OPT (behind a ifdef PTXCONF_KERNEL_MODULES_SIGN).

Hmm, I've been thinking about this some more. I think both should go in
KERNEL_BASE_OPT. Where setting CONFIG_* options here, overwriting stuff
from .config. And we should keep that consistent across all steps.

But definitely conditional with an option each.

Michael

> > >  	$(KERNEL_BASE_OPT)
> > >  
> > > -KERNEL_SHARED_OPT	:= \
> > > +KERNEL_SHARED_OPT	= \
> > >  	$(KERNEL_MODULE_OPT)
> > >  
> > >  ifndef PTXCONF_KERNEL_GCC_PLUGINS
> > > @@ -166,6 +172,7 @@ $(STATEDIR)/kernel.tags:
> > >  
> > >  KERNEL_MAKE_OPT		= \
> > >  	$(call kernel/deprecated, KERNEL_MAKE_OPT) \
> > > +	$(KERNEL_SIGN_OPT) \
> > >  	$(KERNEL_SHARED_OPT) \
> > >  	$(KERNEL_IMAGE) \
> > >  	$(call ptx/ifdef, PTXCONF_KERNEL_MODULES,modules)
> > > @@ -231,7 +238,8 @@ endif
> > >  # Install
> > >  # ----------------------------------------------------------------------------
> > >  
> > > -KERNEL_INSTALL_OPT := \
> > > +KERNEL_INSTALL_OPT = \
> > > +	$(KERNEL_SIGN_OPT) \
> > >  	$(KERNEL_BASE_OPT) \
> > >  	modules_install
> > >  
> > > -- 
> > > 2.30.2
> > > 
> > > 
> > > _______________________________________________
> > > ptxdist mailing list
> > > ptxdist@pengutronix.de
> > > To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
> > > 
> > 
> > -- 
> > Pengutronix e.K.                           |                             |
> > Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> > 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> > 
> > _______________________________________________
> > ptxdist mailing list
> > ptxdist@pengutronix.de
> > To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
> > 
> 
> -- 
> Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
> Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de
> To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de