Why open firmware is important for security

Original author: Jessie Frazelle
  • Transfer
Recently at GoTo Chicago I gave a lecture on this subject and thought it would be nice to write an article with conclusions. This post is about why open source firmware is important for security.

Privilege levels

In a typical stack, you have different privilege levels.

  • Ring 3. Applications:  minimum privileges, with the exception of the sandbox in user space, which is even more limited.
  • Ring 0. Kernel: the  kernel of the operating system, in the case of an open source OS, you see its code.
  • Ring −1. Hypervisor:  Virtual Machine Monitoring (VMM), creates and runs virtual machines. In open source hypervisors such as Xen, KVM, bhyve and others, you see the code.
  • Ring −2. System Management Mode (SMM), UEFI core: proprietary code, more on this below.
  • Ring −3. Control engine:  proprietary code, more on this below.

Negative rings indicate levels with privileges greater than zero.

From the foregoing, it is clear that in the rings from −1 to 3, we have the opportunity to use open source software, to a large extent see and control it. For levels below the −1 ring, we have less control, but the situation is improving thanks to open source firmware development and the community.

This is a contradictory situation: the most closed code has the most privileges in our system. This paradox should fix open source firmware.

Ring −2. SMM, UEFI core

This ring controls all CPU resources.

System Management Mode (SMM) is invisible to the rest of the stack on top of it. It has half the core. Originally used for power management and system hardware control. It contains a lot of proprietary code and is the place where suppliers add new proprietary features. It handles system events, such as memory or chipset errors, as well as a bunch of other logic.

The UEFI core is extremely complex, with millions of lines of code. UEFI applications are active after download. The core was developed on the principle of "security through obscurity." The specification is absolutely insane if you want to rummage around.

Ring −3. Control engine

The most privileged ring. In the case of Intel (x86), this is the Intel Management Engine. This system can quietly turn on nodes and overwrite disks, the kernel starts Minix 3 , as well as a web server and the entire network stack. It turns out that thanks to this, Minix is ​​the most popular desktop operating system. The control engine has many functions. It will probably take me a whole day to list them. If you want, there are many resources for a more detailed study.

Between ring −2 and ring −3 in our stack there are at least two and a half other kernels, as well as a bunch of proprietary and unnecessary complexity. Each of these cores has its own network stacks and web servers. The code can change itself, persisting after turning off the power and reinstalling.We have very little information about what the code actually does in these rings, which is terrible, given that these rings have the most privileges.

They all have exploits

It should not surprise anyone that there are vulnerabilities in rings −2 and −3. When they are found, it is really terrible. Just as an example, although you can search for other examples yourself, there was a bug in the Intel Management Engine web server that the developer had not known about for seven years .

How can the situation be improved?

NERF: Non-Extensible Reduced Firmware

NERF is what the community is working on. The goal is to make the firmware less capable of doing harm and make its actions more visible. They strive to remove all components of the runtime, but this is still difficult to do in the Intel Management Engine. But you can remove the web server and the IP stack from there. Developers also want to remove the UEFI IP stack, other drivers, and remove the Intel Management / UEFI self-firmware feature.


Project for cleaning Intel Management Engine to the minimum required functionality ( on GitHub ).

u-boot and coreboot

u-boot and coreboot  are open source firmware. They handle chip initialization and DRAM. Chromebooks use both, coreboot on x86, and u-boot on the rest. This is one of the steps they check for loading .

Coreboot's design philosophy is to “make the minimum necessary to use the hardware, and then transfer control to another program called the payload . In this case, it is linuxboot.


Linuxboot handles device drivers, the network stack, and provides a multi-user multi-tasking environment. It is built on Linux, so a single core can run on multiple boards. Linux has already been sufficiently tested and many people follow the code, as it is quite widely used. It is better to use an open core with a large number of "controllers" than two and a half other kernels, different and closed. This means that we reduce the attack surface due to fewer code variants and rely on open source code. Linux improves boot reliability by replacing poorly tested firmware drivers with enhanced Linux drivers.

Using the kernel, we already have firmware tools: developers can use familiar tools when they need to write logic to verify signatures, encrypt a disk, and so on. All this in a modern, tested, supported and easy to read language.


u-root is the golang userspace toolkit and bootloader. It is used as initramfs for the Linux kernel in linuxboot.

They say the NERF stack has reduced boot time by 20 times. But this is a security article, so let's

get back to security ... The NERF stack improves the visibility of many components that were previously completely proprietary. However, devices still have many other firmware.

What about other firmware?

We need open firmware for the Network Interface Controller (NIC), Solid State Drives (SSD) and Basic Management Controller (BMC).

The Open Compute project is doing some work on NIC 3.0 firmware . It will be interesting to see what they do.

There are both OpenBMC and u-bmc for BMC . I wrote a little about them in a previous article .

We need to have all open source firmware in order to ensure full visibility on the stack and actually check the status of the software on the machine.

Roots of trust

The purpose of the root of trust is to verify that the appropriate software is installed on each component of the equipment. You can ensure that the equipment is not hacked. Since we now have a lot of closed source code in many areas of the equipment, this is difficult to do. How to really know that there are no vulnerabilities or backdoors in the component firmware? No way. Open source is another thing.

It seems that each cloud and each vendor offers its own root of trust. Microsoft has Cerberus , Google has Titan , Amazon has Nitro . They seem to imply explicit trust in the proprietary code (code that we don't see). This leaves a strange feeling.Wouldn't it be better to use fully open source? Then we can verify without a doubt that the code compiled from the source code is the same one that works on the equipment wherever the firmware is installed. Then we can check that the machine is in the correct state, without doubting that it is vulnerable or with a backdoor.

This makes you wonder what small cloud providers such as DigitalOcean or Packet use as the root of trust. I asked about it on Twitter, but did not get a decent answer ...

There is a great lecture by Paul McMillan and Matt King on equipment safety when scaling . The authors describe in detail how to protect the hardware, while at the same time giving customers access to it. When they receive equipment back from customers, they need to consistently and reliably make sure that everything remains unchanged and that no surprises are hidden in any component.

All cloud providers must make sure that the equipment is not compromised after the client performs calculations on it.

Platform firmware fault tolerance

However, chip makers seem to have a special look. Intel has Platform Firmware Resilience , and Lattice has Platform Firmware Resiliency . They seem to be more focused on the NIST guidelines for fault tolerance of platform firmware .

I tried to ask on the Internet who used it, but received few responses, so if you use devices with Platform Firmware Resiliency technology, let me know!

From the OCP lecture on innovations in Intel firmware, it seems that Intel's Platform Firmware Resilience (PFR) and Cerberus go hand in hand. Intel uses PFR to implement the Cerberus Certification Principles. Thanks @msw for the clarification.

It would be nice to reduce the mottled array of tools to do this job. I would also like to see the source code to see for yourself that it is safe.

How to help

I hope you got some idea of ​​what projects exist for developing open source firmware and how important it is! If you want to help, please tell others. Try using open source platforms. Chromebooks are a great example, as well as Purism computers . You can ask your suppliers what they do to release open source firmware and to ensure the safety of equipment with a root of confidence. Happy nerd! :)

Also popular now: