It’s probably worth mentioning where we are on firmware updates.
A bit of background
One common issue we’ve all had for the last couple of decades is
addressing bugs in system and peripheral firmware. For quite some time,
machines have had the ability to have their various firmwares updated.
Though these mechanisms have existed, they have generally been highly
proprietary, and the tools to perform updates have been difficult to use,
required manual, in-person operation, had a very different user interface
from each vendor, been difficult to mechanically apply to multiple
machines, and had various other usability issues. Vendors have solved
some of these problems in various ways, sometimes with the result of
The overall outcome has been that firmware updates are never applied to
the overwhelming majority of systems. You may have noticed this on
systems of your own. I myself recently discovered I had a laptop
firmware that was 54 releases behind current.
So, this has to be made better. And some things have happened that can
help make this better!
Things added to system firmware that can help this
UEFI 2.x has a feature called Update Capsule (or sometimes
Capsule updates), implemented with an EFI Runtime Services function
UpdateCapsule(). This function is a relatively generic method
to let operating system code running before or after
pass a message, identified by a GUID, to the firmware. The message
itself is comprised of a header, which includes some flags and the
GUID, and a scatter-gather list of physical memory addresses (“the
In UEFI 2.5, a separate feature is added in section 22.3 called the
EFI System Resource Table, or ESRT. The ESRT is a UEFI configuration table
that provides a table of GUIDs to be used in capsule updates, each of which
specifies a hardware device which has upgradeable firmware, and associated
information such as the current firmware version and status of previous
attempts to upgrade that firmware.
Specifically, the ESRT formalizes the GUIDs for use in
calls to initiate a firmware update, with the capsule (i.e. the
scatter-gather list) containing the new firmware. When
called with one of these GUIDs, the firmware performs some validation, and
if it is successful, then either an update will initiate immediately, or
it will initiate after a reboot. What this does not provide is
information to be used by the OS to match entries to specific hardware
devices, nor to firmware update files themselves – that all has to be
orchestrated externally. It’s just a list of which GUIDs are upgradeable
UpdateCapsule() and the status of the firmware matching each GUID.
Higher level progress
Richard Hughes and I have
made a lot of headway on this. Currently we have a couple of projects
that can use this data and with which you can initiate firmware updates
on some test machines:
- Linux 4.2 exposes the ESRT to userland via sysfs; see
gmane or the source or documentation in git for details.
- fwupdate is a simple command line tool and a library which provides the bare functionality of scheduling an update. The command line utility doesn’t do a lot for you; you do something like
fwupdate -a 6c1ce37d-3325-4654-98e2-318b4ca7e174 fwupdate.cap and it sets up BootNext for you to initiate the firmware update during the next reboot. The main purpose here is to provide libfwupdate.so for other tools to use. Right now this only works with local updates, i.e. you have to have an EFI System Partition, but support for other things like https are planned.
- fwupd provides integration between libfwupdate.so and the desktop, and also provides support for keeping track of firmware update packages from your linux distro and matching them up with your hardware, providing useful descriptive text, etc. It provides command line tools that understand the metadata and know when there are new updates available from whomever you’re getting updates from, and extends this functionality into graphical tools and the GNOME Software update system.
- Richard has also made a website with further information, including a (beta) website for uploading firmware to be distributed through distro’s mechanisms, instructions on how to get test accounts, etc. We’re looking for feedback on this and how we can make it as broadly usable as possible, for everyone involved.
So, what’s next
Well, next is more system vendors participating, through supporting these
interfaces on their machines, providing test machine access so we can be
reasonably sure everything works on various platforms, and moving forward
on making sure the actual updated firmwares are as widely available as
possible by providing feedback on the various tools.
Most of the work on this so far has been done on x86 test machines,
because that’s what we have. I have written dummy drivers to test it
with OVMF and AAVMF on virtual machines, and verified that the code
does at least basically function on Aarch64, but we could really use
more support and testing from the ARM community.