==========
== icon ==
==========
My blog about open-source firmware & communities

Firmware -flashing- reading on current AMD systems

AMD flashprog BIOS UEFI
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...

Exploiting Bugs in Early Boot Code with UEFI Capsules

exploit EFI secure boot coreboot
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...

The Underdogs We Protect, the Underdogs We Create

conflicts braindump
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...
1 of 1