Signed kernel module support

Since Linux kernel version 3.7 onwards, support has been added for signed kernel modules. When enabled, the Linux kernel will only load kernel modules that are digitally signed with the proper key. This allows further hardening of the system by disallowing unsigned kernel modules, or kernel modules signed with the wrong key, to be loaded. Malicious kernel modules are a common method for loading rootkits on a Linux system.

Enabling module signature verification
Enabling support is a matter of toggling a few settings in the Linux kernel configuration. Unless you want to use your own keypair, this is all that has to be done to enable kernel module support.

Configuring module signature verification
Module signature verification is a kernel feature, so has to be enabled through the Linux kernel configuration. You can find the necessary options under Enable loadable module support.

The option Module signature verification (CONFIG_MODULE_SIG) enables the module signature verification in the Linux kernel. It supports two approaches on signed module support: a rather permissive one and a strict one. By default, the permissive approach is used, which means that the Linux kernel module either has to have a valid signature, or no signature. With the strict approach, a valid signature must be present. In the above example, the strict approach is used by selecting Require modules to be validly signed (CONFIG_MODULE_SIG_FORCE). Another way of enabling this strict approach is to set the kernel boot option.

When building the Linux kernel, the kernel modules will not be signed automatically unless you select Automatically sign all modules (CONFIG_MODULE_SIG_ALL).

Finally, we need to select the hash algorithm to use with the cryptographic signature. In the above example, we use SHA-512.

Building the kernel with proper keys
When the Linux kernel is building with module signature verification support enabled, then you can use your own keys or have the Linux kernel build infrastructure create a set for you. If you want the Linux kernel build infrastructure to create it for you, just continue as you always do with a  and. At the end of the build process, you will notice that and  will be available on the root of the Linux kernel sources.

If we want to use our own keys, you can use  to create a key pair (private key and public key). The following command, taken from, creates such a key pair.

The resulting files need to be stored as and  in the root of the Linux kernel source tree.

The public key part will be build inside the Linux kernel. If you configured the kernel to sign modules, this signing will take place during the  part.

Validating module signature support
Reboot with the newly configured kernel. In the output of  you should be able to confirm that the proper certificate is loaded:

If CONFIG_KEYS_DEBUG_PROC_KEYS is enabled, then root user can view certificate in /proc/keys file:

modinfo should display same key:

The kernel modules have the digital signature appended at the end. A simple  can confirm if a signature is present or not:

The string  at the end confirms that a signature is present. Of course, it does not confirm that the signature is valid or not.

To remove the signature, we can use the  command:

If we try to load this module now, we get a failure:

This confirms that modules without a signature are not loaded.

Administering kernel module signatures
Once the kernel boots and we have validated that the signed kernel module support works, it is important to correctly handle the keys themselves.

Protecting the private key
The private key, stored as, needs to be moved to a secure location (unless you will be creating new keys for new kernels, in which case the file can be removed). Do not keep it at on production systems as malware can then easily use this key to sign the malicious kernel modules (such as rootkits) and compromise the system further.

Manually signing modules
If you ever need to manually sign a kernel module, you can use the script available in the Linux kernel source tree. It requires four arguments:


 * 1) The hash algorithm to use, such as
 * 2) The private key location
 * 3) The certificate (which includes the public key) location
 * 4) The kernel module to sign

In this case, the key pair does not need to be named and such, nor do they need to be in the root of the Linux kernel source tree location.

Distributing the kernel and modules
If we create a kernel package through, the modules in it will be signed already so we do not need to manually sign them afterwards. The signing keys themselves are not distributed with it.

External resources

 * Booting a self-signed Linux kernel - Greg Kroah-Hartman describes how to boot a self-signed Linux kernel from EFI. As having signed kernel module support is only secure if the Linux kernel is trusted, this is an important (and related) feature to work with.