From: Michael Olbrich <m.olbrich@pengutronix.de>
To: Roland Hieber <rhi@pengutronix.de>, ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] kernel: add support for kernel module signing
Date: Wed, 21 Jul 2021 10:54:53 +0200 [thread overview]
Message-ID: <20210721085453.GA735550@pengutronix.de> (raw)
In-Reply-To: <20210719183053.3799-1-rhi@pengutronix.de>
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....
> +
> + 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.
And I think this should only be used if PTXCONF_KERNEL_MODULES_SIGN is
enabled.
> +
> # 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?
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.
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
next prev parent reply other threads:[~2021-07-21 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-19 18:30 Roland Hieber
2021-07-20 9:38 ` [ptxdist] [PATCH 2/1] host-ptx-code-signing-dev: version bump 0.5.1 -> 0.6 Roland Hieber
2021-07-21 8:54 ` Michael Olbrich [this message]
2021-07-23 10:17 ` [ptxdist] [PATCH] kernel: add support for kernel module signing Roland Hieber
2021-07-23 10:39 ` Michael Olbrich
2021-07-23 14:02 ` Roland Hieber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210721085453.GA735550@pengutronix.de \
--to=m.olbrich@pengutronix.de \
--cc=ptxdist@pengutronix.de \
--cc=rhi@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox