EFI-RPM-macros: helps packaging of EFI code into Red Hat RPMs

efi-rpm-macros provides a set of RPM macros for use in EFI-related packages.

The following variables are meaningful on the make command line:

EFI_ESP_ROOT the directory where the EFI System Partition is mounted
EFI_ARCHES the rpm arches %efi will match on
EFI_VENDOR the vendor name for your EFI System Partition directory

The following rpm macros are set:

%efi the arches that EFI packages should be built on, suitable for use with %ifarch
%efi_vendor the vendor name for your EFI System Partition directory
%efi_esp_root the directory where the EFI system Partition is mounted
%efi_esp_efi the full path to \EFI on the EFI System Partition
%efi_esp_boot the full path to \EFI\BOOT on the EFI System Partition
%efi_esp_dir the full path to your vendor directory on the EFI System Partition
%efi_arch the EFI architecture name, e.g. x64
%efi_arch_upper the EFI architecture name in upper case, e.g. X64



DBXtool has support for Microsoft dbxupdate.bin

DBXtool[1] is a tool by Peter Jones of Red Hat. So it works with Fedora, and perhaps other versions of Linux. It is an interesting tool in that it is one of the few tools that look at the UEFI SecureBoot PKI list of blacklisted keys,  that UEFI Forum occassionally updates[2]. Last year there was the Microsoft leaks Golden Keys” story, which was overblown, watch Jeremiah’s video on Youtube from the Fall 2016 UEFI Plugfest for more details. I just noticed that DBXtool has support[3] for a dbxupdate.bin file from Microsoft, separate from the UEFI.org-hosted DBX file, related to this Microsoft Golden Keys incident.

Peter’s comment from that checkin:

Add a new dbxupdate.bin
This is the dbxupdate.bin referenced in CVE-2016-3320 and
It’s for their bootloaders, not ours.

[1] https://github.com/rhboot/dbxtool
[2] http://uefi.org/revocationlistfile
[3] https://github.com/rhboot/dbxtool/commit/1e9334f1287c4703e7dfb40121e00d16d109e903
WordPress mangles Github Gist URLs, so remove the spaces from the next URL to make it work:
https://gist.  github.com/acepace/   df34b5213f1e0fae6529eb703d947187

Some more background on UEFI SB DBX:
https://translate.google.com/translate?hl=en&sl=ru&u=https://habrahabr.ru/post/273497/&prev=search (English translation above Russian document)

Besides Peter’s DBXtool, I’m not aware of many other tools that use the DBX file. There’s this PowerShell script:
Again, WordPress mangles Gist URLs, remove spaces to make this work:
https://gist. github.com/mattifestation/ 991a0bea355ec1dc19402cef1b0e3b6f

I wish I could point to a tool avaialble in each OS/distro that your firmware has the latest blacklist applied…

PS: Peter also works on the Shim. And he’s updated his canary:

U-Boot UEFI updates, for standard distro boot

Rob Clark has a new 20-part RFC patch to U-Boot to significantly improve U-Boot’s UEFI support. I’ve included most of Rob’s comments below, see the patch for the code.

[PATCH v0 00/20] enough UEFI for standard distro boot

This patchset fleshes out EFI_LOADER enough to support booting an upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and then eventually the per-distro shim.efi which loads the per-distro grubaa64.efi) without resorting to hacks to hard-code u-boot to load a particular distro’s grub, or other hacks like setting up the distro installation as live-media. The first seven patches add dependencies that will be needed later in the series. Patches 8-15 make u-boot work with upstream grub, without relying on distro patches. Patches 16-19 add missing bits of the UEFI implementation needed to support shim/fallback. And finally patch 20 adds bootmanager support to avoid shim/fallback after first boot.

Background: with a normal UEFI implementation, the boot process is:

a) firmware (u-boot) looks at BootOrder and the BootXXXX variables to try to determine what to boot.
b) the firmware will look at the BootXXXX variables (which contain an EFI_LOAD_OPTION “struct” in order specified by BootOrder, and will boot the first bootable option.
c) The EFI_LOAD_OPTION specifies a device-path which identifies the device and file path of the .efi payload to exectute.

If there are no bootable options the firmware falls back to loading \EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which then loads fallback.efi which uses the EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for \EFI\*\boot.csv, and will then set BootOrder and BootXXXX EFI variables accordingly so that on next boot fallback.efi is not necessary.

(I’m ignoring secure boot, it is out of scope here.)

For example, if you had both fedora and opensuse installed on the same disk in different partitions, you would have both:

+ \EFI\fedora\boot.csv
+ \EFI\opensuse\boot.csv

The former would contain the filename of \EFI\fedora\shim.efi and the latter to \EFI\opensuse\shim.efi (each of which would know to load \EFI\fedora\grubaa64.efi or \EFI\opensuse\grubaa64.efi). Based on this, fallback.efi would setup EFI_LOAD_OPTION’s Boot0000 and Boot0001 (and BootOrder would control the order the load-options are considered).

With a real UEFI fw there would also be some sort of boot-order menu (ie. hold down f9 at boot, and get a menu to pick which of the Boot* load-options to try first). That is not part of this patchset but would be a useful next step to allow installing multiple operating systems on the same disk.

This patchset provides EFI variable support during bootservices, so viewing or modifying EFI variables after linux ExitBootServices()’s is not possible. If the board supports saveenv() this will be called in efi_exit_boot_services() to persist variables that where set during the boot process. Making variables available after EBS is tricky on hardware that does not have dedicated storage, as after EBS u-boot no longer controls the devices. An approach that Alexander Graf suggested, is that since reboot/halt is controlled via UEFI, is that on boards that can ensure memory is persisted across reboot, to store modified EFI variables in a special memory location and turn halt into reboot uboot -> appropriate setenv() calls -> saveenv() -> halt in order to persist modified variables. Which is also not part of this patchset, and will likely require some board-specific help.

There will be some updates to this patchset depending on whether we move to c11 as Heinrich suggested (ie s/L”string”/u”string” and some changeups in the vsprintf patch). But rather than calling this an RFC (which I figured was more likely to get ignored for review) I am calling this a v0.

Thanks to Peter Jones for a couple of the patches, and a bunch of help understanding what the things above the UEFI fw expect (and fixing a few shim and grub bugs that we found along the way).

32 files changed, 2508 insertions(+), 329 deletions(-)

Full announcement from Rob:


Peter Jones on Secure Boot failures and mitigations

I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.


Especially because I’ve had nearly nothing useful in this blog on this post:




Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!

Protecting Linux from systemd’s EFI attack

Peter Jones of Red Hat has submitted a patch to the Linux-EFI mailing list, which helps with the recent systemd attack against Linux’s EFI. Patchset email excerpted below:

Preventing “rm -rf /sys/firmware/efi/efivars/” from damage

Here’s a patchset to make all the variables in efivarfs that aren’t well known to be reasonably safe to delete be immutable by default. This should alleviate the danger of somebody accidentally using “rm” to remove some proprietary file that turns out to be important to the platform, which for some reason it also can’t regenerate during POST. In all cases this is just preventing the user from accidentally triggering a major security problem with their underlying firmware, but stopping accidents isn’t a bad thing.  These firmwares still need CVEs and updates to fix them.  Maybe using ESRT and fwupd 🙂

For more information, see the linux-efi mailing list archives.



Linux firmware update

As pointed out on Phoronix, there’s a new blog post by Peter Jones of Red Hat on the status of firmware updates on Linux.


Phoronix has been covering this much better than I have: