“This is the first time Intel has staged a public TianoCore hack-a-thon event.”
utk: generic UEFI tool kit meant to handle rom images. Usage:
utk parse <rom-file>
utk extract [–force] <rom-file> <directory-to-extract-to>
utk assemble <directory-to-extract-to> <out-rom-file>
fmap: parses flash maps. Usage:
fmap checksum [md5|sha1|sha256] FILE
fmap extract i FILE
fmap jget JSONFILE FILE
fmap jput JSONFILE FILE
fmap summary FILE
fmap usage FILE
fmap verify FILE
at least one of these recent Intel bugs should also be in the Tianocore Security Advisories list, and at least one of them was just added to it:
Tianocore includes UEFI developer tools for creating ‘blobs’. But it also includes one tool useful for security researchers to examine existing Firmware Volumes. It is an OS-present tool that works on Mac/Windows/Linux, not a UEFI Shell tool.
Usage: VolInfo [options] <input_file>
Display Tiano Firmware Volume FFS image information
-h, –help — Show this help message and exit
–version — Show program’s version number and exit
-d [DEBUG], –debug [DEBUG] — Output DEBUG statements, where DEBUG_LEVEL is 0 (min) – 9 (max)
-v, –verbose — Print informational statements
-q, –quiet — Returns the exit code, error messages will be displayed
-s, –silent — Returns only the exit code; informational and errorvmessages are not displayed
-x XREF_FILENAME, –xref XREF_FILENAME — Parse the basename to file-guid cross reference file(s)
-f OFFSET, –offset OFFSET — The offset from the start of the input file to start processing an FV
–hash — Generate HASH value of the entire PE image
Tianocore, not the UEFI Forum, has released UDK2018, the latest UEFI Dev Kit, a snapshot of the EDK-II, tied to particular revision of the specs.
Multiple URLs on this blog point to the Tianocore EDK2 development mailing list for more information.
However, there’s a few broken links on the archive page for that list.
Here is more info on some changes to the list archives:
Here is another source of archives of the list:
Thanks to the edk2-devel-owners for a pointer to this alt archive site.
Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh
UEFI EDKII Development Environment
This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]
Somewhat related, I also found these UEFI/Docker options:
PS: Wondering what he’s been messing with UEFI on:
Tianocore EDK2 security advisory page has been updated, for the first time since 2016! It looks like a single entry:
27. UEFI Variable Deletion/Corruption
Description: Input validation error in MinnowBoard 3 Firmware versions prior to 0.65 allow local attacker to cause denial of service via UEFI APIs.
Recommendation: This update improves input validation by firmware and is strongly recommended. For firmware development projects, incorporate the updates in https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017. When using MinnowBoard 3, update to version 0.65 or later. Updated firmware is available at https://firmware.intel.com/projects/minnowboard3
Acknowledgments: Reported by Intel.
The referenced CVE is still empty, hopefully someone at Intel/MITRE/NIST is going to take care of that sometime.
This is a small C framework for UEFI development built on top of TianoCore EDK2. This project is not a comprehensive course in UEFI development. If you’re just starting to write UEFI code you’ll need to use additional material like the official TianoCore documentation, and the UEFI Specification. The library and UEFI applications included in this code are meant to simplify a few repetitive tasks when developing UEFI code. For example there is a configurable command line argument parser that will validate input strings and convert them into the target datatype, e.g. integers. This project started out with another UEFI development kit (gnu-efi) but eventually outgrew the original SDK, so I migrated it to TianoCore EDK2017. As a result of this there are still a few library functions included that are already built-in into TianoCore. It is my hope that this code helps anyone looking into, or starting with, UEFI development: I did that myself a few months ago and found parts of the various documentations frustratingly lacking. If I can spare you some of the headache I had I’m happy.
Pete Batard is adding Visual Studio for ARM support to the Tianocore UEFI dev toolchain:
This is a v2 of the previous patch, that takes into account the alignment of suppressed level 4 warnings between IA32, X64 and ARM, and that also removes compiler options that weren’t actually needed. The following series adds ARM compilation support for the VS2017 toolchain. With these patches, VS2017 toolchain users should be able to compile regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, ARM support does not require a specific update of Visual Studio 2017, as the ARM toolchain has been available from the very first release. We tested compiling and running the full UEFI Shell with this series, as well as a small set of applications and drivers, and found no issues. With an additional patch , it is also possible to use this proposal to compile a complete QEMU ARM firmware. As the patch shows, the changes that need to be applied to the EDK2 sources to achieve this are actually very minimal. However, the generated firmware does not currently boot, possibly because of the following warnings being generated by the MS compiler[…At this stage, since the goal of this series is to allow users to compile regular ARM UEFI applications using the VS2017 toolchain, I have non plans to spend more time on the QEMU firmware issues, especially as I suspect that reducing the firmware size back to 2 MB may not be achievable without Microsoft altering their compiler. I am however hopeful that ARM specialists can take this matter over eventually…
Note that Pete is not from the Microsoft Visual Studio team, he’s just doing their work for them… I hope the VS team gives Pete a complementary subscription to their commercial product! [Strange, I don’t think I’ve ever seen Microsoft add suppport for their own tools to Tianocore, it is always an external vendor that does Microsoft’s work…]
The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.
“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.
UEFI Firmware – Security Concerns and Best Practices (Phoenix)
Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.
Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.
Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.
Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.
NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.
Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.
UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.
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.
Tim has a new blog post — first of a series — on writing UEFI code in C++.
Does not appear to be ready for use yet.
UEFI lightweight development kit
a set of libs including a GUI framework to simplify developing uefi programs
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 PI 1.4a
UEFI Shell 2.2
Intel® 64 and IA-32 Architectures Software Developer Manuals
RAM Disk (UEFI 2.6, Section 12.17, RAM Disk Protocol)
UEFI HTTP/HTTPS Boot
Adapter Information Protocol
Regular Expression Protocol
Signed Capsule Update
Signed Recovery Images
SMM Communication Buffer Protections
Memory Allocation/Free Profiler
NX Page Protection in DXE
LZMA Compression 16.04
MP Init Library
Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org, 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.
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.”
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.