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. Note that to be recognized, the pesign package for v0.112-22 and later, which is available in Oracle Linux 8, 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 can perform the required signing. See About Secure Boot Keys.

Typically, you use the pesign tool in situations such as the following:

Sign a kernel image with a custom key that you might create 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 easier debugging and resolving some UEFI boot issues directly from the command line. For more information and examples, see the efibootmgr(8) manual page.

About the mokutil Utility

The Shim design lets users control their own systems. The distribution vendor key is built into the Shim binary itself. However, an extra database with keys, called 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 the 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 enables you to make keys available to the MOK database directly from user space on 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 have 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 yourself. See Use mokutil to Update Signature Keys for UEFI Secure Boot.
Disabling Secure Boot operations from the Shim upward. See Disabling Secure Boot.

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

Disabling Secure Boot

If controlling the Secure Boot state through the EFI setup program is difficult, you can optionally use the mokutil utility to disable Secure Boot at the level of the Shim so that, although UEFI Secure Boot is enabled, no further validation takes place after the Shim is loaded.

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

Disable Secure Boot at the Shim level:
```
sudo mokutil --disable-validation
```
Choose a password that's between 8 and 16 characters and then enter the same password to confirm.
Reboot the system.
Press a key to perform MOK management, when prompted.
Select the Change Secure Boot state option.
Type each character for the password that you chose, as requested, to confirm the change.

You would need to press Return (or Enter) after each character.
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 as when disabling Secure Boot.

Validating SBAT Status

Starting from version 15.3 of the shim package on Oracle Linux 8 and Oracle Linux 9, Oracle has been using UEFI Secure Boot Advanced Targeting (SBAT). 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

Starting from version 0.6.0 of the mokutil package, the mokutil command 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, you 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 the current contents to a newer version.

UEFI DBX files are made available at https://uefi.org/revocationlistfile. The DBX prevents software that's signed using a compromised key from loading. Thus, 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 are packaged with the dbxtool package and updates are present within each later release of this package on the Oracle Linux yum server. The DBX files are in /usr/share/dbxtool/ and /usr/share/dbxtool-oracle/. 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.