1. Working With UEFI Secure Boot
  2. Signing Kernel Images and Kernel Modules for Use With Secure Boot

3 Signing Kernel Images and Kernel Modules for Use With Secure Boot

This chapter provides instructions on signing kernel modules for Secure Boot.

Attention:

Oracle doesn't support any modules that are built from source directly outside of Oracle's offical release mechanisms. For aid with these modules, you would need to contact the hardware vendor.

A system in Secure Boot mode only loads boot loaders and kernels that have been signed by Oracle. However, you might need to build and install a third-party module to enable particular hardware on a deployed system. If you still require UEFI Secure Boot, the module must be signed with a key that can be validated against a certificate within the UEFI Secure Boot key database or within the Shim MOK Manager key database so that the module is recognized at boot.

Note that if you're running UEK R6, UEK R6U1, or UEK R6U2 the key that's used to sign the module must be compiled into the kernel and then the kernel must be signed again. Note also that the kernel signing key must be added to the either the UEFI or MOK database. As of UEK R6U3, you can load external modules under Secure Boot if the signing key is already enrolled in the MOK database.

Important:

Using the MOK utility on a server depends on server firmware implementation and configuration. Check that the server supports this before manually updating signature keys used for UEFI Secure Boot. If you're unsure, don't follow the instructions provided here.

Adding certificates to the MOK database by using the MOK utility requires that you have physical access to the system so that you can complete the enrollment request after the Shim is loaded by UEFI. Don't follow the instructions in this document if you have no physical access to the system.

Because of differences in kernel releases, instructions on how to sign modules differ depending on the kernel version on the system. In particular, the key signature type within the module signature has changed from X.509 to PKCS#7. Therefore, although the process to sign the module by using the kernel-provided sign-file utility is still used, you might be required to use a utility more appropriate to the specific kernel for which a module is being signed.

More importantly, UEK R6 kernels earlier than UEK R6U3 don't offer the same level of trust for the keys that are available for UEFI or the Shim MokManager key database. Thus, for systems running UEK R6, UEK R6U1, or UEK R6U2, a different set of procedures exists for signing kernel images and modules for use with Secure Boot. See Setting Kernel Module Certificate Trust for UEK R6.

Requirements for Signing Kernel Images and Kernel Modules

Before you can sign a module, you must install several required packages, including the kernel source for the kernel where the module is loaded. You also require a signing certificate for a key pair that you have created for this purpose.

Signing kernel images and kernel modules have the following requirements:

Installing Required Packages

A standard minimal installation of the latest Oracle Linux 7, Oracle Linux 8, or Oracle Linux 9 update release suffices for this procedure. The steps assume that the system is using UEK as the operating environment.

Note:

If the system is running Oracle Linux 7, replace the dnf command in the steps with the proper yum command syntax.

  1. Obtain the package that contains the system's kernel source.

    sudo dnf install kernel-uek-devel

    If you're using RHCK, the kernel source is in the kernel-devel package.

  2. Update the system to ensure that you have the most recent kernel and related packages. 

    sudo dnf update

  3. Reboot the system.

    This step is practical in case the kernel is included in the system update. By rebooting, you avoid confusion around the kernel version that you're working with and the kernel running on the system when you begin kernel-signing operations.

  4. Oracle Linux 7 systems only: Enable the optional_latest repository in the yum configuration. 

    sudo yum-config-manager --enable ol7_optional_latest

  5. Install the required utilities for performing module signing operations. 

    sudo dnf install openssl keyutils mokutil pesign

  6. If you need to build module source, you might install the Development Tools group to ensure that build tools are available for use, for example: 

    sudo dnf group install "Development Tools"

Generating a Signing Certificate

