mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Roland Hieber <>
Cc: Roland Hieber <>
Subject: [ptxdist] [PATCH] kernel: add support for kernel module signing
Date: Mon, 19 Jul 2021 20:30:53 +0200	[thread overview]
Message-ID: <> (raw)

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

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 <>
Note: this depends on "[PATCH v5] ptxd_lib_code_signing: cs_get_ca():
improve error handling", see
 doc/  | 57 +++++++++++++++++++++++++++++++++++++++++++++
 platforms/ | 17 ++++++++++++++
 rules/kernel.make   | 14 ++++++++---
 3 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/doc/ b/doc/
index 8fe7739aa0c8..2ee6d858f19e 100644
--- a/doc/
+++ b/doc/
@@ -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
+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.)
+  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/ b/platforms/
index 68899c0f7dcc..d7bff2656fd9 100644
--- a/platforms/
+++ b/platforms/
@@ -3,6 +3,7 @@
 menuconfig KERNEL
 	default y
 	select HOST_XZ			if KERNEL_XZ
@@ -38,6 +39,22 @@ config KERNEL_MODULES_INSTALL
 	prompt "Install modules into /lib/modules"
 	depends on KERNEL_MODULES
+	bool
+	depends on KERNEL_MODULES
+	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.
 	prompt "kernel version"
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)
+	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))
 # like kernel-opts but with different CROSS_COMPILE=
 	$(call kernel-opts, KERNEL,$(KERNEL_CROSS_COMPILE)) \
 	$(call remove_quotes,$(PTXCONF_KERNEL_EXTRA_MAKEVARS))
 # Intermediate option. This will be used by kernel module packages.
 	-C $(KERNEL_DIR) \
@@ -166,6 +172,7 @@ $(STATEDIR)/kernel.tags:
 	$(call kernel/deprecated, KERNEL_MAKE_OPT) \
 	$(call ptx/ifdef, PTXCONF_KERNEL_MODULES,modules)
@@ -231,7 +238,8 @@ endif
 # Install
 # ----------------------------------------------------------------------------

ptxdist mailing list
To unsubscribe, send a mail with subject "unsubscribe" to

             reply	other threads:[~2021-07-19 18:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 18:30 Roland Hieber [this message]
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 ` [ptxdist] [PATCH] kernel: add support for kernel module signing Michael Olbrich
2021-07-23 10:17   ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: [ptxdist] [PATCH] kernel: add support for kernel module signing' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox