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:

Linux kernel lockdown patch

David Howells of Red Hat has posted the latest version of the ‘kernel lockdown’ patch to the Linux-EFI mailing list. The latest patch includes a manpage, see the LWN article below for text. For more info, see the full 27-part patch on the linux-efi mailing list.

AFAICT, no Linux distros use this patch. Why?!

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available. Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination to lift the lockdown. On x86 this is SysRq+x. The keys must be pressed on an attached keyboard. Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to trigger kernel lockdown.


CVE-2015-7837: RHEL UEFI Secure Boot


Vulnerability ID 106841
Red Hat Enterprise Linux UEFI Secure Boot privilege escalation

A vulnerability, which was classified as critical, has been found in Red Hat Enterprise Linux (the affected version is unknown). This issue affects an unknown function of the component UEFI Secure Boot. The manipulation with an unknown input leads to a privilege escalation vulnerability. Using CWE to declare the problem leads to CWE-269. Impacted is confidentiality, integrity, and availability. The weakness was released 09/19/2017 (oss-sec). The advisory is shared for download at openwall.com. The identification of this vulnerability is CVE-2015-7837 since 10/15/2015. The exploitation is known to be easy. An attack has to be approached locally. No form of authentication is needed for a successful exploitation. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 09/20/2017).[…]


Comments above seem to incidate a 9/19 update, but I can’t find that, only older messages from 2015-2016. Unclear about current status of this.


Red Hat released RHEL 7.4

One new feature that is news to me:

USB Guard, a feature that allows for greater control over how plug-and-play devices can be used by specific users to help limit both data leaks and data injection.




Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.


[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt


UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:


The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:

Red Hat Satellite GRUB UEFI PXE script

Satellite 6 TFTP boot file legacy grub conversion script

This script is used to convert the tftp boot files (found in /var/lib/tftpboot/pxelinux.cfg/) which are automatically generated by Satellite 6 into the old legacy grub format. Why is this useful? Recently I encountered some HP servers which have an additional 10GbE card in one of the PCI-E slots on the machine which is used for the PXE boot. Unfortunately this additional interface only supports UEFI boot and not classic bios boot. By default Satellite 6 uses the shim image for UEFI but this doesn’t work with the older Linux kernel used by RHEL6.X. If this script is executed on a capsule or satellite server which has TFTP enabled, it will automatically replace the boot files using the old format which gives a successful boot for RHEL6.



Shell script for Laszlo’s SMM test environment article

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

[1] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

[2] https://github.com/gencymex/smmtestbuildscript


Background for Kernel Lockdown patch

Re: https://firmwaresecurity.com/2017/04/05/linux-kernel-lockdown-2/

Here’s more background on the Kernel Lockdown patch, from email by David Howells of Red Hat:

The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven’t been compromised. This assumes the following:

 (1) Someone wanting to compromise your machine can’t get physical access to the running hardware.  I think pretty much all bets are off if someone gets their hands on your computer.
 (2) Whatever boots our kernel is not itself compromised.  If it is, there’s pretty much nothing we can do about it.
 (3) Whatever boots our kernel can prove that our kernel is what it says it is.

Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware.  The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted.

With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel.  The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM.

[Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.]

[Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.]

In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image.  We try to do this by the following means:

 (1) Refuse to use any key or hash that UEFI has in its blacklist.
 (2) Refuse to load any module that isn’t signed/hashed.
 (3) Refuse to load any firmware that isn’t signed/hashed.
 (4) Refuse to kexec any image that isn’t signed/hashed.
 (5) Refuse to dump a kernel image for software suspend/hibernation if it’s not encrypted.  Further, if it is encrypted, the key must be protected.
 (6) Refuse to load a dumped kernel image that isn’t encrypted with a protected key.
 (7) Refuse to allow userspace direct access to kernel memory (no /dev/mem,  /dev/kmem, /proc/kcore).
 (8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.).  It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed.
 (9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device.

See the posting on the linux-kernel/efi list for full message.

Testing SMM with QEMU, KVM and libvirt

Laszlo Ersek has created a new document that shows how to test SMM using UEFI’s OVMF. Great information!

I’ve added the following article to the TianoCore wiki[1]. It should help both Windows and Linux desktop users build a KVM test machine / environment that closely resembles mine. Such an environment is useful for testing and regression-testing new MP and SMM features and bugfixes. The initial setup is not short, but once you got it up and running, it’s very simple to rebuild OVMF with the edk2 changes, install the firmware binary in the right place (see the article) and then click the Play button on the Fedora 25 and Windows 10 guests, to see the changes in action. If you have smaller updates or structural reorgs for the document, there’s no need to ask me, just go ahead and do them. If some significant information is missing that you’d like me to add, I think I’d prefer new TianoCore BZs at this time (Product: Tianocore Feature Requests, Component: Web Content, Assignee: yours truly). I don’t know when I’ll have time again to dig into this.

Full announcement:

OpenCIT 2.2 released

Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.

New Features in 2.2:
– TPM 2.0 support.
   + Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
   + Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
   + Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256.  SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
    + The CIT  Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version.  This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
    + Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
    + TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
    + TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.

For more information, see the full announcement on the oat-devel@lists.01.org mailing list.


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!

Steven Ellis: firmware updating on Linux

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.


Firmware Mini-Summit announced

Al Stone of Red Hat has announced the next firmware mini-sumit at Linaro Connect, March in Bankok, Thailand. Excerpt of announcement:

Well, it’s that time of year again. If you’re going to be at Linaro Connect [0] in Bangkok, Thailand on the week of 7-11 March 2016, please drop in to the firmware mini-summit to be help Wednesday afternoon (9 March).  The exact time and location at Connect are still to be determined. We’ll have an hour, and so far the topic list is:

   * Update on current status of ACPI patches (PCI, NUMA, CPPC, plans for the next steps)
   * The new FW_OS_Forum mailing list
   * Progress in ACPI compliance testing in FWTS, and future plans
   * _DSD usage yet again
   * Others?

More information: