More than 20 years ago, early adopters of Linux would typically rely on the Linux Loader (LILO) boot manager to fire up their systems. LILO, which began development in 1992 with the last version released in 2015, had one major drawback: It was unable to read filesystems, meaning that it had to know the kernel's precise memory addresses. Every kernel update meant reading the blocks again before the system could boot. Despite this drawback, LILO was easy to configure and did not require filesystem support during the boot process, because it grabbed the kernel directly at the previously defined location on the hard disk (Figure 1).

Figure 1: LILO, which did not require filesystem support, was a popular, easy-to-use bootloader at the turn of the millennium.

At the turn of the millennium, the Grand Unified Bootloader (GRUB) gradually replaced LILO, because it offered more flexibility in terms of filesystems and installation targets. The majority of today's systems boot with the help of GRUB 2, which was first released in 2012. GRUB 2 can handle a wide variety of filesystems, plus encryption, compression, and RAID. For some time now, systems that use systemd to initialize have also been able to opt for systemd-boot [1], which emerged from the Gummiboot bootloader as an alternative.

GRUB can be used on different architectures; it is capable of accessing networks and supports a variety of filesystems and data carrier types (Figure 2). This means that it offers significantly more functionality than most users actually need. In recent years, though, numerous medium- to high-level vulnerabilities have been discovered in GRUB, prompting increasing criticism of the bootloader. Its massive codebase with more than half a million lines is considered cluttered and susceptible to errors and attacks. In addition, the distributed configuration across multiple files at different locations makes it hard for beginners to manage. All of this suggests that the veteran bootloader may be past its prime.

Figure 2: GRUB is far more powerful than LILO (even if you can't tell by looking at it), but its large feature set also makes GRUB prone to errors. © Huihermit, GPL, https://commons.wikimedia.org/w/index.php?curid=44678809

If systemd developer Lennart Poettering's vision for the future of Linux distributions prevails, the classic bootloader could soon become obsolete. Poettering's idea is for the Linux kernel itself to handle boot tasks. This is done with the help of Unified Kernel Images (UKIs), which Fedora is currently developing. To understand the advantages of this approach, it makes sense to take a look at the legacy Linux boot process first.

Normal Operation

When a PC is switched on, the BIOS or UEFI fires up first. Both of these start initialization routines, including a power-on self-test (POST), and check the basic hardware. Following this, the actual boot process starts: The bootloader (typically GRUB 2) is loaded into RAM either from the master boot record (MBR) or the EFI partition. The bootloader then loads the Linux kernel and the initial RAM filesystem, initramfs, into RAM (Figure 3).

Figure 3: Bootloaders such as GRUB 2 ensure a proper system startup for virtually any conceivable hardware configuration.

The kernel decompresses itself in RAM and takes over control from the bootloader. It initializes memory management, detects additional hardware, and sets up a minimal environment. In this environment, hardware components are initialized, the required device drivers are loaded, and then the temporary root filesystem, initramfs, is mounted. Its main task is to provide essential drivers and programs, such as udev, which enable the actual root filesystem to be mounted. This is where the init phase begins with the first process /sbin/init (PID 1), which coordinates the rest of the system startup. After checking and mounting all filesystems and switching to single-user or multi-user mode, the system is fully operational.

As this sequence shows, it is a complex process with many interlocking components. The overall construct is prone to errors and difficult to secure completely. Attackers could manipulate the BIOS or firmware to install malware or gain control of the system. This kind of attack is particularly insidious because it will likely remain unnoticed by standard defenses for a long time. There is also the risk of bootloader manipulation to inject rootkits or backdoors, to enable compromised operating systems to load, or to run malicious code early in the boot process.

Booting Without a Bootloader

As is so often the case, it was Lennart Poettering who laid the groundwork [2] for the security strategies implemented for the boot process in Fedora and Red Hat. The Trusted Platform Module (TPM) 2.0 security chip plays a key role here.

The TPM [3] is a microcontroller that adds basic security functions to PCs and laptops. It enables a trusted computing platform that detects tampering at boot time. In practical terms, the CPU generates cryptographic hashes for each boot component, which it transmits to TPM. TPM stores the values and only releases the decryption key if they match the reference values (Measured Boot). Each time the system starts up, TPM generates new checksums and compares them with the stored checksums, providing effective protection against software-based attacks on the boot process and, in particular, on initrd.

The cross-distribution Linux Userspace API (UAPI) [4] working group started coordinating the community development of modern Linux derivatives in 2022. It is the home to specifications, documentation, and ideas, including strategies for a new boot process. Poettering's proposal from 2022 envisions a fully signed and verified execution path from the firmware to userspace, secured by TPM 2 and optionally by Secure Boot. The core of the strategy is the Unified Kernel Image (UKI) [5], which has been around for years. It combines the Linux kernel image, initrd, the kernel command line, and a UEFI boot stub such as systemd-stub [6].

The system bundles all these components into an executable UEFI file that is either launched directly by the UEFI firmware or by a bootloader. When executed, the Linux kernel is loaded with the specified command-line options. Initrd is then mounted and the remainder of the system starts up. The ukify [7] tool creates UKIs as EFI Portable Executable (PE) packages for the UEFI firmware.

UKIs offer several advantages: Atomic updates of all components in a single step enhance security, especially given that the UEFI system partition (ESP) is located on a FAT filesystem with limited data security. As regular UEFI files, UKIs can also be fully signed for Secure Boot. Standard tools such as sbsigntool, systemd-sbsign, and pesign can all be used for this.

No More Bootloader

The theory was put into practice when the Fedora developers implemented the No More Bootloader (nmbl) concept (Figure 4). Instead of relying on separate bootloaders, this approach uses the Linux kernel itself through UEFI's EFI stub functionality and UKIs.

Figure 4: Nmbl is built on the currently running kernel. The easiest way to build nmbl is with Fedora 39, which has a tailored make script for this purpose.

The decisive advantage lies in the codebase. While GRUB, with over 500,000 lines of code, is considered complex and high-maintenance, the kernel requires only a few hundred additional lines of code for the boot process. The leaner architecture not only eliminates potential sources of error, but also benefits from the significantly larger kernel developer community: Problems can be identified and fixed more quickly than with conventional bootloaders. The approach shows how simplifying the boot process can simultaneously improve security and maintainability – a paradigm shift away from monolithic bootloaders toward integrated solutions.

In the summer of 2023, the developers documented their motivation and progress with nmbl in a blog post [8]. The proof of concept presented two implementation paths. The first approach uses kexec [9], a system call for loading a new kernel from within the running system. The second relies on switch-root, which works with the same kernel and only switches from early userspace to the final root filesystem. The developers expect switch-root to be used more frequently, but kexec retains the option of starting alternative kernels via a menu. This flexibility shows how nmbl integrates traditional bootloader functionality in a lean and secure way.

Nmbl, still in the proof-of-concept phase, already works on UEFI systems. Fedora users can test it by first building nmbl and then creating UKIs with tools such as Dracut and manually configuring EFI entries. A blog post [10] explains how to build nmbl with Fedora 39. In addition to the option of bypassing Secure Boot, the post also describes how to create your own key for Secure Boot and sign the UKI with it (Figure 5) to implement a Measured Boot. An entry on GitHub describes how to turn all of this into a bootable package [11].

Figure 5: A look at the boot directory after building nmbl shows the various templates for creating and signing UKIs.