[Translation] Why open firmware is important for security

[Translation] Why open firmware is important for security


Recently at GoTo Chicago I gave a lecture on this topic and thought it would be nice to write an article with conclusions. This post focuses on why open source firmware is important for security.

Privilege Levels


In a typical stack, you have different levels of privilege.

  • Ring 3. Applications: minimal 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 operating system, you can see its code.
  • Ring −1. Hypervisor: monitoring of virtual machines (VMM), creates and starts 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 largely see and control it. For levels below the −1 ring, we have less control, but the situation is improving thanks to the development of open source firmware and the community.

This is a controversial 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 for the rest of the stack on top of it. He has half the core. Originally used for power management and hardware system management. It contains a lot of proprietary code and is where vendors add new proprietary functions. 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 kernel was developed on the principle of "security through obscurity." Specification is absolutely insane if you want to dig.

Ring −3. Control Engine


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

Between the ring −2 and the ring −3 in our stack are at least two and a half other cores, 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, remaining after power off and reinstallations. We have very little information about what the code in these rings actually does, 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 the −2 and −3 rings. When they are found, it is really terrible. Just for example, although you can search for other examples yourself, but in the Intel Management Engine web server was a bug that the developer had not known for seven years .

How can you improve the situation?


NERF: non-expandable reduced firmware


NERF is what the community is working on. The goal is to make the firmware less likely to cause harm and make its actions more visible. They seek to remove all the components of the runtime environment, but for now the Intel Management Engine is hard to do. But you can remove the web server and IP stack from there. Developers also want to remove the UEFI IP stack, other drivers, and remove the Intel Management/UEFI self-firmware feature.

me_cleaner


A project to clean the Intel Management Engine to the minimum required functionality ( on GitHub ).

u-boot and coreboot


u-boot and coreboot - 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 as they check the download . < br/>
Coreboot’s design philosophy is to “do the minimum required to use the equipment, and then transfer control to another program called payload ". In this case, it is linuxboot.

linuxboot


Linuxboot handles device drivers, network stack and provides multi-user multitasking. It is built on Linux, so one core can run on multiple boards. Linux is already sufficiently tested and many people are watching the code, since it is quite widely used. It is better to use an open core with a larger number of “controllers” than two and a half other cores, different and closed. This means that we reduce the attack surface due to fewer code variants and rely on open source. Linux improves boot reliability by replacing poorly tested firmware drivers with Linux drivers with enhanced protection.

Using the kernel, we already have the tools for the firmware: developers can use familiar tools when they need to write logic to verify the signature, encrypt the disk, and so on. All this in a modern, proven, supported and easily readable language.

u-root


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

It is said that the NERF stack reduced the load 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 entirely proprietary. However, there are still a lot of other firmware on devices.

What about other firmware?


We need open source firmware for the network interface controller (NIC), solid state drives (SSD), and basic control controller (BMC).

The Open Compute project is working on the firmware NIC 3.0 . It will be interesting to see what happens.

For BMC, there are OpenBMC , and u-bmc . I wrote a little about them in the previous article .

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

The roots of trust


The purpose of the trust root is to verify that the appropriate software is installed in each piece of hardware. You can be guaranteed to make sure that the equipment is not hacked. Since we now have a lot of closed code in many areas of equipment, this is difficult to do. How to really find out that there are no vulnerabilities or backdoors in the component firmware? No Another thing with open source.

It seems that each cloud and each vendor offer their own root of trust. Microsoft has Cerberus , Google has Titan , at Amazon - Nitro . It seems that they imply a clear confidence in the proprietary code (code that we do not see). This leaves a strange sensation. Wouldn't it have been better to use fully open source? Then we can check without a doubt that the code collected from the source is the same one that works on the equipment wherever the firmware is installed. Then we can verify that the machine is in the correct condition, without a doubt that it is vulnerable or with a backdoor.

It makes you wonder what small cloud providers, such as DigitalOcean or Packet, use as a root of trust. I asked about it on Twitter, but didn’t get a decent answer ...


There is a big lecture by Paul McMillan and Matt King about safety equipment 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 no surprises are hidden in any component.

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

Fault tolerance of platform firmware


However, chip manufacturers seem to have a special look. Intel has a platform resiliency technology Platform Firmware Resilience , and Lattice - Platform Firmware Resiliency . They seem to be more focused on the NIST guidelines on the resiliency of the platform’s firmware . < br/>
I tried to ask on the Internet who used it, but received few feedback, so if you use devices with Platform Firmware Resiliency technology, let me know!


From OCP lectures about innovations in Intel firmware, it seems that Platform Firmware Resilience (PFR ) from Intel and Cerberus go hand in hand. Intel uses PFR to implement Cerberus certification guidelines. Thanks to @msw for clarification.

It would be nice to reduce a variety of tools to do this work. I would also like to see the source code to see with my own eyes that it is safe.

How to help


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

Source text: [Translation] Why open firmware is important for security