Kernel Module Packages Manual

This version of the Kernel Module Packages Manual applies to:

Developers who want to build for SUSE Linux Enterprise Server versions before SUSE Linux Enterprise Server 12 SP2 should use previous versions of this document SUSE SolidDriver Documentation: Kernel Module Packages Manual for Code 11 .

Appendix B provides a list of changes that have been made to this document to accommodate new features.

The Linux kernel supports adding functionality at runtime through kernel-loadable modules. It includes more than 1500 modules, about 75 percent of which are hardware drivers. These modules are shipped as part of the kernel packages. In some cases it is desirable to add additional modules or replace existing ones. For example, a driver for a particular storage controller that was not available at the time of product release might be added later to support new hardware.

Kernel modules interact with the kernel by the means of exported symbols, in a way similar to how user space binaries use shared libraries. The /proc/kallsyms file lists all symbols currently known to the kernel. To ensure that the kernel and modules refer to the same symbols, a version checksum (modversion) is added to each symbol. The checksum is computed from the symbol's type: in the case of function symbols, the checksum is determined by the function's parameters and return type.

When any of a function's parameters or the return type changes, the checksum changes as well. This includes all the data types involved recursively:

If a function takes a struct task_struct as parameter and struct task_struct includes a field of type struct dentry, then a change to struct dentry will cause the symbol's version checksum to change as well. Symbol version checksums for different kernel flavors (for example kernel-default versus kernel-xen) will not match, and symbol versions of the same kernel package on different architectures will not match either. This mechanism ensures that the kernel and kernel modules agree on the types of data structures that they use to communicate.

Unless symbol version checking is disabled, modules will load only if the checksums of the symbols they use match the checksums of the symbols that the kernel exports. The exported symbols and their version checksums comprise the kernel Application Binary Interface (kABI). When an updated kernel includes kABI changes, kernel modules that use any modified symbols must be updated as well.

During their multi-year lifecycle, products like SUSE Linux Enterprise Server undergo continuous changes. Different kinds of updates like service packs (SPs), maintenance/security updates, and customer-specific updates (Program Temporary Fixes) are released. The Application Binary Interface (ABI) between the kernel and kernel modules is volatile. Some kernel updates will change the kernel ABI (kABI) by adding or removing exported symbols, or existing symbol checksums can change in a kernel update because of changes in data structures they reference. SUSE strives to keep the kernel ABI stable in maintenance and security and customer-specific updates, but sometimes changes cannot be avoided. In service packs, SUSE reserves the right to introduce more intrusive changes, which increases the likelihood of ABI changes. SUSE believes that the added flexibility outweighs the disadvantages of breaking older modules. For full discussion of this topic, see the documentation SUSE SolidDriver Documentation: SUSE Kernel ABI Stability and The Linux Kernel Driver Interface from Greg Kroah-Hartman (also provided as stable_api_nonsense.txt in the upstream kernel source tree).

SUSE Linux Enterprise-based operating systems include technology to ensure that kernel modules can be reused or updated in synchronization with kernel updates. To use this technology, kernel modules must be packaged into Kernel Module Packages (KMPs) as defined in this document.

Each product based on SUSE Linux Enterprise 12 SP2 or SUSE Linux Enterprise 15 contains a set of kernel packages that share the same version and release number; they are built from the same kernel sources. These packages are:

The binary kernel packages. Each architecture has its own set of kernel flavors (for example kernel-default, kernel-debug, etc.). These are the packages that the kernel modules will be used with.

The kernel-FLAVOR-base packages are subsets of the kernel-FLAVOR packages, intended for use with minimal installs. They are not installed by default.

The kernel source tree, generated by unpacking the vanilla kernel sources and applying all necessary patches. Although the kernel-FLAVOR packages technically are not built from the kernel-source package, they are built from the same source tree. This tree should be used for module building.

Kernel-level headers, makefiles, and RPM macros and templates required for development of external kernel modules.

Kernel symbol version information for compiling external modules. The kernel-FLAVOR-devel package is required for building external modules. If this package is not used, the resulting modules will be missing symbol version information, which will cause them to break during kernel updates. The kernel-syms package is a placeholder package which depends on the kernel-FLAVOR-devel packages for all kernel flavors.

For more information, refer to the document “Working With The SUSE 2.6.x and 3.x Kernel Sources” from Andreas Gruenbacher and Michal Marek. This document is provided as README.SUSE in the SUSE kernel-source package.

Documentation on general kernel module building can be found in abundance on the Internet. Two good lectures are:

SUSE-specific information is found in the above-mentioned README.SUSE in the kernel-source package.

When built, kernel module binaries are installed below /lib/modules/VERSION-RELEASE-FLAVOR on the file system (example: /lib/modules/4.4.73-5-default for the SUSE Linux Enterprise Server 12 SP3 kernel-default-4.4.73-5 package). Different kernels have different module directories, and will usually not see each other's modules.

Update modules are modules intended to replace or augment the modules that are provided in the kernel packages. Update modules must be stored below the /lib/modules/VERSION-RELEASE-FLAVOR/updates/ directory. Modules in the updates/ directory have precedence over other modules with the same name. Never replace modules from the kernel package by overwriting files: this would lead to inconsistencies between the file system and the RPM database.

Note: Where to store modules

Modules intended to take precedence over in-kernel modules of the same name should be stored below /lib/modules/VERSION-RELEASE-FLAVOR/updates/. Other add-on modules can be stored below /lib/modules/VERSION-RELEASE-FLAVOR/extra/.

Modules usually remain compatible with a range of kernel-FLAVOR packages. To make such modules visible to other kernel-FLAVOR packages, symbolic links to compatible modules are put in /lib/modules/VERSION-RELEASE-FLAVOR/weak-updates/ directories. Modules in the weak-updates/ directory have lower priority than modules in the updates/ directory, but higher priority than all other modules in /lib/modules/VERSION-RELEASE-FLAVOR. If more than one compatible module is available for a kernel, the module with the highest kernel release is chosen. Kernel Module Packages must never directly install modules into weak-updates/ directories.

Kernel modules must never be installed as individual files on a production system, but always as part of a Kernel Module Package.

SUSE has worked closely with the Linux Foundation Driver Backport Workgroup to establish a standard structure for building Kernel Module Packages for all RPM-based distributions. The information in this document includes the standards as appropriate.

Kernel Module Package spec files define a main package, and a sub-package for each kernel flavor supported. The kernel-flavor-specific sub-packages are defined with the %kernel_module_package RPM macro. The macro automatically determines for which kernel flavors to generate sub-packages. Several options are available to modify the macro's behavior, which are described below:

%kernel_module_package [-f filelist] [-p preamble] [-n name] [-v version] [-r release] [-t template] [-x flavor] [-b]

The main package of a Kernel Module Package can either contain no %files section, in which case rpm will not create a binary package with the main package's name, or the files section can also be used for the user space part associated with the kernel modules that end up in the kernel specific sub-packages. The example Kernel Module Package in Appendix A has a main package without a %files section.

Kernel Module Packages must adhere to the following rules:

The %description tag will be applied to both the main package and the sub-packages.

The %kernel_module_package macro uses a default sub-package template that should work for most KMPs. This template can be overridden using the macro's -t option. The default template takes care of the following:

By default, each kernel-specific sub-package will have the following list of files, which can separately be overridden with the -f option:

%defattr (-,root,root)
/lib/modules/%2-%1

Additional sub-package preamble lines such as Requires, Provides, and Obsoletes tags can be specified with the -p option. File name arguments specified in -f, -p and -t should be given as absolute path names (for example %_sourcedir/file) and should be listed as sources. The following substitutions are defined in those files:

Some Kernel Module Packages may make sense only for some of the kernel flavors a given architecture supports. A list of flavors to exclude from the build should be passed with the -x option to the %kernel_module_package macro.

Appendix A contains an example Kernel Module Package spec file and the source code referenced by it. When this spec file and its accompanying source is built into an x86_64 RPM as described in section Section 7, “Building Kernel Module Packages”, the BuildRequires tag in the spec file will pull the module-init-tools, kernel-source, kernel-syms and kernel-devel packages into the build root.

Note: Dependency

The %kernel_module_package_buildreqs macro does not need to explicitly list “kernel-source” since the kernel-syms package has a dependency on the kernel-source package.

Now assume that the required packages are available in SUSE Linux Enterprise Server 12 SP3 (kernel 4.4.73-5), and that the default kernel flavor is available on that platform. Assuming a release number of “0”, rpm would then create the following packages:

suse-hello-kmp-default-1.0_k4.4.73_5-0.x86_64.rpm

The generated packages would contain the following module, and require and provide the following symbols:

Kernels export symbols that kernel modules use. Symbols have version checksums attached, and the checksums of the exported kernel symbols must match the checksums of the kernel symbols that the Kernel Module Package uses.

