mirror of
https://github.com/SCST-project/scst.git
synced 2026-08-25 00:26:43 +00:00
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. Commit7aade0a109("Makefile: Make the qla2x00t-32gbit driver the default QLogic FC driver") made the newer tree the default. Commit0d3c9018af("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.
65 lines
2.9 KiB
Plaintext
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/
|