Product SiteDocumentation Site

23.7.2. Kernel Module Authentication

In Fedora, when a kernel module is loaded, the module's signature is checked using the public X.509 keys on the kernel's system key ring, excluding those keys that are on the kernel's system black list key ring.

23.7.2.1. Sources For Public Keys Used To Authenticate Kernel Modules

During boot, the kernel loads X.509 keys into the system key ring or the system black list key ring from a set of persistent key stores as shown in Table 23.2, “Sources For System Key Rings”
Table 23.2. Sources For System Key Rings
Source of X.509 Keys User Ability to Add Keys UEFI Secure Boot State Keys Loaded During Boot
Embedded in kernel No - .system_keyring
UEFI Secure Boot "db" Limited Not enabled No
Enabled .system_keyring
UEFI Secure Boot "dbx" Limited Not enabled No
Enabled .system_keyring
Embedded in shim.efi boot loader No Not enabled No
Enabled .system_keyring
Machine Owner Key (MOK) list Yes Not enabled No
Enabled .system_keyring

Note that if the system is not UEFI-based or if UEFI Secure Boot is not enabled, then only the keys that are embedded in the kernel are loaded onto the system key ring and you have no ability to augment that set of keys without rebuilding the kernel. The system black list key ring is a list of X.509 keys which have been revoked. If your module is signed by a key on the black list then it will fail authentication even if your public key is in the system key ring.
You can display information about the keys on the system key rings using the keyctl utility. The following is abbreviated example output from a Fedora system where UEFI Secure Boot is not enabled.
~]# keyctl list %:.system_keyring
1 key in keyring:
 61139991: ---lswrv     0     0 asymmetric: Fedora kernel signing key: 1fc9e68f7419556348fdee2fdeb7ff9da6337b
The following is abbreviated example output from a Fedora system where UEFI Secure Boot is enabled.
~]# keyctl list %:.system_keyring
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...
The above output shows the addition of two keys from the UEFI Secure Boot "db" keys plus the Red Hat Secure Boot (CA key 1) which is embedded in the shim.efi boot loader. You can also look for the kernel console messages that identify the keys with an UEFI Secure Boot related source, that is UEFI Secure Boot db, embedded shim, and MOK list.
~]# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...

23.7.2.2.  Kernel Module Authentication Requirements

If UEFI Secure Boot is enabled or if the module.sig_enforce kernel parameter has been specified, then only signed kernel modules that are authenticated using a key on the system key ring can be successfully loaded.[4] If UEFI Secure Boot is disabled and if the module.sig_enforce kernel parameter has not been specified, then unsigned kernel modules and signed kernel modules without a public key can be successfully loaded. This is summarized in Table 23.3, “Kernel Module Authentication Requirements for Loading”.
Table 23.3. Kernel Module Authentication Requirements for Loading
Module Signed Public Key Found and Signature Valid UEFI Secure Boot State module.sig_enforce Module Load Kernel Tainted
Unsigned - Not enabled Not enabled Succeeds Yes
Not enabled Enabled Fails
Enabled - Fails -
Signed No Not enabled Not enabled Succeeds Yes
Not enabled Enabled Fails -
Enabled - Fails -
Signed Yes Not enabled Not enabled Succeeds No
Not enabled Enabled Succeeds No
Enabled - Succeeds No

Subsequent sections will describe how to generate a public and private X.509 key pair, how to use the private key to sign a kernel module, and how to enroll the public key into a source for the system key ring.


[4] Provided that the public key is not on the system black list key ring.