Similarly, at an RPM level, each kernel-FLAVOR package (for example kernel-default) provides the symbols and checksums that are exported by that flavor of the kernel, and each Kernel Module Package requires the specific kernel symbols and checksums needed by the module(s) that it contains. Installation of a KMP will succeed as long as an installed kernel package provides the symbols and checksums that are required by the KMP.

When modules in Kernel Module Packages export additional symbols, such symbols are mapped to Provides of those packages. Modules in other Kernel Module Packages may require those symbols. As an example, assume that a Kernel Module Package provides an exported function as ksym(default:exported_function) = e52d5bcf. Any Kernel Module Package that uses this function would require this same symbol and checksum.

In addition to the C and kernel programming skills required for writing the kernel module source code, creating proper Kernel Module Packages requires some familiarity with the rpm command and with build environments. For more information on kernel module building refer to the above-mentioned Linux Kernel Module Programming Guide and the book Linux Device Drivers. Additional SUSE-specific kernel and kernel module information can be found in the README.SUSE in the kernel-source package. SUSE recommends using the example package found in Appendix A as a template to reduce the complexities related to RPM. A lot of additional information on RPM can be found at http://www.rpm.org/, including a reference to the excellent Maximum RPM.

SUSE strongly recommends using the kernel build infrastructure (kbuild) for building and installing the kernel modules, as done in the example package. kbuild is documented in the file /usr/src/linux/Documentation/kbuild/ from the kernel-source package. Trying to emulate kbuild will lead to various problems including mis-compilations and missing or wrong symbol versions, and increased support load because of subtle breakages.

