Files
scst/README.module-signing
T
Gleb Chesnokov 9129391ac3 docs: Refresh build and installation guides
The top-level guides still describe retired source, QLogic, service and
kernel-support workflows. Following them can select the wrong driver,
cross-compile only part of the tree, or misstate module-signing policy.

Commit 7aade0a109 ("Makefile: Make the qla2x00t-32gbit driver
the default QLogic FC driver") made the newer tree the default.
Commit 0d3c9018af ("debian, scstadmin: Add systemd scst.service")
added the installed systemd unit.

Point source users at GitHub and kernel support at
nightly/conf/nightly.conf. Separate kernel and user-space cross builds,
follow the current service recipes, and make module acceptance depend
on the target kernel and platform policy.
2026-08-21 10:05:36 +03:00

65 lines
2.9 KiB
Plaintext

SCST and kernel module signing
==============================
Introduction
------------
The purpose of kernel module signatures is to only allow those kernel modules
to be loaded that have been signed with an approved key. A signed kernel
module is a kernel module with a digital signature embedded into the module
stating the owner of the signature created that kernel module. This is a
security mechanism that was introduced in kernel v3.7. Module signatures are
verified against trusted public keys available to the running kernel. Whether
unsigned modules are rejected depends on the kernel configuration, command
line and platform security policy.
Module Signing and SCST
-----------------------
On systems that use shim and the Machine Owner Key (MOK) mechanism, the
preferred approach is to keep signature verification enabled and enroll the
public certificate generated during the SCST build.
Permissive module loading is only available if the kernel and platform policy
allow it. In particular, `module.sig_enforce=0` does not override a kernel
built with `CONFIG_MODULE_SIG_FORCE`. Follow the distribution-specific Secure
Boot and module-signing documentation before changing the boot configuration.
Signing SCST Kernel Modules
---------------------------
If `CONFIG_MODULE_SIG=y` is set in the target kernel configuration, the SCST
build uses openssl to generate a public/private key pair in the scst/src/certs
directory:
ls -l scst/src/certs/scst_module_key*
The `.der` file is the public certificate and the `.priv` file is the private
key. Keep the private key secret and never pass it to mokutil. During
installation, `scripts/sign-modules` signs modules with the target kernel's
`scripts/sign-file`. If `sign-file` is unavailable, the script reports that
the modules are not being signed and continues; check the installation output
before relying on signature enforcement.
On systems that use shim and the Machine Owner Key (MOK) mechanism, start
importing the public certificate as follows:
mokutil --import scst/src/certs/scst_module_key.der
The mokutil software asks for a temporary enrollment password. Next, verify
with `mokutil --list-new` that the import is pending and reboot. The bootloader
starts MokManager, where the certificate can be enrolled. Before loading SCST
modules, use `modinfo -F signer <module.ko>` to inspect the embedded signer.
This confirms that signer metadata is present; it does not prove that the
running kernel trusts the certificate. Only test module loading on a host
where changing SCST module and service state is safe.
See Also
--------
* Linux Kernel Module Signing Documentation, kernel.org
https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html
* Signed kernel module support, Gentoo Wiki
https://wiki.gentoo.org/wiki/Signed_kernel_module_support
* Build and install signed Kvaser driver modules
https://www.kvaser.com/developer-blog/build-install-signed-kvaser-driver-modules/