Why open firmware is important for safety
I recently gave a lecture on this topic at GoTo Chicago and thought it would be nice to write an article with conclusions. This post is about why open source firmware is important to security.
In a typical stack, you have different levels of privileges.
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.
This ring controls all CPU resources.
System Management Mode (SMM) is invisible to 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 core of UEFI 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." The specification is absolutely insane if you want to rummage.
The most privileged ring. In the case of Intel (x86), this is the Intel Management Engine. This system can silently turn on nodes and overwrite disks, the kernel starts 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 are 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.
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 on your own, there was a bug in the Intel Management Engine web server, which the developer has not known for seven years .
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.
A project to clean the Intel Management Engine to the minimum necessary functionality ( on GitHub ).
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 downloads .
The coreboot design philosophy is to "make the minimum necessary to use the equipment, and then transfer control to another program called the payload . " In this case, it is linuxboot.
Linuxboot handles device drivers, network stack and provides multi-user multitasking environment. 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 is the golang userspace toolkit and bootloader. It is used as the initramfs for the linux kernel in linuxboot.
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, devices still have many other firmware.
We need open source firmware for the network interface controller (NIC), solid state drives (SSD) and basic control controller (BMC).
In the Open Compute project, there is some work being done on the NIC 3.0 firmware. It will be interesting to see what they will do.
For BMC, there are both 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 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 , and Amazon has 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 did not get a decent answer ...
There is a big lecture by Paul McMillan and Matt King about the safety of 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 get the 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 ensure that the equipment is not compromised after the client has performed calculations on it.
However, chip manufacturers seem to have a special look. Intel has the resiliency technology Platform Firmware Resilience , and Lattice has Platform Firmware Resiliency . They seem to be more focused on the NIST guidelines for the resiliency of the platform firmware .
I tried to ask on the Internet who used it, but received little feedback, 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 Platform Firmware Resilience (PFR) from Intel and Cerberus go hand in hand. Intel uses PFR to implement Cerberus certification guidelines. Thank you @msw for the 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.
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 Purism computers. You can ask your suppliers what they are doing to release open source firmware and ensure equipment security with roots of trust. Happy nerd! :)
Privilege levels
In a typical stack, you have different levels of privileges.
- 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 see its code.
- Ring −1. Hypervisor: monitoring 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 to 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 core of UEFI 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." The specification is absolutely insane if you want to rummage.
Ring −3. Control engine
The most privileged ring. In the case of Intel (x86), this is the Intel Management Engine. This system can silently turn on nodes and overwrite disks, the kernel starts 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 are 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 on your own, there was a bug in the Intel Management Engine web server, which the developer has 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 necessary 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 downloads .
The coreboot design philosophy is to "make the minimum necessary to use the equipment, and then transfer control to another program called the payload . " In this case, it is linuxboot.
linuxboot
Linuxboot handles device drivers, network stack and provides multi-user multitasking environment. 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 the golang userspace toolkit and bootloader. It is used as the initramfs for the linux kernel in linuxboot.
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, devices still have many other firmware.
What about other firmware?
We need open source firmware for the network interface controller (NIC), solid state drives (SSD) and basic control controller (BMC).
In the Open Compute project, there is some work being done on the NIC 3.0 firmware. It will be interesting to see what they will do.
For BMC, there are both 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.
Trust roots
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 , and Amazon has 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 did not get a decent answer ...
There is a big lecture by Paul McMillan and Matt King about the safety of 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 get the 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 ensure that the equipment is not compromised after the client has performed calculations on it.
Fault tolerance platform firmware
However, chip manufacturers seem to have a special look. Intel has the resiliency technology Platform Firmware Resilience , and Lattice has Platform Firmware Resiliency . They seem to be more focused on the NIST guidelines for the resiliency of the platform firmware .
I tried to ask on the Internet who used it, but received little feedback, 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 Platform Firmware Resilience (PFR) from Intel and Cerberus go hand in hand. Intel uses PFR to implement Cerberus certification guidelines. Thank you @msw for the 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 Purism computers. 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: https://habr.com/ru/post/451320/
All Articles