LinuxBoot: Linux as firmware

Both the free-software and security communities have recently been focusing on the elements of our computers that run below the operating system. These proprietary firmware components are usually difficult or impossible to extend and it has long been suspected (and proven in several cases) that there are significant security concerns with them. The LinuxBoot Project is working to replace this complex, proprietary, and largely unknown firmware with a Linux kernel. That has the added benefit of replacing the existing drivers in the firmware with well-tested drivers from Linux.

To understand LinuxBoot and the problem it's working to solve, we first have to discuss how computers actually boot. We usually think of a running system as including the hardware, operating system (OS), and applications. However, for a number of reasons, there are several layers that run between the hardware and the OS. Most users are aware of UEFI (which replaced the older BIOS); for many systems, it prepares the system to run and loads the bootloader. These necessary functions are just the tip of the iceberg, though. Even after the computer finishes loading the OS, there are multiple embedded systems also running on the system entirely separate from the OS. Most notably, the Intel Management Engine (ME) runs a complete Minix operating system, while System Management Mode (SMM) is used to run code for certain events (e.g. laptop lid gets closed) in a way that is completely invisible to the running OS.

All of these add up to the LinuxBoot project's statement that there are "at least 2.5 kernels between the hardware and Linux,"; those kernels collectively make up the firmware. Many of these firmware components are surprisingly complex and capable, with full network stacks and extensive hardware drivers. The firmware is a major concern to the free-software community, as it leaves all computers running on a large foundation of code that is proprietary and unaudited. It is also a major risk to large tech companies and cloud providers since the firmware presents many opportunities for powerful, persistent exploits and rootkits. Besides these substantial security concerns, improvements in performance and flexibility of the early stages of boot is also a major motivation for this simplification and move to open source.

To work towards a more elegant and open solution, Google launched a project called NERF, or the Non-Extensible Reduced Firmware, which LWN covered back in November. The primary goal of NERF was to reduce the firmware attack surface by removing almost all functionality that was not necessary to start the operating system (although there are limits on the extent to which this is possible). NERF consisted of a "full stack" solution of stripped-down EFI firmware, a Linux kernel, and an initramfs with tools written in Go. Although these components all make up one bundle stored in ROM, they have since been split into separate projects: LinuxBoot is the firmware and kernel while the user-space initramfs image with Go tools for system booting is available as u-root. Due to this modularity, LinuxBoot can be used with a variety of initramfs images.

UEFI boot process

It's easier to understand how these components fit together if we first look a bit closer at the boot process. A UEFI computer boots in four main phases. The security phase (SEC) and the Pre-EFI Initialization Stage (PEI) are responsible for low-level operations to prepare the hardware and are usually specific to the hardware they are implemented for. After these two stages, the Driver Execution Environment (DXE) loads various drivers, and then the Boot Device Select (BDS) phase can begin.

The BDS phase is where most of what we as users are aware of happens: the system is searched for storage devices, those devices are inspected for bootloaders, and then one of those bootloaders is started. This sounds simple but, due to the many different storage devices and boot schemes available, it can be quite complicated in practice. To manage this complexity, the previous DXE stage loads hundreds of drivers on most systems, implementing support for the majority of the devices the final operating system will be able to use. Further, hardware in the system can provide "option ROMs" that include additional drivers to be loaded and executed prior to BDS. All of these are potentially vulnerable, and it's easy to imagine incredibly damaging attacks based on the extensive capabilities of the largely hidden UEFI.

This is where LinuxBoot comes in. It starts during the DXE stage, resulting in most of the drivers (and their associated attack surface) not being loaded. Instead, a Linux kernel is loaded as if it were a driver.

This brings several immediate advantages. The first, and perhaps most exciting, is that the Linux kernel is an open-source system that has been subject to a great deal of security scrutiny and receives regular fixes. This is almost the exact opposite of the case with existing UEFI drivers. The second is a practical improvement: running Linux at this early stage provides a standardized and well-documented programming environment for developing further modules. This makes it far more practical to extend UEFI's capabilities.

