1. Introduction
Secure Boot is part of the Unified Extensible Firmware Interface (UEFI) specification for a feature that prevents payloads and drivers without digital signatures from booting or loading during and after initial system startup. Its implementation in contemporary motherboard firmware is usually in the form of a safe but limited boot loader, which expects a specific payload. As a feature of UEFI, Secure Boot can be switched on and off only in the firmware settings available when starting the machine.
In this tutorial, we talk about Secure Boot and ways to toggle it on a Linux system. First, we briefly overview the Secure Boot feature. After that, we turn to a basic method for reaching the machine firmware settings. Finally, we explore more complex approaches to do the same so we can toggle Secure Boot.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. Unless otherwise specified, it should work in most POSIX-compliant environments.
2. Secure Boot
Secure Boot is a protocol specification. Further, the protocol dictates that only some UEFI drivers and OS bootloaders can be loaded during the boot process. In particular, only objects with a digital signature deemed safe are accepted.
Acceptable keys vary according to the Secure Boot operation mode:
- Setup: platform key (PK)
- User: platform key, any PK-dependent key exchange key (KEK)
- Custom: any key in the system
Further, Setup mode generates the PK, a private and public key combination.
Support for Secure Boot is currently available on several platforms:
- Microsoft Windows 8 and above
- Microsoft Windows 2012 and above
- Fedora 18 and above
- openSUSE 12.3 and above
- RedHat Enterprise Linux 7 and above
- CentOS 7 and above
- Debian 10 and above
- Ubuntu 12.04.2 and above
- Mint 21.3 and above
Despite its security orientation, FreeBSD still doesn’t support Secure Boot.
Since it’s a ROM feature, to toggle Secure Boot, we need to enter the firmware settings of the machine. Let’s see ways to do that.
3. Machine Firmware Settings
While a universal list of steps for toggling Secure Boot or other firmware features on any system isn’t feasible, there is a general requirement: we need to modify the local firmware settings. For that, we first have to enter the latter during a machine start.
Let’s briefly review the boot process:
- machine powers on
- boot screen shows up during initial instructions
- boot manager shows up or directly loads OS
- OS initialization manager loads
- OS loads
We can attempt to intercept this process and divert to the firmware settings screen at several stages.
3.1. Keyboard Key During Boot (Screen)
Many motherboards present the user with a way to enter the BIOS or UEFI configuration by pressing a specific keyboard key near the beginning of the boot process:
+-------------------------------------------------------+
| |
| X CPU |
| Powered |
| |
| |
| LinuX Operating System |
| |
| >----v gy |
| | | er |
| ^----< En |
| Hexagon |
| |
| |
|Press <F2> to Setup, <F12> to Boot Menu |
+-------------------------------------------------------+
For example, the bottom of this custom boot screen hints that the F2 function key should take us to the Setup.
The exact key varies, but is usually one of several:
- Return
- Escape
- F2
- F8
- F10
Critically, Fast Start, Quick Boot, and similar features may prevent such hotkeys from working or provide a very narrow window for their input.
Sometimes, this is due to the use of USB keyboards. Since features that reduce boot times may disable USB port initialization before the OS loads, a PS/2 keyboard could enable the hotkey detection. Thus, a firmware feature may prevent us from disabling a firmware feature, including itself.
So, if a PS/2 keyboard doesn’t resolve our inability, we may have to turn to other methods.
3.2. Boot Manager
As usual, boot process modifications can be introduced via the boot manager or bootloader.
While this doesn’t always mean we can access low-level interfaces such as firmware settings, there are boot managers that are able to do that:
- GRUB(2) supports a specific UEFI Firmware Settings option to enter setup, not on by default
- rEFInd provides an option to enter firmware setup by default
- systemd-boot (gummiboot) provides an option to enter UEFI firmware setup by default
Notably, some bootloaders require specific settings to even work on machines with Secure Boot turned on or off.
Further, some machines lack support for sending the user to the firmware settings from the bootloader screen. This severely limits our options. For example, if we activate the GRUB(2) UEFI Firmware Settings option and it doesn’t appear in the boot menu, this usually indicates a lack of support.
In fact, this often means the following method may also not work.
3.3. Initialization Manager
Depending on the environment, we could have an initialization manager that handles more than the initial OS loading.
For example, the systemd initialization manager provides the –firmware-setup flag of systemctl when rebooting:
$ systemctl reboot --firmware-setup
If specified, the switch triggers communication between the OS and firmware via different variables. Through it, they synchronize supported and requested features to fulfill the request, if possible.
Specifically, the OS can set the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit in the special OsIndications variable to direct the boot process to the firmware configuration during the next boot. Notably, the firmware should clear this bit after fulfilling the request to prevent an infinite loop.
Further, since the feature depends on both the machine and the operating system, we can also try the similar functionality that Microsoft Windows offers.
3.4. Force UEFI Boot by Disconnecting Hardware
As one of the methods of last resort, we can attempt another approach:
- ensure we have a UEFI machine
- disconnect all storage devices
- disconnect all non-essential hardware
- disconnect network interfaces
Essentially, we should be left with a machine that has a power supply unit (PSU), central processing unit, main memory, motherboard, and a keyboard connected to it.
At this point, the system should either directly boot into the UEFI setup or present an option to do so.
Alternatively or in addition, we can also take out the CMOS battery to reset any leftover UEFI settings.
3.5. Force UEFI Boot by Deleting EFI System Partition (ESP)
Another brute-force approach involves deleting, clearing, or hiding the EFI System Partition (ESP).
This way, the firmware shouldn’t be able to find the bootloader or supporting files, thereby halting the boot process and potentially entering setup for reconfiguration.
Critically, this method can invalidate the partition, forcing us to use tools like Boot Repair, efibootmgr, or similar to restore the EFI boot partition.
Due to the dangers of this approach, we won’t go into detail about it.
4. Summary
In this article, we explored Secure Boot and ways to boot into the UEFI firmware settings to disable it.
In conclusion, the Secure Boot feature is configurable but may require specific steps to reach its toggle within a given system.