Modern PCs run a lot of proprietary firmware on their main CPUs. In the
past, it was sometimes possible to have all the initialisation steps in
open-source, for instance with the coreboot firmware framework. At some
point however, the initialisation process became more complex, and less
documented. Then, alas, open-source firmware fell behind.

A huge part of this complexity comes with the DRAM training. Modern DDR
DRAM needs very precise timings, and the time a signal takes can differ
from hardware unit to hardware unit. Hence, special algorithms are used
to detect working timings at runtime. These timings are often stored in
the firmware flash, and are picked up on subsequent boots. In coreboot,
this is called MRC cache, named after Intel's Memory Reference Code.

On AMD systems, the DRAM training and potentially more of the initiali-
sation is done by firmware on an auxiliary processor. When the main x86
CPU comes out of reset, DRAM is already available.  And thanks to AMD's
openSIL effort,  everything running on the x86 cores can be open-source
again.  The separation of the more complex, more proprietary steps from
the initialisation that runs on the x86 seems to pay off. Let's explore
a different separation that runs on a single processor and utilises the
idea of cached training data as a barrier, the Training-Mode Boot Flow.

Open-source software is prevailing, because of its flexibility, transparency and trustworthiness. In firmware, OTOH, we still have proprietary components, often because of IP concerns. Mixing proprietary and open-source firmware components on a single boot path has several disadvantages.

Read more...

What is coreboot? If not a bootloader, does it fit into any other box?
I watched a recording of an OSFC talk[1] about advances of Intel's FSP
lately, where coreboot was referred to as a bootloader. There was also
a new boot flow presented which didn't fit coreboot at all.  This made
me wonder, is coreboot fundamentally misunderstood? And also, how does
FSP fit into the picture?

[1] https://www.osfc.io/2025/talks/intel-r-signed-fsp-and-verified-boot

The coreboot architecture separates hardware initialisation, which happens in coreboot, and a program payload outside the scope of coreboot. The latter is run after coreboot to continue the boot process. I believe, this separation clearly shows that coreboot is not a bootloader. But first, let’s have a look at what a bootloader technically is.

Read more...

After I got my hands on a second AMD system that is too locked down to
even get read access to the SPI flash controller, I thought it's about
time to summarise my findings.  As it turns out, owner control is once
more left behind. This affects not only end users, but also opensource
development, researchers, and not to forget education.  But more about
this later.

Prior Open-Source Support

Flashprog has always supported BIOS/firmware flashing from the OS command line on AMD systems. This worked very well so far, also on AMD’s AM4 and AM5 platforms, and respective mobile and server systems. With one wrinkle though: The boot firmware can lock us out. There have been multiple locking mechanisms over the years, most of them somewhat cooperative. That is, they locked the SPI controller to allow only particular commands and to deny access to specific flash regions. This still allowed us to support even odd configurations, e.g. a locked controller with a 32MiB flash chip on platforms that officially support only 16MiB max :D And for the newest platforms, there’s always a patch ready for testing the next, partially locked system.

Read more...

Recently, support for in-memory UEFI-capsule updates  was introduced to
the firmware framework coreboot [1]. The original implementation wasn't
accounting for potential integer overflows, which could be exploited by
an adversary with control over memory contents before a reboot. Because
early boot firmware often doesn't implement modern countermeasures, the
exploit I'm going to describe is rather simple. This highlights the im-
portance to avoid untrusted input in early boot stages altogether.

Note:  For readers who are generally familiar with exploits, this might
be a dull read.  The point of this post is primarily to show how easily
bugs can be exploited in unprotected, early boot code.

[1]: https://review.coreboot.org/c/coreboot/+/83422
     "drivers/efi/uefi_capsules.c: coalesce and store UEFI capsules"

Environment and Threat Model

A UEFI capsule is a data container passed to UEFI firmware. Usually, a capsule contains a firmware update, but it can also contain code to be run by the firmware. Sometimes, a capsule actually contains an update program, paired with the actual firmware update.

Read more...

During the last maybe 10 years of my open-source involvement, I have
seen a lot of conflicts. Some of them involving myself, some of them
I only witnessed, and some of them I helped to settle.  It was often
hard for me to look the other way. Trying to understand why, I star-
ted thinking about underdogs.  This is just me brooding, without any
conclusive thought.

What do I call an underdog? To me it’s just somebody who may feel or is left alone in an argument against all other involved people. Having been too often in such a situation myself, I know it can take a huge emotional toll.

Read more...

Here is an opinion piece that I once wrote for blogs.coreboot.org, but
actually wasn't published there. Back then, we were debating if an odd
combination of a proprietary ARM trusted firmware with a reduced core-
boot ramstage should be supported upstream and if this should be added
to the Arm Base Boot Requirements [1].  We ended up adding the regular
coreboot boot flow, along with this combination to the spec. A similar
topic reminded me of this lately, so I decided to publish it in Decem-
ber 2025, two years late.

[1] https://developer.arm.com/documentation/den0044/latest/

I had an odd brainwave yesterday, when two memories of the past few days suddenly were associated. The first was about a discussion on IRC about LogoFAIL and its impact on Intel BootGuard (a tech that allows OEMs to prevent you from running your own firmware). The other was an answer on Gerrit about when a new “coreboot port” for an ARM emulator runs in the overall boot process:

Read more...