By loading during the DXE, LinuxBoot runs after the first two stages of the UEFI, but takes over after that point, replacing the UEFI drivers. It therefore completely replaces a large portion of the boot process, much of what is often still colloquially referred to as "the BIOS". Because LinuxBoot handles the part of the boot process where I/O devices become available, it eliminates the parts of UEFI with the greatest security and stability risk.

User space

A Linux kernel alone is not of much use; to implement actual system features, a Linux user space is needed. That user space is provided in an initramfs filesystem, much like the standard Linux boot process. There are currently several options available for user-space tools. One is u-root, which is the original solution developed by Google as part of the NERF project. U-root is a tiny image containing binaries written entirely in the Go programming language, and can optionally be built as a single executable binary for optimal load and execution times. This makes it similar to BusyBox. U-root is a complete-enough Linux system to start the final operating system by simply executing its kernel using kexec.

Another notable option for the user space is HEADS, which is a Linux system specifically designed to be secure even when an attacker has physical access to the system. It achieves this through TPM-based hardware trust and extensive protections against firmware attacks. HEADS was originally designed to boot directly from coreboot, but has been ported to work as a LinuxBoot initramfs as well.

Essentially any Linux tool set that can be made compact enough to fit in the available ROM can be built into an initramfs for LinuxBoot, including BusyBox and other minimal user-space projects. The availability of several initramfs images emphasizes the core feature of LinuxBoot: it is an open system. Not only is the LinuxBoot source itself available, the community is free to develop initramfs images that utilize the power of the Linux kernel to extend the firmware in new directions that were almost impossible before due to the closed nature of UEFI implementations.

Because of the limitations of the environment available early in the boot process, the LinuxBoot kernel and user space are highly stripped down. You wouldn't want to use either as your actual computing environment. Instead, LinuxBoot can carry out the next steps to bring the system to a usable state. In many cases this is as simple as searching the available storage devices for a standard Linux kernel and handing over control using kexec, but LinuxBoot enables more sophisticated boot processes as well. An obvious application is cryptographic verification of the final operating system, building another link in a trusted computing system. The sky is the limit, though, and there are many possibilities: improved booting from the network, easier support for unusual storage arrangements, and advanced security controls, for example.

Much like the LinuxBoot initramfs depends on the LinuxBoot kernel to start, so too does the LinuxBoot kernel depend on a previous step in the boot process. This is where coreboot may be involved. LinuxBoot and coreboot are not competitors, rather they address different stages of booting. Remember that the UEFI boot process consists of four stages, of which the third (the driver execution environment or DXE) is the point at which LinuxBoot starts. Coreboot is an implementation of the first two stages, where it can replace the UEFI firmware provided by the motherboard vendor. Coreboot only supports a narrow range of hardware but, when it can be used in concert with LinuxBoot, it enables an almost completely open boot process.

LinuxBoot itself promises much broader hardware support than coreboot because the LinuxBoot kernel and initramfs generally do not need to be heavily customized for the hardware—this is a major part of the reason that LinuxBoot is designed to start after the first few stages of UEFI boot. That allows the UEFI firmware to handle the hardware-specific steps that vendors tend to keep as trade secrets.

LinuxBoot has been demonstrated on Chromebooks, and has clear applications for consumer computers. The major target for LinuxBoot at present is servers. It has recently drawn quite a bit of attention in the large data center environment; the Open Compute Project, which maintains open-source infrastructure designs used by Facebook among others, recently announced that LinuxBoot developer Ron Minnich is to serve as one of the two leads of its firmware work. Server vendor Horizon Computing plans to soon release the Winterfell server, an Open Compute Project implementation that ships with LinuxBoot and NERF. Considering Facebook's heavy investment in Open Compute, this could mean LinuxBoot in use outside of Google soon.

The LinuxBoot Project has recently become a Linux Foundation project. Contributors to the project include Google and Facebook alongside smaller firms Horizon Computing, Two Sigma, and 9elements. Judging by the level of interest the project has attracted early on, this list seems likely to grow.

LinuxBoot is a promising development for anyone frustrated with the amount of hidden, proprietary, and highly privileged firmware in their computers—and the attack surface and maintenance complexity that all of that brings with it. The project's industry support and a general wave of interest in firmware security may make our infrastructure more secure and bring our devices a bit closer to being under our control.