To achieve consistent and reproducible builds in a defined environment independent of the software installed on the system used for building, use the build script from the build.rpm package. This script sets up a build environment from the RPM packages the script is pointed at. The packages are then built in this environment using chroot (see the chroot(1) manual page at https://linux.die.net/man/1/chroot). All SUSE packages are built using the same mechanism. When building Kernel Module Packages with build.rpm, the following options of the build script are particularly relevant:

Define the directory in which to set up the build environment. Defaults to the BUILD_ROOT environment variable, and to /var/tmp/build-root if unset.

Define where build will look for packages for constructing the build environment. The directories are searched recursively. Packages found earlier in the path have precedence over packages found later, similar to how the PATH environment variable works. Defaults to the BUILD_RPMS environment variable, and to /media/dvd/suse if unset. The --rpms option must only be specified once.

Reconstruct the build environment entirely from scratch (--clean), or start the build without initializing the build environment (--no-init), which skips checking whether all packages in the build environment are up-to-date.

Build stores the created packages below home/abuild/rpmbuild/ in the build environment.

On dual-architecture machines, packages for the other supported architecture can be built by running the build script inside an architecture selector. On Intel 64/AMD64, the selector is called linux32, on IBM POWER this is ppc32, and on IBM Z the selector is called s390x. The same build environment cannot be reused for different architectures unless it is reinitialized with build's --clean option.

See the build(1) manual page for further information.

Note: Building external modules

For building external modules, you need to have both the kernel-source and kernel-FLAVOR-devel packages installed in the build environment. The BuildRequires line in spec files takes care of this: the %kernel_module_package_buildreqs macro specifies the kernel-syms package, which pulls in the kernel-source package and the kernel-FLAVOR-devel packages because of its dependency on them. Without the kernel-syms package the module build can still succeed depending on how you do the build, but the resulting modules will have module symbol versions disabled. Kernel Module Packages without module symbol versions will appear to match any kernel although in fact they do not. This can easily lead to very hard-to-diagnose system malfunctions.

Signing (as applied to a piece of software) is the process of digitally tagging the software to verify the author and guarantee that the software has not been altered since it was signed. SUSE Linux Enterprise Server and SUSE Linux Enterprise Desktop include utilities to sign and validate signatures on packages and repositories. In addition, SUSE Linux Enterprise Server and SUSE Linux Enterprise Desktop 12 and later versions include technology to sign and validate signatures on kernel modules.

The following sections describe how to sign packages and kernel modules. The topic of repository signing is beyond the scope of this document.

$ rpm --eval “%define _signature gpg” \
      --eval “%define _gpg_name build@suse.com” \
      --addsign package.rpm

$ gpg --armor --export build >build-pubkey.txt

$ rpm --import build-pubkey.txt

$ rpm --checksig package.rpm
package.rpm: (sha1) dsa sha1 md5 gpg OK

8.2 Signing module object files (UEFI Secure Boot) #

  

Although using signed packages and other OS security features can secure an installed and running system, they cannot prevent system subversion before the OS has booted. To address pre-OS security concerns, the UEFI Secure Boot specification (see http://www.uefi.org/specs) details a protocol to prevent the loading of boot loaders or kernels (including modules) that are not signed with an approved digital key stored in the system firmware.

The UEFI Secure Boot specification allows for variation in implementation. A simple way to implement secure boot is to ensure that the base system (as provided by the system vendor) contains all the keys that will be used by the boot loader, the OS, and any drivers. But having the system vendor simply place all needed keys into the firmware is not a full solution, as it does not give appropriate control to the system user/owner. SUSE's secure boot implementation addresses this control issue by extending the secure-boot-enabled EFI shim loader to accept keys that have been approved by the system owner. Thus, if there is a need to load a module with an unrecognized key, the key can be added to the “approved key” database (reboot and system-owner approval required).

8.2.1 Creating a key and certificate #

  

Module signing requires having access to a digital key and certificate. Official keys and certificates are generally maintained by an organization's security team or by build services (such as the Open Build Service or the SolidDriver/PLDP Build Service). Developers and packagers can also generate their own keys and certificates for example for testing purposes.

To create a key and certificate using the openssl req command, type the following:

export USER="your company name"
openssl req -new -x509 -newkey rsa:2048 -sha256 -keyout key.asc -out cert.der \
            -outform der -nodes -days 4745 -addext "extendedKeyUsage=codeSigning" \
            -subj "/CN=$USER/"

The above sequence of commands will create a key.asc key file and a cert.der x509 certificate in the current working directory. The 4745 option generates a certificate which will be valid for 13 years.

Note: Extended Key Usage (EKU) setting

The -addext "extendedKeyUsage=codeSigning" openssl option has been added to this document as of October 2021. The EKU codeSigning setting is now required for latest kernel releases of SUSE Linux Enterprise 15 SP2 and all kernels of subsequent service packs to accept the certificate for signature verification of kernel modules.

The -addext option requires OpenSSL version 1.1.1 or later. For earlier versions of OpenSSL, consult the documentation for setting the EKU.

8.2.2 Signing modules during packaging #

  

Signing modules as part of the packaging process requires making several changes to the KMP spec file. The spec file template in Appendix A.1 includes these changes, which are:

1. List the certificate file as a %Source file. The top-level directory of the build structure (where the spec file is located) should include both a private key file and a certificate file. The spec file should list the certificate as a %Source file. The spec file should not list the key file (since the private key should not be included in the source KMP).

   

   Note: Naming

   To be recognized by the kernel Makefile, the key file must be named “signing_key.priv” and the certificate file must be named “signing_key.x509”. The example above describes how to use the openssl req command to create a key.asc key file and a cert.der certificate file; to use these files at packaging-time, they should be renamed to “signing_key.priv” and “signing_key.x509”.

2. Invoke the %kernel_module_package macro with the -c %_sourcedir/signing_key.x509 option to generate a <name>-ueficert package which installs the certificate and calls the mokutil utility to enroll the public key. The actual module signing is handled in the %install section of the spec file.

3. Add %install section code to invoke the kernel-sign-file file to sign the modules.

Note: Own Keys and Certificates

The Appendix A.1 sample spec file is designed to be used by developers and packagers who provide their own keys and certificates and their own build environments. Developers/packagers who use the Open Build Service should modify their spec file as described in the pesign-obs-integration package README.

8.2.3 Signing an existing KMP #

  

The pesign-obs-integration package in SUSE Linux Enterprise Server provides a modsign-repackage utility that can be used to sign kernel modules in an existing KMP. modsign-repackage unpacks the original RPM, signs any included modules and re-creates the RPM. It also creates a second <NAME>-ueficert RPM that installs the certificate and calls the mokutil utility to enroll the public key. The re-packaged RPM will have a dependency on the <NAME>-ueficert RPM, ensuring that the certificates will be installed at the same time as the module(s).

To repackage the suse-hello-kmp-default-1.0_k4.4.73_5-0.x86_64.rpm package with the key and the certificate created above, do the following:

modsign-repackage -c ./cert.der -k ./key.asc
                    ./suse-hello-kmp-default-1.0-k4.4.73_5-0.x86_64.rpm

The above command creates the following directories and files in the current working directory:

./RPMS/
   x86_64/
     suse-hello-kmp-default-1.0-k4.4.73_5-0.x86_64.rpm
     suse-hello-ueficert-1.0-0.x86_64.rpm

To see the module signature, unpack the repackaged KMP and use the modinfo command to view the module signature info:

rpm2cpio suse-hello-kmp-default-1.0-k4.4.73_5-0.x86_64.rpm | cpio -idv
modinfo ./lib/modules/4.4.73-5-default/updates/hello.ko | grep signature

Note: rpm-build must be installed

modsign-repackage uses the /usr/bin/rpmbuild utility which is provided by the SUSE Linux Enterprise Server rpm-build package. This means the rpm-build package must be installed to use modsign-repackage.

8.2.4 Installation of secure-boot-enabled KMPs #

  

As discussed above, secure-boot-enabled KMPs include an additional <NAME>-ueficert package to install the certificate and enroll the public key. The <NAME>-kmp-<flavor> packages require the <NAME>-ueficert package.

After the <NAME>-ueficert package is installed, the system must be rebooted and the newly-enrolled key approved by the system owner before the key (and thus the signed modules) can be used.

The mokutil utility can also be used on its own to view and manage keys in the key database.

Kernel Module Packages can be provided as stand-alone RPMs. However, SUSE encourages distributing them via add-on products (for drivers that do not need to be included in the installation kernel), or in driver update disks or full bootable driver kits (for drivers that do need to be included in the installation kernel).

Add-on products can be created using the YaST Add-on Creator module in the SUSE Linux Enterprise Server 12 Software Development Kit (SDK). They can also be created manually using the information available in the section Creating Add-Ons from the document Update Media HOWTO.

Driver update disks can be created using the information in the section SUSE Update Media Howto from the document Creating Add-Ons. To create full custom bootable installation media, use the mksusecd utility included in SUSE Linux Enterprise Server. Note that mksusecd does not include a man page but provides detailed usage information via mksusecd --help.

Initial system installation is carried out by YaST from some installation media (CDs or DVDs, network locations, etc.). As noted above, support for additional hardware that the installation media do not provide can be added with Driver Update Disks or Bootable Driver Kits/Installation Kits. This is most important to enable hardware needed for booting, such as storage controllers.

Update media such as Driver Update Disks and Bootable Driver Kits/Installation Kits provide two kinds of modules: those which the kernel that runs the installation uses, and those which are installed onto the final target system. Both types of modules are provided by including Kernel Module Packages on the update media. In addition, update media can contain scripts which are run at specific times during the installation.

After the initial YaST installation, additional driver packages can be installed using any of the mechanisms for installing RPM packages (YaST Add-on Products, YaST Software Management, YaST Online Update, the rpm command, etc.). The add-on product format supports the ability to register the system for an update site.

Note: initrd

Any drivers required for getting to and accessing the root file system must be part of the initial RAM disk. YaST will automatically include necessary kernel modules in the initrd created during installation. But when Kernel Module Packages are installed by hand or are updated, it can be necessary to explicitly rebuild the initrd to include the new modules. As noted in Section 5, “Kernel Module Packages”, a Kernel Module Package will automatically rebuild the initrd in its %postinstall script if the module being installed is already part of the existing initrd or if the -b option to the %kernel_module_package macro is used.

The -b option simply forces a RAM disk rebuild using the existing RAM disk configuration: If the existing RAM disk configuration does not include the module being installed, then simply using the -b option will not include the new module in the new RAM disk. In such cases, the Kernel Module Package also needs to make appropriate RAM disk configuration changes (for example by creating or updating files in /etc/dracut.conf.d) to include the new module.

After all software repositories that should be checked for updates have been added, the package manager will automatically detect when new kernel packages and new Kernel Module Packages become available. The dependencies between those packages will ensure that the installed kernel packages match the installed Kernel Module Packages.

The following sample is described in the section Section 5, “Kernel Module Packages”. For a sample spec file that signs modules during packaging, see Appendix A.1.

suse-hello.spec

# norootforbuild

Name:           suse-hello
Version:                1.0
Release:                0
Summary:                Sample Kernel Module Package
License:                GPL-2.0
Group:          System/Kernel
Source0:                %{name}-%{version}.tar.bz2
BuildRequires:  %kernel_module_package_buildreqs
BuildRoot:      %{_tmppath}/%{name}-%{version}-build

%kernel_module_package

%description
This package contains the hello.ko module.

%prep
%setup
set -- *
mkdir source
mv "$@" source/
mkdir obj

%build
for flavor in %flavors_to_build; do
       rm -rf obj/$flavor
       cp -r source obj/$flavor
       make -C %{kernel_source $flavor} modules M=$PWD/obj/$flavor
done

%install
export INSTALL_MOD_PATH=$RPM_BUILD_ROOT
export INSTALL_MOD_DIR=updates
for flavor in %flavors_to_build; do
       make -C %{kernel_source $flavor} modules_install M=$PWD/obj/$flavor
done

The following two files should be compressed to form the suse-hello-1.0.tar.bz2 TAR archive referenced as Source0 in the suse-hello.spec file above.

suse-hello-1.0/Kbuild

obj-m           := hello.o
hello-y     += main.o

suse-hello-1.0/main.c

/*
 * main.c - A demo kernel module.
 *
 * Copyright (C) 2003, 2004, 2005, 2006
 * Andreas Gruenbacher <agruen@suse.de>, SUSE Labs
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation.
 *
 * A copy of the GNU General Public License can be obtained from
 * http://www.gnu.org/.
 */

#include <linux/module.h>
#include <linux/init.h>

MODULE_AUTHOR("Andreas Gruenbacher <agruen@suse.de>");
MODULE_DESCRIPTION("Hello world module");
MODULE_LICENSE("GPL");

int param;

module_param(param, int, 0);
MODULE_PARM_DESC(param, "Example parameter");

void exported_function(void)
{
        printk(KERN_INFO "Exported function called.\n");
}
EXPORT_SYMBOL_GPL(exported_function);

int __init init_hello(void)
{
        printk(KERN_INFO "Hello world.\n");
        return 0;
}

void __exit exit_hello(void)
{
        printk(KERN_INFO "Goodbye world.\n");
}

module_init(init_hello);
module_exit(exit_hello);

The following spec file can be used to sign modules during packaging as described in Section 8.2.2 above.

suse-hello.spec

# norootforbuild

Name:           suse-hello
Version:                1.0
Release:                0
Summary:                Sample Kernel Module Package
License:                GPL-2.0
Group:          System/Kernel
Source0:                %{name}-%{version}.tar.bz2
# Required to sign modules:  Include certificate named “signing_key.x509”
# Build structure should also include a private key named “signing_key.priv”
# Private key should not be listed as a source file
Source1:        signing_key.x509
BuildRequires:  %kernel_module_package_buildreqs
BuildRoot:      %{_tmppath}/%{name}-%{version}-build

# Required to sign modules:  The -c option tells the macro to generate a
# suse-hello-ueficert subpackage that enrolls the certificate
%kernel_module_package -c %_sourcedir/signing_key.x509

%description
This package contains the hello.ko module.

%prep
%setup
# Required to sign modules:  Copy the signing key to the build area
cp %_sourcedir/signing_key.* .
set -- *
mkdir source
mv "$@" source/
mkdir obj

%build
for flavor in %flavors_to_build; do
       rm -rf obj/$flavor
       cp -r source obj/$flavor
       make -C %{kernel_source $flavor} modules M=$PWD/obj/$flavor
done

%install
export INSTALL_MOD_PATH=$RPM_BUILD_ROOT
export INSTALL_MOD_DIR=updates
for flavor in %flavors_to_build; do
       make -C %{kernel_source $flavor} modules_install M=$PWD/obj/$flavor
       # Required to sign modules:  Invoke kernel-sign-file to sign each module
       for x in $(find $INSTALL_MOD_PATH/lib/modules/*-$flavor/ -name '*.ko'); do
               /usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 $PWD/obj/$flavor/signing_key.priv $PWD/obj/$flavor/signing_key.x509 $x
       done
done

Copyright ©2006-2024 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

SUSE, the SUSE logo and YaST are registered trademarks of SUSE LLC in the United States and other countries. For SUSE trademarks, see http://www.suse.com/company/legal/. Linux is a registered trademark of Linus Torvalds. All other names or trademarks mentioned in this document may be trademarks or registered trademarks of their respective owners.

Documents published as part of the SUSE Best Practices series have been contributed voluntarily by SUSE employees and third parties. They are meant to serve as examples of how particular actions can be performed. They have been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. SUSE cannot verify that actions described in these documents do what is claimed or whether actions described have unintended consequences. SUSE LLC, its affiliates, the authors, and the translators may not be held liable for possible errors or the consequences thereof.

Below we draw your attention to the license under which the articles are published.