mirror of
https://github.com/SCST-project/scst.git
synced 2026-10-22 06:02:33 +00:00
Gleb Chesnokov
43e717c7f1
Move patch generation, specialization, regression, kernel selection and module signing helpers together, with their shared shell libraries. Update component Makefiles, CI, nightly jobs, packaging metadata, documentation and KUnit tooling references alongside the move. Adjust repository-root and source-inventory lookups for the deeper path. Resolve rhel-rpm-functions relative to kernel-functions through BASH_SOURCE, since it is also sourced by the QLogic extraction helpers. Keep the regression runner behavior and the nightly kernel matrix intact, including the existing checkpatch, sparse and smatch switches and 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/kernel/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/
|