Coreboot’s design philosophy is to
“do the bare minimum necessary to ensure hardware is usable and then pass
control to a different program called
the payload” ( https://doc.coreboot.org).
The payload in this case is LinuxBoot.
LinuxBoot ( https://www.linuxboot.
org/), formerly known as Non-exten-sible Reduced Firmware, or NERF
( https://trmm.net/NERF), handles device drivers, manages the network
stack, and supplies a multiuser, mul-titasking environment. It is built with
Linux so a single kernel can work for
several boards. It is arguably better to
use an open source kernel with lots of
eyes on it, rather than the two and a
half other kernels that are all different
and closed off. This means that you are
lessening the attack surface by using
fewer variations of code, and you are
making an effort to rely on code that is
open source. Linux improves boot reliability by replacing minimally tested
firmware drivers with hardened Linux
drivers. (Linux is significantly more
vetted than most proprietary systems
are; it has lots of eyes on it, since it is
used quite extensively.)
By using a kernel that already has
tooling, firmware devs can build using tools they already know. When they
need to write logic for signature verification, disk decryption, and the like,
they can use a language that is modern, easily auditable, maintainable,
Runtimes enable systems to use open
source firmware and run custom programming logic.
Heads ( http://osresearch.net/) is a
configuration of coreboot that has a
securely configured Linux kernel as
the coreboot payload. It works on servers and laptops. The project, started by
Trammel Hudson, is influenced by several years of firmware vulnerability research (Thunderstrike; https://trmm.
net/Thunderstrike; and Thunderstrike
u-root ( https://github.com/u-root/
u-root) is a set of Golang userspace
tools and bootloader. It is used as the
initramfs for the Linux kernel from
By being open source, this new firmware stack helps improve the visibility into many of the components that
˲Ring – 2—System management
mode (SMM), unified extensible firmware interface (UEFI) kernel. This is
proprietary code that controls all CPU
resources (more on this later).
˲ Ring – 3—Management engine. This
is proprietary code that runs as long as
the motherboard is receiving power,
even if it is off (more on this later).
This summary makes clear that
rings – 1 to 3 have the option to use
open source software and have a large
amount of visibility and control over
the software. The privilege levels under
ring - 1 allow less control, but the situation is improving with the open source
firmware community and projects.
It’s counterintuitive that the code
with the least visibility has the most
privilege. This is what open source
firmware is aiming to fix. The ecosystem’s goals are focused on making
firmware less capable of doing harm
and making its actions more visible.
Ring – 2. SMM, UEFI kernel. This
ring controls all CPU resources. SMM
is invisible to the rest of the stack on
top of it. It was originally used for power
management and system hardware
control. It handles system events such
as memory or chipset errors.
UEFI is the interface between the
operating system and the BIOS firmware. EFI, the predecessor of UEFI,
was made to solve BIOS bit and address limitations. Since then, more
functionality has been added to the
UEFI spec, including cryptography,
networking, and authentication. The
UEFI kernel is extremely complex and
has millions of lines of code. It consists of boot services and runtime ser-vices.Th e specification (https://uefi.
org/specifications) is quite verbose if
you want to dig in. UEFI applications
such as the UEFI shell, GRUB, Gummi-boot, or Windows Boot Manager have
the option of being active after boot.
The UEFI kernel is a common vector for many vulnerabilities since it
has some of the same proprietary code
used on many different platforms.
Bootloaders such as GRUB and Windows Boot Manager are platform specific. The UEFI kernel is shared on multiple platforms, making it a great target
Additionally, since only UEFI can
rewrite itself, exploits can be made
persistent. This is because UEFI lives
in the processor’s firmware, typically
stored in the Serial Peripheral Inter-
face (SPI) flash. Even if a user were to
wipe the entire operating system or in-
stall a new hard drive, an attack would
persist in the SPI flash.
Ring – 3. Management engine. In
the case of Intel (x86), Ring – 3 is the
Intel Management Engine. 7 It can turn
on nodes and reimage disks invisibly.
It has a kernel that runs Minix, 11 as
well as a web server and entire networking stack. Because of this, Minix
is the world’s most widely used operating system. There is a lot of functionality in the Management Engine;
it could take all day to list it all, but
many resources are available for digging into more detail. 16
Between Ring – 2 and Ring – 3 there
are at least two and a half other kernels in our stack that have many capabilities. Each of these kernels has its
own networking stacks and web servers, which is unnecessary and potentially dangerous, especially if you do
not want these rings reaching out over
the network to update themselves. The
code can also modify itself and persist across power cycles and reinstalls.
There is very little visibility into what
the code in these rings is actually doing, which is horrifying, considering
these rings have the most privileges.
They all have exploits. It should be
of no surprise to anyone that Rings – 2
and – 3 have their fair share of vulnerabilities. Exploits here have a huge
impact radius when they happen. For
example, there was a bug in the Web
server of the Intel Management Engine. 14 No one realized the bug existed
for seven years.
How can we make it better?
Firmware projects are typically stored
in SPI flash.
u-boot ( https://www.chromium.org/
developers/u-boot) and coreboot
( https://www.coreboot.org/) are open
source firmware. They handle silicon and DRAM initialization. Google
Chromebooks use both: coreboot on
x86 and u-boot for the rest. This is one
part of how Google verifies boot. 2 Verified boot reduces the risk of malware,
permits safe software updates, and ensures the integrity of the software on