If you don't already have a signing certificate to be used for signing third-party modules or kernel images, you can generate one by using the OpenSSL utilities. For more information about OpenSSL and the public key infrastructure, see Oracle Linux: Managing Certificates and Public Key Infrastructure.

  1. Create a configuration file that OpenSSL can use to obtain default values when generating certificates.

    As best practice, create the file in /etc/ssl/x509.conf with the rest of the OpenSSL configuration. The file would resemble the following example: 

    [ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no
string_mask = utf8only
x509_extensions = extensions

[ req_distinguished_name ]
O = Module Signing Example
CN = Module Signing Example Key
emailAddress = first.last@example.com

[ extensions ]
basicConstraints=critical,CA:TRUE
keyUsage=digitalSignature
extendedKeyUsage = codeSigning
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always

  2. Generate a new key pair using this configuration file: 

    sudo openssl req -x509 -new -nodes -utf8 -sha512 -days 3650 -batch -config /etc/ssl/x509.conf -outform DER -out /etc/ssl/certs/pubkey.der -keyout /etc/ssl/certs/priv.key

    This sample command creates a signing certificate that is valid for 10 years (3,650 days). Ensure that the keys are adequately protected.

  3. Export the certificate in PEM format: 

    sudo openssl x509 -inform DER -in /etc/ssl/certs/pubkey.der -out /etc/ssl/certs/pubkey.pem

Signing the Kernel for Secure Boot

UEFI Secure Boot requires that kernels are signed with a trusted certificate to prevent attackers from installing and running unauthorized OSs.

Oracle signs kernel releases that are provided through official software channels to verify their origin and integrity. For a custom kernel to perform the boot or kexec operations, you must sign the kernel image by using the signing certificate that you created and confirm that you trust kernel images that are signed with that certificate.

Signing the kernel for Secure Boot involves the following tasks:

  1. Configuring an NSS Database

  2. Signing the Kernel Image

  3. Updating the MOK Database

Configuring an NSS Database

The NSS database stores complete sets of keys to which the tool for signing kernels refers to obtain the kernel signing key.

  1. Configure an NSS database.

    sudo certutil -d . -N

  2. Create a password for the database as prompted.

  3. Export a PKCS#2 version of the kernel signing key.

    NSS utilities are only capable of working with PKCS#12 formatted key files. Thus, you need to perform this step so that you can sign the kernel image. 

    sudo openssl pkcs12 -export -inkey /etc/ssl/certs/priv.key -in /etc/ssl/certs/pubkey.pem -name cert -out /etc/ssl/certs/cert.p12

  4. Enter the export password as prompted.

    The password refers to the password for the PKCS#12 archive. To be practical, make this password match the password for the NSS database.

  5. Add or import the PKCS#12 version of the kernel signing key to the new database.

    sudo pk12util -d . -i cert.p12

  6. Enter the passwords as prompted.

    Two password prompts are displayed: first, for the NSS database, then for the PKCS#12 archive. 

    Enter Password or Pin for "NSS Certificate DB":
Enter password for PKCS12 file:
pk12util: PKCS12 IMPORT SUCCESSFUL

Signing the Kernel Image

In this task, you use the pesign utility to re-sign the kernel with a new signature by using the signing key in the NSS database.

  1. Remove the existing PE signature.

    sudo pesign -u 0 -i /boot/vmlinuz-$(uname -r) --remove-signature -o vmlinuz.unsigned

  2. Assign a new signature based on the kernel signing key in the NSS database.

    sudo pesign -n . -c cert -i vmlinuz.unsigned -o vmlinuz.signed -s

  3. Enter the password as prompted.

    The password of the NSS certificate database is the one that you created in Configuring an NSS Database.

  4. Copy the signed kernel back to /boot. 

    sudo cp -bf vmlinuz.signed /boot/vmlinuz-$(uname -r)

    The -b option in the command creates a backup of the original kernel image.

Updating the MOK Database

Because the key that you created isn't included in the UEFI Secure Boot Key Database, you must enroll it into the MOK database in the Shim.

  1. Import the key with the following command:

    sudo mokutil --import /etc/ssl/certs/pubkey.der

    The command prompts you for a single use password that you use when the MOK Management service enrolls the key after you reboot the system.

  2. Reboot the system.

    The UEFI Shim automatically starts the Shim UEFI key manager at boot. Ensure that you hit a key within 10 seconds to interrupt the boot process to enroll the MOK key you created.

  3. Press any key to perform MOK Management.

  4. Select Enroll MOK from the menu.

  5. Select View key 0 from the menu to display the key details.

  6. Verify that the values presented match the key that you used to sign the module and that you inserted into the kernel image, then press any key to return to the Enroll MOK menu.

  7. Select Continue from the menu.

    The Enroll the key(s)? screen is displayed.

  8. Select Yes to enroll the key.

  9. At the password prompt, enter the password that you used when you imported the key at the beginning of this procedure.

    The key is enrolled within the UEFI Secure Boot key database.

  10. When the Perform MOK management screen is displayed, select Reboot from the menu.

Signing the Kernel Module for Secure Boot

Note:

If you're running UEK R6, UEK R6U1, or UEK R6U2, go instead to Setting Kernel Module Certificate Trust for UEK R6. That section contains added tasks to complete Secure Boot setup for these UEK R6 kernels.

UEFI Secure Boot requires that kernel modules are signed with a trusted certificate to prevent attackers from installing and running unauthorized OSs and malicious drivers.

Oracle signs kernel releases that are provided through official software channels to verify their origin and integrity. However, to install other drivers, you must create signing certificates for them, sign the relevant kernel modules, and confirm that you trust the kernel modules that are signed with that certificate.

The secure boot implementation in UEK R6U3 is updated to trust modules signed using platform certificates that are available in the UEFI and MOK databases. Thus, beginning with UEK R6U3, the key for signing the module itself is enrolled into the database.

For UEK versions except UEK R6, UEK R6U1, and UEK R6U2, signing the kernel module involves the following tasks:

  1. Signing the Kernel Module

  2. Updating the MOK Database with the Kernel Module Certificate

Signing the Kernel Module

The sign-file utility ensures that the module is signed correctly for the kernel. This utility is provided within the kernel source.

Caution:

The instructions provided here assume that you're signing a module for the currently running kernel. If you're signing a module for a different kernel, you must provide the path to the sign-file utility within the correct kernel version source. Otherwise, the signature type for the module for that kernel might not align correctly with the expected signature type.

  1. Ensure that module is already installed in /lib/modules/.

  2. Run the sign-file utility for the currently running kernel. 

    sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 /etc/ssl/certs/priv.key /etc/ssl/certs/pubkey.der /lib/modules/$(uname -r)/path/to/module.ko

  3. (Optional) Check the signature information of the module.

    modinfo module

    For example, a module named hello might display the following output: 

    filename:       /lib/modules/5.4.17-2036.103.3.1.el8uek.x86_64/extra/hello.ko
description:    Hello World Linux Kernel Module
author:         A.Developer
license:        GPL
srcversion:     D51FB4CF0B86314953EE797
depends:        
retpoline:      Y
name:           hello
vermagic:       5.4.17-2036.103.3.1.el8uek.x86_64 SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         Module Signing Example Key
sig_key:        AB:2C:E3:AB:87:D9:9C:6A:31:B8:80:20:D4:92:25:F3:9A:26:DC
sig_hashalgo:   sha512
signature:   9F:B0:25:CB:14:C1:C7:10:7F:60:1E:E6:66:82:64:58:91:1F:01:A5:
		D9:03:1B:9C:2D:42:00:45:78:2B:FA:70:F8:C7:3B:1A:A2:42:00:09:
		33:E0:81:1D:C6:E6:46:A5:FE:8B:9F:8C:3D:4E:A1:3A:05:52:ED:F6:
		25:F9:88:98:D3:70:78:1D:7E:63:F3:73:C8:C8:14:C2:3A:52:B4:8F:
		4C:8D:80:D9:0D:24:F8:C9:B1:28:82:B6:A9:27:56:C6:86:80:25:A5:
		75:C8:78:A9:30:BD:01:4C:DD:43:7F:FD:41:98:2C:59:21:7D:39:17:
		EC:2C:C1:65:1D:95:F0:09:C7:F6:45:10:83:15:78:A2:EE:D4:73:79:
		B2:F0:57:C1:96:B3:4C:43:B8:D1:87:94:50:61:D6:EC:50:2B:6A:6C:
		5C:C1:3E:8C:CB:6F:19:DC:EF:6C:12:07:03:99:B7:B3:22:0B:F6:AC:
		CB:40:C6:34:15:EA:1F:88:D4:4E:1C:87:2D:5A:92:F7:12:A6:E7:91:
		B3:80:AA:80:8F:49:B7:F0:F0:97:05:09:7A:65:30:4A:AE:10:BE:9F:
		6A:E4:B2:24:BE:1A:21:D0:F6:15:05:DA:2C:64:EA:B2:8E:AC:6F:18:
		40:65:21:F6:AA:17:31:AE:3F:3A:43:DB:A8:BC:71:79:EF:11:18:DE:
		86:EE:74:2A:E0:44:FC:B3:FF:CB:CB:F0:CA:BD:7B:A1:57:84:D8:A6:
		91:E5:B8:EF:1B:8A:63:16:43:03:AF:C4:C7:BF:52:9A:A9:23:75:C6:
		42:54:69:4E:3D:51:56:5A:9D:9B:C7:11:5E:9A:30:87:5F:F3:5E:C3:
		AE:2C:1D:6F:C9:4D:15:E5:CF:EC:46:0E:EF:D9:BB:2F:DF:DF:54:EA:
		F3:B6:9C:A3:6F:80:19:B9:DF:FA:2A:30:4E:2E:70:74:11:F9:5C:F6:
		EE:1A:DF:86:C4:2B:36:7E:B4:A4:D4:7E:30:19:1A:D1:92:D3:A7:FB:
		53:BF:67:C3:65:9E:4B:92:F0:6C:D4:6C:05:9B:0F:BF:D1:5B:CB:86:
		AE:68:00:AE:43:53:8B:7D:7E:18:20:CD:65:68:6C:4A:0D:93:A4:54:
		09:39:9C:D3:BD:CD:17:B6:8A:D3:62:0C:CA:A8:FD:1A:52:CE:29:A0:
		93:BF:AD:D2:58:3F:EA:4E:4B:50:31:6F:F6:B2:1E:87:C4:0A:9D:E4:
		43:E9:C7:CA:E9:CB:EF:A6:61:5B:DA:01:33:37:66:DB:16:8D:7C:D7:
		30:39:57:D4:0C:1A:54:AE:91:7B:FE:35:10:CC:34:03:99:EA:5A:57:
		E0:95:61:02:42:95:A2:F5:2E:72:30:95

Updating the MOK Database with the Kernel Module Certificate

Because the key that you created isn't included in the UEFI Secure Boot Key Database, you must enroll it into the MOK database in the Shim.

  1. Run the following command:

    sudo mokutil --import /etc/ssl/certs/pubkey.der

    The command prompts you for a single use password that you use when the MOK Management service enrolls the key after you reboot the system.

  2. Reboot the system.

    The UEFI Shim automatically starts the Shim UEFI key manager at boot. Ensure that you hit a key within 10 seconds to interrupt the boot process to enroll the MOK key you created.

  3. Press any key to perform MOK Management.

  4. Select Enroll MOK from the menu.

  5. Select View key 0 from the menu to display the key details.

  6. Verify that the values presented match the key that you used to sign the module and that you inserted into the kernel image, then press any key to return to the Enroll MOK menu.

  7. Select Continue from the menu.

    The Enroll the key(s)? screen is displayed.

  8. Select Yes to enroll the key.

  9. At the password prompt, enter the password that you used when you imported the key at the beginning of this procedure.

    The key is enrolled within the UEFI Secure Boot key database.

  10. When the Perform MOK management screen is displayed, select Reboot from the menu.

Setting Kernel Module Certificate Trust for UEK R6

The information in this section applies to kernel modules with any UEK R6 kernels before UEK R6U3, namely:

  • UEK R6

  • UEK R6U1

  • UEK R6U2

With these UEK R6 kernels, after a module is signed, the key that was used to sign it must be inserted into the compiled kernel image. UEK R6 only trusts modules that are signed with keys that are listed in the kernel built-in, trusted keyring. Thus, the updated kernel image must be signed again. Further, the customer owned certificate that's used to sign the kernel must then be added to the UEFI or MOK database. In this manner, the kernel image becomes trusted and can boot in Secure Boot mode.

Setting the kernel module certificate trust for the listed kernels involves the following tasks:

  1. Signing the Kernel Module

    This task is the same as the first task listed under Signing the Kernel Module for Secure Boot.

  2. Inserting the Module Certificate in the Kernel Image

  3. Signing the Kernel Image

  4. Updating the MOK database

    This task is the same as the second task listed under Signing the Kernel Module for Secure Boot.

Signing the Kernel Module

The sign-file utility ensures that the module is signed correctly for the kernel. This utility is provided within the kernel source.

Caution:

The instructions provided here assume that you're signing a module for the currently running kernel. If you're signing a module for a different kernel, you must provide the path to the sign-file utility within the correct kernel version source. Otherwise, the signature type for the module for that kernel might not align correctly with the expected signature type.

  1. Ensure that module is already installed in /lib/modules/.

  2. Run the sign-file utility for the currently running kernel. 

    sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 /etc/ssl/certs/priv.key /etc/ssl/certs/pubkey.der /lib/modules/$(uname -r)/path/to/module.ko

  3. (Optional) Check the signature information of the module.

    modinfo module

    For example, a module named hello might display the following output: 

    filename:       /lib/modules/5.4.17-2036.103.3.1.el8uek.x86_64/extra/hello.ko
description:    Hello World Linux Kernel Module
author:         A.Developer
license:        GPL
srcversion:     D51FB4CF0B86314953EE797
depends:        
retpoline:      Y
name:           hello
vermagic:       5.4.17-2036.103.3.1.el8uek.x86_64 SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         Module Signing Example Key
sig_key:        AB:2C:E3:AB:87:D9:9C:6A:31:B8:80:20:D4:92:25:F3:9A:26:DC
sig_hashalgo:   sha512
signature:   9F:B0:25:CB:14:C1:C7:10:7F:60:1E:E6:66:82:64:58:91:1F:01:A5:
		D9:03:1B:9C:2D:42:00:45:78:2B:FA:70:F8:C7:3B:1A:A2:42:00:09:
		33:E0:81:1D:C6:E6:46:A5:FE:8B:9F:8C:3D:4E:A1:3A:05:52:ED:F6:
		25:F9:88:98:D3:70:78:1D:7E:63:F3:73:C8:C8:14:C2:3A:52:B4:8F:
		4C:8D:80:D9:0D:24:F8:C9:B1:28:82:B6:A9:27:56:C6:86:80:25:A5:
		75:C8:78:A9:30:BD:01:4C:DD:43:7F:FD:41:98:2C:59:21:7D:39:17:
		EC:2C:C1:65:1D:95:F0:09:C7:F6:45:10:83:15:78:A2:EE:D4:73:79:
		B2:F0:57:C1:96:B3:4C:43:B8:D1:87:94:50:61:D6:EC:50:2B:6A:6C:
		5C:C1:3E:8C:CB:6F:19:DC:EF:6C:12:07:03:99:B7:B3:22:0B:F6:AC:
		CB:40:C6:34:15:EA:1F:88:D4:4E:1C:87:2D:5A:92:F7:12:A6:E7:91:
		B3:80:AA:80:8F:49:B7:F0:F0:97:05:09:7A:65:30:4A:AE:10:BE:9F:
		6A:E4:B2:24:BE:1A:21:D0:F6:15:05:DA:2C:64:EA:B2:8E:AC:6F:18:
		40:65:21:F6:AA:17:31:AE:3F:3A:43:DB:A8:BC:71:79:EF:11:18:DE:
		86:EE:74:2A:E0:44:FC:B3:FF:CB:CB:F0:CA:BD:7B:A1:57:84:D8:A6:
		91:E5:B8:EF:1B:8A:63:16:43:03:AF:C4:C7:BF:52:9A:A9:23:75:C6:
		42:54:69:4E:3D:51:56:5A:9D:9B:C7:11:5E:9A:30:87:5F:F3:5E:C3:
		AE:2C:1D:6F:C9:4D:15:E5:CF:EC:46:0E:EF:D9:BB:2F:DF:DF:54:EA:
		F3:B6:9C:A3:6F:80:19:B9:DF:FA:2A:30:4E:2E:70:74:11:F9:5C:F6:
		EE:1A:DF:86:C4:2B:36:7E:B4:A4:D4:7E:30:19:1A:D1:92:D3:A7:FB:
		53:BF:67:C3:65:9E:4B:92:F0:6C:D4:6C:05:9B:0F:BF:D1:5B:CB:86:
		AE:68:00:AE:43:53:8B:7D:7E:18:20:CD:65:68:6C:4A:0D:93:A4:54:
		09:39:9C:D3:BD:CD:17:B6:8A:D3:62:0C:CA:A8:FD:1A:52:CE:29:A0:
		93:BF:AD:D2:58:3F:EA:4E:4B:50:31:6F:F6:B2:1E:87:C4:0A:9D:E4:
		43:E9:C7:CA:E9:CB:EF:A6:61:5B:DA:01:33:37:66:DB:16:8D:7C:D7:
		30:39:57:D4:0C:1A:54:AE:91:7B:FE:35:10:CC:34:03:99:EA:5A:57:
		E0:95:61:02:42:95:A2:F5:2E:72:30:95

Inserting the Module Certificate in the Kernel Image

  1. Go to the directory where the certificates are stored.

    cd /etc/ssl/cert

  2. Insert the raw DER certificate that was used to sign the module into the compressed kernel boot image.

    sudo /usr/src/kernels/$(uname -r)/scripts/insert-sys-cert -s /boot/System.map-$(uname -r) -z /boot/vmlinuz-$(uname -r) -c pubkey.der
    INFO:    Executing: gunzip <vmlinux-8ig4vO >vmlinux-QyW44r
WARNING: Could not find the symbol table.
INFO:    sym:    system_extra_cert
INFO:    addr:   0xffffffff82891616
INFO:    size:   8194
INFO:    offset: 0x1c91616
INFO:    sym:    system_extra_cert_used
INFO:    addr:   0xffffffff82893618
INFO:    size:   0
INFO:    offset: 0x1c93618
INFO:    sym:    system_certificate_list_size
INFO:    addr:   0xffffffff82893620
INFO:    size:   0
INFO:    offset: 0x1c93620
INFO:    Inserted the contents of pubkey.der into ffffffff82891616.
INFO:    Used 1481 bytes out of 8194 bytes reserved.
INFO:    Executing: gzip -n -f -9 <vmlinux-QyW44r >vmlinux-M5uNR6

Important:

Only a single custom certificate can be added to the kernel because the compressed size of the kernel's boot image can not increase. Do not add multiple certificates to the kernel boot image.

Signing the Kernel Image

In this task, you use the pesign utility to re-sign the kernel with a new signature by using the signing key in the NSS database.

  1. Remove the existing PE signature.

    sudo pesign -u 0 -i /boot/vmlinuz-$(uname -r) --remove-signature -o vmlinuz.unsigned

  2. Assign a new signature based on the kernel signing key in the NSS database.

    sudo pesign -n . -c cert -i vmlinuz.unsigned -o vmlinuz.signed -s

  3. Enter the password as prompted.

    The password of the NSS certificate database is the one that you created in Configuring an NSS Database.

  4. Copy the signed kernel back to /boot. 

    sudo cp -bf vmlinuz.signed /boot/vmlinuz-$(uname -r)

    The -b option in the command creates a backup of the original kernel image.

Updating the MOK Database

Because the key that you created isn't included in the UEFI Secure Boot Key Database, you must enroll it into the MOK database in the Shim.

  1. Import the key with the following command:

    sudo mokutil --import /etc/ssl/certs/pubkey.der

    The command prompts you for a single use password that you use when the MOK Management service enrolls the key after you reboot the system.

  2. Reboot the system.

    The UEFI Shim automatically starts the Shim UEFI key manager at boot. Ensure that you hit a key within 10 seconds to interrupt the boot process to enroll the MOK key you created.

  3. Press any key to perform MOK Management.

  4. Select Enroll MOK from the menu.

  5. Select View key 0 from the menu to display the key details.

  6. Verify that the values presented match the key that you used to sign the module and that you inserted into the kernel image, then press any key to return to the Enroll MOK menu.

  7. Select Continue from the menu.

    The Enroll the key(s)? screen is displayed.

  8. Select Yes to enroll the key.

  9. At the password prompt, enter the password that you used when you imported the key at the beginning of this procedure.

    The key is enrolled within the UEFI Secure Boot key database.

  10. When the Perform MOK management screen is displayed, select Reboot from the menu.

Validating That a Key Is Trusted

After the system is booted, you can validate whether a key is included in the appropriate kernel keyring. Validation depends on the kernel version that you're running. Also, the keyring name that you need to check varies, as the implementation has changed across kernel versions.

If the key that was generated for signing custom modules is listed within the correct keyring, you can load modules that are signed with this key while in Secure Boot mode.

UEK R7 Releases

UEK R7 introduces the .machine keyring. Keys within the .machine keyring are trusted for use within the Oracle Linux kernel. All of the MOK keys are loaded into this keyring at boot.

Just like the .builtin_trusted_keys keyring, the new .machine keyring is linked to the .secondary_trusted_keys keyring. With this link in place, the .machine keyring is referenced when the kernel uses the .secondary_trusted_keys keyring to validate a signed kernel module, as illustrated by the following example: 

sudo keyctl show %:.secondary_trusted_keys
Keyring
 772746105 ---lswrv      0     0  keyring: .secondary_trusted_keys
 252396885 ---lswrv      0     0   \_ keyring: .builtin_trusted_keys
 660166481 ---lswrv      0     0   |   \_ asymmetric: Oracle CA Server: 702a35b0d12005e5010c0614f7b8abf7c5bd5f73
  86702374 ---lswrv      0     0   |   \_ asymmetric: Oracle IMA signing CA: a2f28976a05984028f7d1a4904ae14e8e468e551
 247354640 ---lswrv      0     0   |   \_ asymmetric: Oracle America, Inc.: Ksplice Kernel Module Signing Key: 09010ebef5545fa7c54b626ef518e077b5b1ee4c
 264616160 ---lswrv      0     0   |   \_ asymmetric: Oracle Linux Kernel Module Signing Key: 2bb352412969a3653f0eb6021763408ebb9bb5ab
 772320403 ---lswrv      0     0   \_ keyring: .machine
 450491670 ---lswrv      0     0       \_ asymmetric: Oracle America, Inc.: 7c552922286d66bcb33c53d7ee0f1cd716ecdc63
 100307441 ---lswrv      0     0       \_ asymmetric: Oracle America, Inc.: 39bff3f0f578f26e527321cafda2a9cdbd71143c
 688922247 ---lswrv      0     0       \_ asymmetric: Oracle America, Inc.: 4ff35c3e09ce586fa776d56468d86b022af272f1

UEK R6U3 and Later UEK R6 Updates (Includes RHCK on Oracle Linux 8 and Oracle Linux 9)

Keys within both the builtin_trusted_keys keyring and the platform keyring are trusted for both module signing and for the kexec tools. You can follow the standard procedure to sign a module and add it to the MOK database for the key to appear in the platform keyring. The keyring is then automatically trusted.

Because a key can be loaded into the builtin_trusted_keys keyring, check both keyrings for the module signing key, for example: 

sudo keyctl show %:.builtin_trusted_keys
Keyring
 441234704 ---lswrv      0     0  keyring: .builtin_trusted_keys
 798307349 ---lswrv      0     0   \_ asymmetric: Oracle CA Server: 32a7ceb6c56614c69b4729b455254bfaf09569a4
 277992501 ---lswrv      0     0   \_ asymmetric: Oracle Linux RHCK Module Signing Key: dd995b155c19b3a7c3ef7707b969e25f9639666e
1000618915 ---lswrv      0     0   \_ asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b72e3852e2014c3a676fc8
 199403819 ---lswrv      0     0   \_ asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87362bc7229d9f465321773dfd1f77a80


sudo keyctl show %:.platform
Keyring
 705628740 ---lswrv      0     0  keyring: .platform
  89698906 ---lswrv      0     0   \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
 497244381 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: d6ee3a06a222bf4244b8986a531046e59c14eeef
 710039804 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: c65d1d746ae4cb127762e1dbd7ade48215703c5c
 730271863 ---lswrv      0     0   \_ asymmetric: Oracle America Inc.: 2e7c1720d1c5df5254cc93d6decaa75e49620cf8
 535985802 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: 795c5945e7cb2b6773b7797571413e3695062514
 607819007 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: f9aec43f7480c408d681db3d6f19f54d6e396ff4
  99739320 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: 430c85cb8b531c3d7b8c44adfafc2e5d49bb89d4
 231916335 ---lswrv      0     0   \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
 866576656 ---lswrv      0     0   \_ asymmetric: Oracle Linux Test Certificate: d30dffa37bec20ecfb1d3caee53cd746282e8cad
 230958440 ---lswrv      0     0   \_ asymmetric: Module Signing Example Key: a43b4e638874b0656db2bc26216f56c0ac39f72b

UEK R6 releases prior to UEK R6U3

For UEK R6 releases before UEK R6U3, only those keys that are listed in the kernel builtin_trusted_keys keyring are trusted for module signing. For this reason, module signing keys are added to the kernel image as part of the process for signing modules.

To check this keyring whether the module signing key that you created is listed, type: 

sudo keyctl show %:.builtin_trusted_keys
Keyring
 892034081 ---lswrv      0     0  keyring: .builtin_trusted_keys
 367808024 ---lswrv      0     0   \_ asymmetric: Oracle CA Server: fbcd3d4d950c6b2b0e01f0a146c5a4e3855ae704
 230958440 ---lswrv      0     0   \_ asymmetric: Module Signing Example Key: a43b4e638874b0656db2bc26216f56c0ac39f72b
 408597579 ---lswrv      0     0   \_ asymmetric: Oracle America, Inc.: Ksplice Kernel Module Signing Key: 09010ebef5545fa7c54b626ef518e077b5b1ee4c
 839574974 ---lswrv      0     0   \_ asymmetric: Oracle Linux Kernel Module Signing Key: 2bb352412969a3653f0eb6021763408ebb9bb5ab

UEK R5

For UEK R5, the built-in kernel keys, the UEFI Secure Boot database keys, and the MOK database keys all appear in the kernel keyring, which is named secondary_trusted_keys. Keys in this keyring are trusted for module signing and also for the kexec tools.

To check this keyring whether the module signing key that you created is listed, type:

sudo keyctl show %:.secondary_trusted_keys
Keyring
 847333689 --alswrv      0     0  keyring: .secondary_trusted_keys
 304199016 --alswrv      0     0   \_ keyring: .builtin_trusted_keys
1008872915 --alswrv      0     0   |   \_ asymmetric: Oracle CA Server: 911ccad43f8dcc5e169cf7d89af9d28edd7e68aa
 252474061 --alswrv      0     0   |   \_ asymmetric: Oracle America, Inc.: Ksplice Kernel Module Signing Key: 09010ebef5545fa7c54b626ef518e077b5b1ee4c
 164249372 --alswrv      0     0   |   \_ asymmetric: Oracle Linux Kernel Module Signing Key: 2bb352412969a3653f0eb6021763408ebb9bb5ab
 567204509 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: 7b13dad59daa6adeacfff53c9a3b7e4f61fe068a
 202164133 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: 9c68fc11b0f85979388df4c8cc2c9c098928eda9
 600928065 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: fe1ea0d2db0446565aec7d637e2509c9900398c1
1023599957 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: bc5971954c749d3d309852ef0f3c236fa498e8f6
 837499579 --alswrv      0     0   \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
 230958440 ---lswrv      0     0   \_ asymmetric: Module Signing Example Key: a43b4e638874b0656db2bc26216f56c0ac39f72b
 260150072 --alswrv      0     0   \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53

UEK R4 and RHCK on Oracle Linux 7

For UEK R4 and RHCK (3.10.0) on Oracle Linux 7 the built-in kernel keys, the UEFI Secure Boot database keys, and the MOK database keys all appear in the kernel keyring, which is named system_keyring. Keys in this keyring are trusted for module signing and also for the kexec tools.

To check this keyring whether the module signing key that you created is listed, type: 

sudo keyctl show %:.system_keyring
Keyring
 490420691 --alswrv      0     0  keyring: .system_keyring
 985562533 --alswrv      0     0   \_ asymmetric: Oracle America, Inc.: Ksplice Kernel Module Signing Key: 09010ebef5545fa7c54b626ef518e077b5b1ee4c
 117527109 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: 7b13dad59daa6adeacfff53c9a3b7e4f61fe068a
 752001237 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: 9c68fc11b0f85979388df4c8cc2c9c098928eda9
 405618281 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: fe1ea0d2db0446565aec7d637e2509c9900398c1
1018396318 --alswrv      0     0   \_ asymmetric: Oracle America Inc.: bc5971954c749d3d309852ef0f3c236fa498e8f6
 264415311 --alswrv      0     0   \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
 811847839 --alswrv      0     0   \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
  38542369 --alswrv      0     0   \_ asymmetric: Oracle CA Server: 7efd70c89ee321c6be7098cd17fe7f4eded76a9e
 230958440 ---lswrv      0     0   \_ asymmetric: Module Signing Example Key: a43b4e638874b0656db2bc26216f56c0ac39f72b
 285314597 --alswrv      0     0   \_ asymmetric: Oracle Linux Kernel Module Signing Key: 2bb352412969a3653f0eb6021763408ebb9bb5ab