Tools and Applications for Administering Secure Boot

About the pesign Tool

The pesign tool is a command line tool for manipulating signatures and cryptographic digests of UEFI applications. You can use the pesign tool to sign kernels for both GRUB2 and Shim.

You can also use the pesign tool for printing binary signature information. The pesign package also provides the pesigcheck tool that you can use to verify a signature against an exact public certificate.

The pesign tool accepts the X.509 certificate/key pair and signs a PE-COFF binary with it. The Oracle Linux kernel has an EFI boot stub that wraps the bzImage file as a PE-COFF binary according to standard UEFI implementation. This implementation provides you with the option to boot the kernel directly from UEFI without requiring a boot loader. In addition, the pesign tool can perform the required signing. See About Secure Boot Keys.

Typically, you use the pesign tool to perform one of the following tasks:

Sign a kernel image with a custom key that you created to sign custom kernel modules. See Signing Kernel Images and Kernel Modules for Use With Secure Boot.
Enroll the hash for a particular kernel within the MOK database so that the kernel can be loaded at boot, even if the Shim doesn't contain its certificate.
Extract a kernel hash from the signed kernel binary so that you can enroll it by using the mokutil tool. See Use mokutil to Update Signature Keys for UEFI Secure Boot.

About the efibootmgr Application

Oracle Linux provides the efibootmgr user space application that you can use to change the Intel Extensible Firmware Interface (EFI) Boot Manager. You use the application to perform several tasks, including the following:

Create and destroy boot entries.
Change the boot order.
Change the next running boot option.

This tool is a general usage application and doesn't directly relate to Secure Boot. However, the tool helps you to manage UEFI boot options directly from user space and makes it easier to debug and resolve some UEFI boot issues from the command line. For more information and examples, see the efibootmgr(8) manual page.

About the mokutil Utility

Shim lets users control their own systems. The distribution vendor key is built into the Shim binary itself. However, an extra database with keys, called the Machine Owner Key (MOK) list or database, is also provided, and which the user can manage through the MOK Manager Utility.

In Oracle Linux, the MokManager utility is installed in the EFI System Partition (ESP) within the /boot/efi/EFI/redhat directory. Originally called MokManager.efi, this file has been renamed to mmx64.efi for x86_64 platforms or mmaa64.efi for Arm platforms. MOK keys can be placed in the ESP and then installed from MokManager during boot.

By running the mokutil command, you can use the MokManager utility to add and remove keys in the MOK list, which remain separate from the distribution vendor key. The mokutil utility lets you to make keys available to the MOK database directly from user space by using the command line. Because keys are often created or extracted in this space, mokutil is the most appropriate tool to use for managing keys that are used for Secure Boot.

Note that although mokutil is run from user space, it doesn't update the MOK database directly. Instead, mokutil makes keys available to the MOK Management service and triggers the Shim to display the MOK Management menu at boot. This process ensures that keys or hashes are only enrolled within the MOK database by somebody who has physical access to the system and prevents a malicious application or user from changing the MOK database directly from user space.

Typical use case scenarios where you might use the mokutil utility include the following:

Adding keys for custom modules that aren't included and signed with the distribution and which you needed to sign yourself. See Signing Kernel Images and Kernel Modules for Use With Secure Boot.
Adding keys or hashes for custom kernels for which the signing key is either revoked or you have built from source. See Use mokutil to Update Signature Keys for UEFI Secure Boot.
Disabling Secure Boot operations from the Shim upward. See Disabling Secure Boot at Shim Level.

For more information, see the mokutil(1) manual page.

Disabling Secure Boot at Shim Level

UEFI can be disabled through the UEFI setup program, or you can use the mokutil utility to disable Secure Boot at the level of the Shim, as described here.

When you disable Secure Boot at Shim level, UEFI Secure Boot remains enabled but no further validation takes place after the Shim is loaded.

The following steps apply to OS that are loaded through Shim and GRUB:

Disable Secure Boot.
Run the following command to disable Secure Boot at the Shim level:
```
sudo mokutil --disable-validation
```
Select a password

Select a password that's between 8 and 16 characters and then enter the same password to confirm.
Reboot the system.
Perform MOK management.

When prompted, press a key to perform MOK management.
Change the Secure Boot state.

Select the Change Secure Boot state option.
Confirm the change.

When promoted, enter each character of the password that you chose, to confirm the change. Press Return (or Enter) after each character.
Reboot

Select Yes, then select Reboot to reboot the system.

To reenable the Secure Boot state at the Shim level, run the following command:

sudo mokutil --enable-validation

Follow the same prompts that appear in the procedure for disabling Secure Boot.

Validating SBAT Status

Oracle Linux10 uses UEFI Secure Boot Advanced Targeting (SBAT), available in the shim package.

SBAT is a mechanism for revoking older versions of core boot components such as grub2 and shim by setting generation numbers in the .sbat section of the UEFI binary. The generation number set in a UEFI binary defines its revocation level.

To confirm whether UEFI Secure Boot is active, use the --sb-state option with the mokutil command:

mokutil --sb-state

Themokutil utility can be used to review and update UEFI SBAT revocation status. To review the current UEFI SBAT level on which the current system is running, use the --list-sbat-revocations option:

mokutil --list-sbat-revocations

You can change the SBAT policy that applies at the next reboot. Setting the SBAT policy to latest applies the latest SBAT revocations and prevents the system from booting older grub2 and shim packages that were operating at an earlier SBAT level, and previous falls back to the previous SBAT revocation level:

mokutil --set-sbat-policy latest

mokutil --set-sbat-policy previous

For systems with UEFI Secure Boot enabled, the default SBAT policy is previous. Both the latest and previous SBAT policies only set a revocation level that's the same or later than it was when the latest shim package was installed.

For troubleshooting purposes, you can reset the SBAT policy to the default revocation level. First, disable UEFI Secure Boot and then set the delete SBAT policy:

mokutil --set-sbat-policy delete

Note:

You can review the .sbat metadata used by grub2 and shim by using the objdump command. For example, on an x86_64 system you can run the following commands:

objdump -s -j .sbat grubx64.efi

objdump -s -j .sbat shimx64.efi

To review the current SBAT policy levels for the provided shim:

objdump -s -j .sbatlevel shimx64.efi

About the dbxtool Command

The dbxtool command combines a command line tool with the systemd service that's used to apply UEFI Secure Boot DBX updates. With this tool, you can operate on the UEFI Forbidden Signature Database, also known as the DBX revocation list. For example, you can use the command to list the current DBX contents and update them to a newer version.

UEFI DBX files are available at https://uefi.org/revocationlistfile. The DBX prevents any software that's signed using a compromised key from loading. In this way it helps to protect the integrity of the Secure Boot framework and avoids needing to manually manage a static database of keys.

The most current UEFI DBX files and the dbxtool utility that's used to manage the DBX revocation list are in the fwdup package and updates are present within each later release of this package on the Oracle Linux yum server. The DBX files are prefixed by DBXUpdate and found in the /usr/share/fwupd/remotes.d/vendor/firmware/ directory.

If the dbxtool systemd service is running, DBX updates are handled automatically. However, if you're notified of a CVE that requires a DBX update, you might need to use the tool manually.

2 Tools and Applications for Administering Secure Boot