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.[…]
A while ago, Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article 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.
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 c. CDROM
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.
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.
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.
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.
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.
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 email@example.com list.
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.
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.
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.