Secure Boot Setup

Pre-setup

GRUB Boot Manager

If you are using GRUB, run the following command to enable secure boot support on GRUB using CA Keys.

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=cachyos --modules="tpm" --disable-shim-lock

Note

Loading unnecessary modules in your boot manager has the potential to present a security risk. Only run this command if you actually need secure boot.

Enabling Setup Mode in UEFI

Firstly, we need to go to firmware settings and set secure boot mode to “Setup Mode”. You can reboot from an already running system to firmware settings with following command.

systemctl reboot --firmware-setup

This is how the BIOS looks like on a Lenovo Ideapad 5 Pro. Reset to setup mode or restore factory keys and reboot back to the system.

However, some MSI motherboards don’t have a setup mode. To achieve the same effect, follow the two steps from the image below:

Some Asus motherboards have a similar behavior to the above mentioned MSI motherboards, as they do not have a dedicated setup mode.

Navigate to Boot → Secure Boot, set Secure Boot Mode to Custom, then open Key Management and select “Delete all Secure Boot Variables”.

Installing sbctl and Enrolling Keys

Before proceeding, make sure to check if sbctl is installed.

sbctl is a user-friendly secure boot key manager capable of setting up secure boot, offering key management capabilities, and keeping track of files that need to be signed in the boot chain.

How to install sbctl

Open a terminal and run the following command

sudo pacman -S sbctl

Now that sbctl is installed, you have to setup sbctl and enroll your keys to the firmware. This process is pretty straightforward, just follow the steps below.

1. Check if Setup Mode is enabled:

   sudo sbctl status

   Expected Output

   Installed:      ✘ sbctl is not installed
   Setup Mode:     ✘ Enabled
   Secure Boot     ✘ Disabled

2. Create your custom Secure Boot keys:

   sudo sbctl create-keys

   Example of a successful key creation

   Created Owner UUID a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
   Creating secure boot keys...✔
   Secure boot keys created!

3. Enroll your keys with Microsoft’s and the OEM firmware’s built-in keys:

   sudo sbctl enroll-keys --microsoft --firmware-builtin

   Expected output

   Enrolling keys to EFI variables...✔
   Enrolled keys to the EFI variables!

   ASUS Motherboards — Do not use --firmware-builtin

   On some ASUS motherboards using the --firmware-builtin flag causes duplicate entries in the EFI key variables (e.g. builtin-db appearing multiple times in Vendor Keys). When activating Secure Boot in the UEFI settings afterwards, the board detects this inconsistent key structure and throws a Secure Boot Violation before the boot manager can load.

   Use only --microsoft on ASUS boards:

   sudo sbctl enroll-keys --microsoft

   If Vendor Keys shows microsoft builtin-db builtin-db ..., the keys need to be re-enrolled. Re-enter Setup Mode in the UEFI (using delete all keys), then run sbctl enroll-keys --microsoft again without --firmware-builtin.

4. Check the status of sbctl again to make sure that the keys are enrolled and setup mode is disabled:

   sudo sbctl status

   Expected Output

   Installed:      ✔ sbctl is installed
   Owner GUID:     a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
   Setup Mode:     ✔ Disabled
   Secure Boot     ✘ Disabled
   Vendor Keys:    microsoft

Signing the Kernel Image and Boot Manager

systemd-boot

CachyOS provides sbctl-batch-sign, a script that takes the list of files needed to be signed from sudo sbctl verify and signs them all.

Caution

On systems with a separate /boot and /boot/efi partition layout, sbctl may only scan for EFI binaries in /boot/efi. This causes kernel images that are in /boot to not be detected. sbctl-batch-sign works around this by always scanning /boot for vmlinuz-* files.

sudo sbctl verify
Verifying file database and EFI images in /boot...
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn4.0.fc40.x86_64/linux is not signed
✘ /boot/EFI/BOOT/BOOTX64.EFI is not signed
✘ /boot/EFI/systemd/systemd-bootx64.efi is not signed
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/0-rescue/linux is not signed
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn3.0.fc40.x86_64/linux is not signed

sudo sbctl-batch-sign

sudo sbctl verify
Verifying file database and EFI images in /boot...
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn4.0.fc40.x86_64/linux is signed
✔ /boot/EFI/BOOT/BOOTX64.EFI is signed
✔ /boot/EFI/systemd/systemd-bootx64.efi is signed
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/0-rescue/linux is signed
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn3.0.fc40.x86_64/linux is signed

Now that all the files are signed. Reboot your system and go to your UEFI Settings to enable Secure Boot.

ASUS Motherboards — enabling Secure Boot

Some ASUS motherboards behave differently from other vendors when enabling Secure Boot:

• Use Windows UEFI Mode, not Other OS: The name is misleading this setting simply controls whether Secure Boot is enforced. Setting OS Type to Other OS actively disables Secure Boot on ASUS boards, regardless of any other settings. sbctl status will continue to show Secure Boot: Disabled even after rebooting.

• There is no separate Secure Boot on/off toggle on some ASUS boards. Secure Boot is activated implicitly by selecting Windows UEFI Mode.

The correct ASUS BIOS configuration to activate Secure Boot in this case is:

Boot → Secure Boot
  OS Type          → Windows UEFI Mode
  Secure Boot Mode → Custom

Check this part for reference

Note that this is a one-time process as signing files with -s flag will save those files to sbctl’s database.

Reminder

sbctl ships with a pacman hook meaning it will automatically sign all new files upon a kernel or boot manager update.

CachyOS uses systemd-boot-update.service provided by systemd to update the boot manager on reboot. This means that the sbctl pacman hook will not sign the updated EFI binaries. As a workaround, we can sign the boot manager directly

sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

Limine

Limine is a special boot manager that allows checking the hash of kernel images and other files that Limine uses during boot. If this is enabled, any sort of manual configuration done by the user, e.g. signing the image via sbctl-batch-sign, will modify the hash of the corresponding files and fail Limine’s checksum verification.

However, signing these files isn’t necessary on Limine because it has a special boot process that bypasses EFI chainloading and signature checks. The only EFI binaries that need to be signed are Limine itself.

Limine >= 11.2.0

Starting with Limine 11.2.0, Secure Boot policies are strictly enforced when UEFI Secure Boot is active:

• A BLAKE2B config checksum must be enrolled in the Limine EFI binary, otherwise Limine will panic with: SECURE BOOT IS ACTIVE BUT NO CONFIG CHECKSUM IS ENROLLED
• All file paths in limine.conf (kernel, initramfs, etc.) must have BLAKE2B hashes appended (e.g. boot():/vmlinuz-linux#<hash>)
• The config editor is unconditionally disabled
• Hash mismatches always cause a panic

To enable automatic config checksum enrollment, set the following in /etc/default/limine:

ENABLE_ENROLL_LIMINE_CONFIG=yes

Proceed to generate a hash for Limine’s splash image:

Root permissions are required to perform the following steps, make sure to use sudo or switch to the root user before proceeding.

1. Check the current name and path of the splash image in the config file:

   Open a terminal and run the following command:

   sudo cat /boot/limine.conf

   You should be able to spot a line like this:

   wallpaper: boot():/limine-splash.png

2. Generate a BLAKE2B hash for the splash image and append it to the path in the config file:

   Run the following command, replacing the path with the one you found in the previous step:

   sudo b2sum /boot/limine-splash.png

   This will output a hash like this example:

   75205d08fa9c61599897857e861d6b2f6da25465183fc4cc9efecffb22ee630efb510f2ef1b17677db94c28d5c69ad2ceb4d3892f5bec9cfa65c97b5ba16f52f

3. Afer copying the newly generated hash from the previous step. Open the config file with a text editor and append the hash to the path of the splash image, like this:

   Do not use the example hash from above, make sure to use the one you generated in the previous step.

   wallpaper: boot():/limine-splash.png#75205d08fa9c61599897857e861d6b2f6da25465183fc4cc9efecffb22ee630efb510f2ef1b17677db94c28d5c69ad2ceb4d3892f5bec9cfa65c97b5ba16f52f

   As you can see, the hash is appended to the path with a # symbol. Save the file after making the change.

After enabling config checksum enrollment and generating the hash for the splash image, run the following commands to enroll the config checksum and sign Limine’s EFI binary:

# Use limine-enroll-config to enroll the config checksum and sign Limine's EFI binary
# This uses sbctl under the hood
sudo limine-enroll-config
sudo limine-update

Secure Boot Status Check

To check that secure boot is indeed enabled. You can run one of the following commands

sudo sbctl status
Installed:      ✓ sbctl is installed
Owner GUID:     a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
Setup Mode:     ✓ Disabled
Secure Boot:    ✓ Enabled
Vendor Keys:    microsoft

bootctl
System:
      Firmware: UEFI 2.80 (INSYDE Corp. 28724.16435)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

Links and Credits

• The Arch Wiki laid the groundwork for this guide. Most of the stuff here was taken from there.
• sbctl - This easy guide to enable secure boot support wouldn’t have been possible if it weren’t for the amazing work done to create this piece of software.
• Improving the Secure Boot Experience by Morten linderud - Blog post by Morten “Foxboron” Linderud on how the secure boot experience was complicated before sbctl.