Secure Boot

Secure Boot Configuration with Microsoft Windows

This tutorial will guide you through the process of setting up a Linux install with a direct UEFI to kernel boot process and using custom secure boot keys to harden the boot process and protect your system.

This guide was written for Arch Linux, and all information is taken from the Arch Wiki, which ought to be referenced in case of error.

Preparation

EFISTUB

In order to properly secure the boot process, we have to setup direct UEFI to kernel boot. This reduces the attack surface by removing GRUB.

PARTUUIDs can be found though blkid, which will be explained latter.

For a basic install (no hibernate or swap) use:

1
$ sudo efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img' --verbose

For an install with hibernate and swap, use:

1
$ sudo efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX resume=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=\initramfs-linux.img' --verbose

For a system with full disk encryption, use:

1
$ sudo efibootmgr --disk /dev/sdX --part Y --create --label "Arch Linux" --loader /vmlinuz-linux --unicode 'cryptdevice=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX:cryptlvm root=/dev/cryptLVM/root resume=/dev/cryptLVM/swap rw initrd=\initramfs-linux.img' --verbose

Notice the UUID instead of PARTUUID in the cryptdevice and make sure to replace the root and resume devices with the proper paths for your volumes.

In all cases, make sure to replace /dev/sdX and Y with the drive where the boot loader is installed. For example, a boot loader on /dev/nvme0n1p1 becomes --disk /dev/nvme0n1 --part 1

Often, it’s easier and more reliable to copy your GRUB_CMDLINE_LINUX_DEFAULT value from /etc/default/grub and use that as the value for --unicode

Make sure to enroll the LTS kernel as well with --loader /vmlinux-linux-lts

Finding UUID

To view all UUIDs, use the command blkid, paying attention to the difference between UUID and PARTUUID.

Configuring boot order

Now that we have our boot entries, we can choose what order they will boot in. View available entries by running sudo efibootmgr with no arguments. Now, set the boot order by running the following command, replacing XXXX with your desired entries (more than 2 may be specified).

1
$ sudo efibootmgr --bootorder XXXX,XXXX

Getting the system ready

We will backup existing Secure Boot variables by creating a new directory and running the following commands

1
2
3
4
$ efi-readvar -v PK -o old_PK.esl
$ efi-readvar -v KEK -o old_KEK.esl
$ efi-readvar -v db -o old_db.esl
$ efi-readvar -v dbx -o old_dbx.esl

Now, we will have to boot the machine into UEFI settings, find the secure boot section (typically under security), clear the existing keys, and put it in setup mode. This varies by manufacturer and motherboard.


Secure Boot: the easy way

The Arch Wiki gives you the resources to do all the following manually, but using sbctl is a far more convenient and reliable. We will use the Arch Wiki nearly command for command in this section. First, install the sbctl package.

Create and enroll keys

Now, check the secure boot status to ensure it is in Setup mode

1
$ sudo sbctl status

Now we will create our keys and enroll them with the Mcrosoft keys in UEFI

1
2
$ sudo sbctl create-keys
$ sudo sbctl enroll-keys -m

Re-run sbctl status to ensure it is now installed

Signing the kernel

Now, we can check what files need to be signed and sign them.

1
$ sudo sbctl verify

Sign the kernel

1
$ sudo sbctl sign -s /boot/vmlinuz-linux

Check the status again with sbctl status to ensure the kernel is signed


Now, your system should be setup with EFISTUB and secure boot. Reboot the system, checking if Secure boot is enabled in UEFI first. If it is and the system boots, then your install was successful. Make sure that you have password protected UEFI settings, otherwise a malicious party with physical access could disable secure boot, making it useless.

Previous:
New Shell, who dis?
Next:
Fibonacci
Tutorials · UEFI