Why the BIOS is such a stubborn black box
Press the power button and the firmware initializes the hardware. Then it hands off to a bootloader. Modern desktop firmware is a UEFI implementation, and it is mostly proprietary. It is a layered stack that mixes code from several sources: independent firmware vendors, silicon makers such as Intel and AMD, board makers and other third parties.
That matters for security as well as for people who care about openness. Firmware runs with extensive privileges over the hardware. A flaw in a component shared across many boards can therefore affect a lot of machines at once. With closed code, outsiders can't audit it. They have to trust the vendors to have gotten it right.
This is general industry context, not a new finding. Typical UEFI image sizes and which vendor supplies which board's firmware are claims I could not independently verify, so I have left specifics out.
What Coreboot does, and what it doesn't
Coreboot's design philosophy, per its own documentation, is to do the bare minimum needed to make hardware usable. It then passes control to a separate program called a payload.
The payload supplies the rest: user interfaces, file system drivers and boot policy. The coreboot documentation lists these popular payloads:
- SeaBIOS provides classic PC BIOS services.
- edk2 provides UEFI services.
- GRUB2 is the bootloader many Linux distributions use.
- depthcharge is the custom boot loader on Chromebooks.
Calling Coreboot an "open-source BIOS" can therefore mislead. The Chromium documentation spells out the distinction. UEFI is a firmware specification, not a single implementation. Coreboot doesn't follow that specification, but it can launch a UEFI payload such as TianoCore to provide UEFI boot services.
The UEFI specification also covers things outside Coreboot's scope. These include boot device selection, firmware updating, a shell and network communication. The coreboot FAQ adds that Coreboot has no Wi-Fi driver and doesn't talk to networks directly.
For a Windows user, the practical consequence is that Windows 11 needs a UEFI interface. That means an EDK II payload sits on top of Coreboot. The result is a combination of components, not one program replacing everything.
The case study: Dasharo on the MSI PRO B850-P WIFI
3mdeb's Dasharo project released v0.9.0 for the MSI PRO B850-P WIFI on July 30, 2026. 3mdeb describes it as the first open-source firmware for a modern AMD Ryzen desktop platform. It is built on coreboot 25.12 and AMD openSIL for the Phoenix Zen 4 processor family. Phoronix framed it the same way, calling it the first open-source firmware release for a modern AMD Ryzen desktop motherboard.
The 79.1% figure, and how to read it
3mdeb compares the Dasharo image with MSI's vendor firmware image E7E56AMSI.2A92. It reports a 79.1% reduction in closed-source firmware code. Igor's Lab repeats the figure and attributes it to 3mdeb. It says Dasharo 0.9.0 contains around 79.1 percent less closed firmware code than the MSI UEFI used for comparison.
Two cautions apply.
- It is the project's own comparative metric for one firmware image. It does not measure all the code in the system.
- The release notes say a very high difference in some data came from the tool finding no data in the vendor BIOS. The tool then assumed a size of 1 to avoid dividing by zero. Read the headline percentage with that in mind.
What stays closed
The release notes say the dominant remaining closed-source portion is AMD Platform Security Processor (PSP) firmware. AMD's Coreboot documentation describes the PSP as an on-die, isolated security processor that runs independently of the main x86 cores. It executes its own firmware and shares the SPI flash with the system BIOS.
So even with open host-side firmware, a separate processor runs code you can't read. The Dasharo release also leans on the PSP for features. Its firmware TPM, which supports TPM 2.0 without a discrete chip, runs inside the PSP.
Coreboot's own blob policy is candid about this. For modern platforms, the project says it depends on silicon vendors for hardware-initialization details, and that datasheets are often NDA-only. It discourages blobs but accepts that they can be a door opener for supporting new platforms. Each new blob is supposed to be weighed for need, risk and alternatives.
Compatibility: the real catch
This is the part most likely to bite a would-be flasher.
- Support is board-specific. The coreboot FAQ says the first step in judging a port is checking whether the processor and chipset are supported. Then check whether the board is locked to its vendor firmware.
- Intel Boot Guard can block you. If it is enabled, the FAQ says getting Coreboot to run is difficult or impossible, even where a port exists.
- AMD Ryzen support is thin. The FAQ describes Ryzen platforms as not well supported outside Chromebooks and AMD reference boards. That text predates the Dasharo release, but it shows how unusual the MSI port is.
- The Dasharo CPU list is narrow. Per 3mdeb, the release supports Phoenix Zen 4 parts, meaning the Ryzen 8000-series. Validation was done only on a Ryzen 5 8600G. Ryzen 9000 chips such as the 9950X3D are not supported, and 3mdeb says they will not boot. Igor's Lab puts the consequence plainly: users cannot simply replace the MSI UEFI of any AM5 system with Dasharo.
- It isn't a free download. According to 3mdeb, the firmware ships through its Dasharo Pro Package and a hardware-firmware bundle in its shop. Open code doesn't mean a free binary.
Features and known issues in v0.9.0
According to 3mdeb, the release includes:
- UEFI Secure Boot
- AMD fTPM with measured boot
- SMM BIOS write protection via ROM Armor 3
- Setup password support
- TCG OPAL and SATA disk passwords
- Memory context restore for fast boot
- EZ Debug LED support
- UEFI Capsule Update v1 using Capsule on Disk
- Testing on Windows 11 25H2 and Ubuntu 26.04 LTS
The project lists four known issues:
- UEFI capsules don't survive resets, so only immediate Capsule on Disk updates work.
- Previous power-state restoration doesn't work for the powered-off state, so only "always on" or "always off" is reliable.
- Ubuntu 26.04 with serial console occasionally halts during boot.
- The onboard Wi-Fi adapter may not appear on the PCI device list. A CMOS reset restores it, and 3mdeb says the vendor BIOS has the same problem.
3mdeb says none of these affect core platform functionality. That is the vendor's own assessment of a v0.9 release. A cautious buyer would treat it as one data point.
Chromebooks: the existing proof that it works at scale
Chromium's documentation says ChromeOS devices released from 2012 onward use Coreboot for their main system firmware. That includes Chromebooks, Chromeboxes and Chromebits. They use the depthcharge payload, which ultimately loads the Linux kernel. That is a more precise boundary than a blanket "virtually all modern Chromebooks."
The fixed hardware of those devices makes them good candidates. It doesn't mean their whole stack is free of blobs.
What this means for readers
- Windows users: Windows 11 25H2 was tested on the MSI board, with Secure Boot, so open firmware doesn't have to mean giving up Windows. The hardware list is tiny, though.
- Buyers: Check the exact board and CPU against a project's support list before buying. A socket match isn't enough.
- Security-minded readers: Open firmware reduces how much you must take on faith. It does not eliminate it. Don't treat smaller code as proof of better security.
- Anyone tempted to flash: The coreboot project expects a "firmware developer mindset." It warns that recovering from a bad flash may mean attaching tools to chips. Prebuilt, pre-tested distributions such as Libreboot or Dasharo lower that risk but don't remove it.
Bottom line
Open-source firmware shrinks the black box instead of eliminating it. On the MSI PRO B850-P WIFI, 3mdeb claims roughly four-fifths less closed firmware code, with AMD's PSP firmware still sitting there. For most Windows desktop owners the stock BIOS remains the only practical option. Anyone who cares about firmware transparency should watch whether AMD publishes more openSIL branches.