Porting UEFI to Apple PowerPC…

Porting UEFI to a new architecture:
So it turns out that blogging about something after the fact is pretty tough. I really wanted to blog about my PoC port of UEFI to the OpenPower ecosystem, but it’s incredibly difficult to go back and try to systematize something that’s been a few years back. So let’s try this again. This time, our victim will be a G4 12″ PowerBook6,8 with a 7447A. That’s a 32-bit PowerPC. Now, I’ll go in small steps and document everything. For added fun, we’ll begin porting on the target itself, at least until that gets too tedious. Also, I’ve a few OldWorld machines, a spare G4 12″ for parts and a G5, so hopefully this odyssey won’t be interrupted by old and failing hardware ;-). Keep in mind that each part is checked in along with the source code, so look at the entire commit. Each blog post will focus on the most important details.[…]




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



Hao Wu of Intel posted a patch to EDK2 which provides support for UEFI’s “EFI Partition Infomation Protocol”, and includes a DumpPartInfo tool:

Add the EFI Partition Information Protocol per the latest UEFI spec.

Test for the series:
A simple application called ‘DumpPartInfo’ is used to dump the contents of the Partition Information protocols when the following devices are attached:
a. MBR Hard disk
b. GPT Hard disk

The source of the application and the series is available at:
https://github.com/hwu25/edk2 branch:partition_info_test

8 files changed, 216 insertions(+), 88 deletions(-)

UEFI UDK2017 pre-release available

Brian Richardson of Intel announced a pre-release of UDK2017, a snapshot of the Tianocore.org EDK2 trunk code matching a set of UEFI.org specs.

Information on UDK2017, the next stable snapshot release of EDK II, is available on the TianoCore wiki.

From the release page on the wiki, here’s the list of

UDK2017 Key Features
    Industry Standards & Public Specifications
        UEFI 2.6
        UEFI PI 1.4a
        UEFI Shell 2.2
        SMBIOS 3.1.1
        Intel® 64 and IA-32 Architectures Software Developer Manuals
    Storage Technologies
        RAM Disk (UEFI 2.6, Section 12.17, RAM Disk Protocol)
        GCC 5.x
    OpenSSL 1.1.0
    Adapter Information Protocol
    Regular Expression Protocol
    Signed Capsule Update
    Signed Recovery Images
    SMM Communication Buffer Protections
    STM Launch
    Memory Allocation/Free Profiler
    NX Page Protection in DXE
    LZMA Compression 16.04
    Brotli Compression
    MP Init Library


More info:

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


Tianocore gets Brotli compression support

BinX Song of Intel has submitted a patch to EDK2 with support for Google’s Brotli compression algorithm.

[PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

Brotli algorithm has a little less compress ratio than Lzma, but has better decompress performance than it.  Add Brotli algorithm support, include Brotli decompression library and tool set.

Brotli is a generic-purpose lossless compression algorithm that compresses data using a combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling, with a compression ratio comparable to the best currently available general-purpose compression methods. It is similar in speed with deflate but offers more dense compression.

More info:

Tianocore patch to increase memory protection

Ard Biesheuvel of Linaro submitted a V2 5-part patch to the EDK2 project, to harden UEFI more!

This is a proof of concept implementation that removes all executable permissions from writable memory regions, which greatly enhances security. It is based on Jiewen’s recent work, which is a step in the right direction, but still leaves most of memory exploitable due to the default R+W+X permissions. The idea is that the implementation of the CPU arch protocol goes over the memory map and removes exec permissions from all regions that are not already marked as ‘code. This requires some preparatory work to ensure that the DxeCore itself is covered by a BootServicesCode region, not a BootServicesData region. Exec permissions are re-granted selectively, when the PE/COFF loader allocates the space for it. Combined with Jiewen’s code/data split, this removes all RWX mapped regions.

Changes since v1:
– allocate code pages for PE/COFF images in PeiCore, so that DxeCore pages have the expected memory type (as suggested by Jiewen)
– add patch to inhibit page table updates while syncing the GCD memory space map with the page tables
– add PCD to set memory protection policy, which allows the policy for reserved and ACPI/NVS memory to be configured separately
– move attribute manipulation into DxeCore page allocation code: this way, we should be able to solve the EBC case by allocating BootServicesCode pool memory explicitly.

More info:

EDK2 test harness

Michael Kinney of Intel has created an edk2-test branch, to focus on testing!

I am creating a new branch in edk2-staging called edk2-test. The purpose of this branch is to develop a test harness, test case SDK, and library of test cases that can be used as part of edk2 validation. The initial version of this test harness is compatible with binary releases of the PI SCTs and UEFI SCTs, are native edk2 packages with no dependencies on the EdkCompatibilityPkg, and the test harness runs using the latest version of the UEFI Shell. 

Additional work items:
* Update to take advantage of latest edk2 features/libraries.
* Update for all supported CPU types
* Update for all supported compilers
* Review initial test harness features and determine what features should be dropped and what new features should be added.
* Determine where the test harness, test case SDK, and test cases should live once the initial functional and quality criteria are met.  Could be packages in the edk2 repo or packages in a new edk2-test repo.  Other options???
* Resolve compatibility issues with binary releases of the PI SCTs and UEFI SCTs.
* Update test harness to support PEI tests
* Update test harness to support Runtime tests
* Update test harness to support SMM tests
* Optimize performance of the test harness and tests.

More info:

EBC Debugger added to EDK2

Pete Batard has added EBC Debugger support to the EDK2 project! As I understand it, there was EBC Debugger support in the original EDK project, but it was not carried forward into the EDK2 project, so this is great news! It sounds like this initial patch will need to go through an iteration or two, so hold off until the dust settles…

“The EBC Debugger, which was present in Tianocore, is an invaluable tool for EBC development.  This patch adds it back into the EDK2, allowing, for instance, the compilation of an AARCH64 EBC debugger. […]”

EBC is a bytecode and VM that is widely used, yet barely understood by most, including security researchers.  While EBC was initially an Intel-centric technology, only supporting their Itaniaum, x86, and x64 processors, and only available from their commercial-only Intel C Compiler, these days ARM is also targetting EBC support.  I’m unclear about ARM’s EBC compiler options, perhaps only via their commecial-only compiler? I hope someone gets EBC support into an open source C compiler codebase, like clang or GCC.

More information:

UEFI Capsule-Update and Recovery

On the EDK2-Devel mailing list, Michael Kinney of Intel has started a new EDK2 wiki page on UEFI Capsule-Based-Firmware Update/Recovery. Capsule Updates are how UEFI-based firmware updates itself.

Draft of documentation for Signed Capsule Feature:
I have started a draft of Wiki pages that describe how to use and verify the Signed Capsule feature from Jiewen Yao. I have focused this first draft on the system firmware update use case for signed capsules. Please review this content and provide feedback. I will work on the remaining 3 signed capsule use cases while the content for this fist use case is reviewed. I plan to add this content to the edk2 Wiki once the reviews are completed.




UEFI EDK2 Platform Proposal V2

Michael Kinney of Intel posted the V2 RFC for the EDK2 Platform Proposal, dealing with how to deal with repos and branches. Outline of changes and problem statement excerpted below, see the full proposal for much more details.

Changes from V1:
* edk2-platform is not a fork of edk2.
* edk2-platforms branches contain CPU, Chipset, SoC, and platform specific packages
* edk2-plaforms/master contains all open platforms that are synced with edk2/master.
* Each edk2-platforms branch may support many platforms (not just one)
* Use PACKAGES_PATH to do builds using packages from multiple repositories
* Update edk2-platforms branch naming to clearly identify platforms that are considered stable and platforms that are under active development.
* edk2 developers may be required to verify platforms in edk2-platforms builds as part of test criteria.  Especially platforms that are intended to be used with edk2/master in edk2-platforms/stable-* branches.

Problem statement: Need place on tianocore.org where platforms can be maintained by the EDK II community.  This serves several purposes:
* Encourage more platforms sources to be shared earlier in the development process
* Allow platform sources to be shared that may not yet meet all edk2 required quality criteria
* Allow platform source to be shared so the EDK II community may choose to help finish and validate
* Allow more platforms to be used as part of the edk2 validation and release cycle.
* Not intended to be used for bug fixes.

For more information, see the archives of the edk2-devel@lists.01.org list.


New UEFI Capsule Update and Recovery sample

Jiewen Yao of Intel checked in a *45-part* patch to the Tianocore project, adding a new UEFi Capsule sample and documentation!

This series patch provides sample on how to do signed capsule update and recovery in EDKII. The feature includes:
1) Define EDKII signed system BIOS capsule format.
2) Provide EDKII signed system BIOS update sample.
3) Provide EDKII signed recovery sample.
4) Provide Microcode update sample for X86 system.
5) Update Quark to use new capsule/recovery solution.
6) Update Vlv2(MinnowMax) to use new capsule/recovery solution.

The signed capsule/recovery solution is in MdeModulePkg. The capsule in IntelFrameworkModulePkg is deprecated. The Microcode update solution is in UefiCpuPkg.

124 files changed, 17848 insertions(+), 384 deletions(-)

For more info, see the full patch:

UEFI EDK2 FDF V1.27 draft spec available

Laurie Jarlstrom of Intel announced the latest UEFI FDF spec: V1.27 Draft for Review.

“Please Review By EOW”.

I think I already saw an issue show up on the public EDK2 bug database.

EDK II FDF File Spec v1.27 DRAFT for Review
Update Sept 2016 (DRAFT)
This document describes the EDK II Flash Description (FDF) file format. This format was designed to support new build requirements of building EDK and EDK II modules within the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of current Unified EFI, Inc. (UEFI 2.6 and PI 1.4) compliant binary images. The FDF file is used to describe the content and layout of binary images. Binary images described in this file may be any combination of boot images, capsule images or PCI Options ROMs.


Click to access FDF_Spec_1_27_Review_Draft.pdf

new EDK2-Bugs mailing list and Tianocore bugzilla server

On the EDK2-Devel list, Mike Kenney of Intel announced the creation of the Tianocore Bugzilla Server, and the new EDK2-bugs mailing list, which tracks changes to the bug database. The Tianocore project is going to migrate from the Github bug database to their own Bugzilla-based one. The announcement mentions a special case for UEFI security issues:

There is one special Product type on the Bugzilla server called “Tianocore Security Issues”.  If you believe you have discovered a security issue, then you must enter the issue using the “Tianocore Security Issues” Product.  The issue will be evaluated to determine if it really is a security issue or not. NOTE: Never any security issue details in email.

For full details, see Mike’s post:

More info:

Hmm, No posts yet to the new list, at least nothing has been archived, yet there are 39 bugs in the database, I would have expected at least 39 posts in the archives…. The Tianocore Security Advisory list never seemed to work. The Intel Security Advisories list never seemed to work. Let’s hope the EDK2-bugs list works…