Firmware is the most powerful software that runs on a platform. It can tear your security concerns apart if configured wrongly, and it can prevent your platform from booting if written faulty. So it should be more important what is running on the lowest level of hardware on your platform. There are several alternatives for the Basic Input Output System (BIOS) your server or laptop is running right now.
BIOS is dead since 10 years ago.
Nowadays the Firmware — this is how you actually call it — can be built upon various frameworks. Most of the firmware today support the Unified Extensible Firmware Interface(UEFI) standard which has been published in 2007 by Intel, AMD, Microsoft and other PC manufactures.
Already 1999 an open-source alternative called LinuxBIOS was born in the Los Alamos National Laboratory with the goal to create a BIOS which boots fast and can be configured more flexible than the current standard. Even though LinuxBIOS, nowadays called coreboot, was constantly improved and is still under development, it only gained traction in the last couple of years.
State of the Art
So — what is the state of the art of firmware development? The truth is:
Firmware Development is still in the Stone Age
and here is why: The Majority of the Firmware Development is still Closed Source. That means that only the companies, so called Independent BIOS Vendors (IBVs), who are actually developing firmware really know the source code. Also: Firmware Development is kind of a monopoly. There are only a hand full of companies who are developing firmware for nearly the complete market of servers and laptops.
Several studies state that competition is good for business — and even better for innovation. Aghion, Bloom, Blundell, Griffithand Howitt analyzed panel data from UK firms in 2005 and showed that competition drives innovation, even though the relation between innovation and intensity of competition is not linear.
Arising Problems
A few problems arise if the market is dominated by only a couple of companies using opaque techniques:
Bloatware
On the Open Source Firmware Conference 2019 in Silicon Valley Ryan O’Leary and Gan Shun Lim showed that there were able to remove 214 out of 424 DXEs within the boot process. DXEs are drivers which get loaded at boot time within the Driver eXecution Environment(DXE) Phase.
That’s an overall reduction of more than 50%.
Normally Firmware needs to be adjusted to every single board. Due to the fact that companies like to save time (and also money) it is much easier to put everything into the firmware that might be needed. This results in more code and longer boot times.
Transparency
As already stated above, most of the Firmware on modern platforms is closed source, which means that the source code is not made publicity available for everyone. In reality only a handful of developer actually know or have access to the source code. This also means that is not transparent what actually has been implemented and what code is really running.
We have to recap that Firmware is actually the first code that runs when the platform boots up and is capable of reading and writing everything without any restrictions — even your encryption wont save you here.
Security
There are a few major security concerns in current firmware solutions. The lack of transparency is one of those. In my honest opinion, we can not talk about reliable security, if the implementation of those mechanism are not available in the public domain. The majority of the cryptography community actually relies on open source. Every known and sane cryptographic algorithm or protocol is publicly documented and available.
Closed Source Firmware is just a blob..
..and that is the problem. We do not know what is happening on the lowest level of the hardware — and especially what goes wrong. Writing bugs and making errors is just natural. Hiding those does not help at all. Security by obscurity is no security at all. Therefore it is no surprise that security researches tend to find new vulnerabilities every now and then in closed source firmware. There is a nice blog about firmware security-related topics which you can find here.
Possible Solutions
So — what could solve all the problems mentioned before? Open Source Firmware. There is a project called coreboot, which has the approach of a minimal hardware initialization and then let e.g. the Linux Kernel take over to do the rest of the driver initialization. This would reduce Bloatware because only the hardware needed will be initialized.
Improving security is a tough call. Humans are writing the code, and humans tend to make errors. The security community developed the technique to make everything publicly available when it comes to security. Every known crypto algorithm is available in the public domain. The idea is, that if we open source the algorithms, we can find flaws or errors in the algorithms or implementation, and can fix them to improve security.
The same mindset should apply when it comes to firmware. We should implement security features open source to improve the implementation and make it more secure by having it publicly reviewed by security researches, companies or universities. And if every firmware shares the same code basis which has been proven to be secure, we can dramatically reduce security flaws in firmware.
Open Source Firmware
There are several Open Source Firmware projects out there — and I like to talk about three of those. They are my personal preference and there could be better ones out there — or not.
coreboot
coreboot is the project that I personally work most of my time with. It evolved over the last two decades (it has its 20th anniversary this year) to a quite big project. It all started in 1999 where the people at the Los Alamos National Laboratory need a solution for the proprietary BIOS and started something that was first called LinusBIOS and later became coreboot.
The overall idea of coreboot is that we do the minimal hardware initialization and jump as quickly as possible to the Linux kernel, which then should take over the rest. The project wants to reduce multiple code basis, as most of the drivers are already implement in the Linux kernel — so there is no need to implement it twice (and maybe faulty) in the firmware. Everything that does not necessary needs to be implemented in firmware, will be pushed into the Bootloader / OS which has a kernel running.
If you want to get into the topic — here is a Getting started with coreboot guide. Also check out the homepage https://www.coreboot.org . They have a quite active community on IRC or Slack. Right now, coreboot support quite a lot of the newer Intel platforms, from Apollo Lake to Coffee Lake, sadly there is no Scalable Support (yet).
oreboot
oreboot is another project that I want to talk about. Basically it is coreboot without the c — and so it has been completely been rewritten in Rust. You can check out it here. It is a fairly young, but very interesting project. There are two major goals:
- Rewrite coreboot in Rust,
- oreboot only supports architectures/SoCs which can be booted blobfree.
In contrast to coreboot, where BLOBs are still allowed for the sake of supporting as much SoCs as possible (every modern Intel SoC need closed-sources BLOBs to run), oreboot is very strict and does not allow BLOBs or NDA documents at all. Lately the dropped support for the ASpeed AST2500, because NDA documents where needed for implementing all registers and functions — so it went out of the tree.
We are moving into the right direction..
Right now it feels that Open Source Firmware is pushing into the right direction. We have some big players on board which have the weight to push firmware development into the right direction. But of course it is not only the big companies who set the tone. We need more developers on-board which port mainboards to coreboot and more customers who want coreboot as the firmware running on their servers.
If you want to get involved or want to know more about Open Source Firmware — feel free to drop me a message.
Other than that — Thanks for reading. Stay curious.
