summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorRoland Hieber <rhi@pengutronix.de>2021-07-23 16:29:54 +0200
committerMichael Olbrich <m.olbrich@pengutronix.de>2021-07-26 11:32:46 +0200
commit7771a8c434c34cf8276be8f143e0182fac0909b5 (patch)
tree9b6298d5cad5eacc90ff4a53d1a705098d9f1b71 /doc
parent642d138482bf67b36df720ea7f9c324620b20356 (diff)
downloadptxdist-7771a8c434c34cf8276be8f143e0182fac0909b5.tar.gz
ptxdist-7771a8c434c34cf8276be8f143e0182fac0909b5.tar.xz
kernel: add CAs from the code signing provider to the kernel trust root
Additional trusted CAs can be necessary for certain use cases, see the snippet in the docs. Current kernels don't cope well with an empty CONFIG_SYSTEM_TRUSTED_KEYS variable, so only add it when the singing provider actually supplies a non-empty list of 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 ':=', except the options for the perf and iio tools, were this is not needed. All other recipes using KERNEL_* variables also already take care of this.) Signed-off-by: Roland Hieber <rhi@pengutronix.de> Message-Id: <20210723142956.31879-1-rhi@pengutronix.de> Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Diffstat (limited to 'doc')
-rw-r--r--doc/daily_work.inc34
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/daily_work.inc b/doc/daily_work.inc
index 3b436c21f..4562b5ca7 100644
--- a/doc/daily_work.inc
+++ b/doc/daily_work.inc
@@ -123,6 +123,40 @@ 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.
+Using the Code Signing Infrastructure with the Kernel Recipe
+------------------------------------------------------------
+
+The kernel recipe can make use of the :ref:`code signing infrastructure
+<code_signing>` to supply cryptographic key material for several kernel features.
+They can be enabled in the `Linux kernel` section of ``ptxdist platformconfig``.
+
+.. important::
+
+ When supplying the kernel with key material, you should 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.
+
+.. _kernel_trust_root:
+
+Trusted Root CAs
+~~~~~~~~~~~~~~~~
+
+In some setups additional trusted CAs can be necessary;
+for example, when using EVM, the EVM key must be issued by a certificate that
+is trusted by the kernel.
+
+When ``PTXCONF_KERNEL_CODE_SIGNING`` ("depend on code signing infrastructure")
+is enabled in the platformconfig, and if the code signing provider supplies CA
+certificates in the ``kernel-trusted`` role,
+PTXdist adds the option ``CONFIG_SYSTEM_TRUSTED_KEYS`` to the kernel config to
+add those certificates to the kernel trust root.
+(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-trusted`` role to supply those certificates.)
+
Discovering Runtime Dependencies
--------------------------------