Tianocore releases UDK2018

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.







Windows UEFI development course

WinInsider — probably via Alex Ionescu — has a UEFI development course available.  Alex is the author of VisualUEFI, which hides the non-Visual Studio’isms of EDK-II development. Alex, along with others at Wininternals, is also one of the current authors of the “Windows Internals”  book from Microsoft Press, now a 2-volume 6th edition set, originally called “Inside Windows NT”, written by Helen Custer.

Windows UEFI Development (3 Days or 5 Days)

In this course, one can expect to learn the internals of the Unified Extensible Firmware Interface inside and out, from the high-level concepts and overview of its functionality, down to the low-level development of actual UEFI applications, drivers, and services. The seminar will go over the history of UEFI’s development, from its original “Intel Boot Initiative” days to today’s SecureBoot facilities (and controversies), discuss the core UEFI data structures that form the basis of the environment, describe the different internal boot phases of the UEFI Runtime, and go in detail over the main UEFI protocols and their semantics. The course will also cover how UEFI leverages several Microsoft technologies, such as Authenticode and the Portable Executable (PE) format. Finishing off the lecture section will be a deep dive on how Windows 8 and later take advantage of UEFI to support booting off GPT disks, implementing SecureBoot, and speeding up the boot experience. Windows user-mode and kernel-mode APIs that interact with UEFI, as well as internal kernel data structures and capabilities in the UEFI HAL will also be shown off. Alongside the lecture period, attendees will get their hands dirty with bare-to-the-metal UEFI development using Visual Studio, as well as learning how to setup the UEFI SDK (EDK) to work alongside Microsoft’s development tools. Participants will get the chance to build their own UEFI applications, drivers, and runtime services, as well as learn how to debug and test their work in the OVMF environment alongside QEMU, without requiring actual UEFI hardware. The course will also show how to develop and build SecureBoot-compatible binaries. Finally, attendees will discover the Windows-specific Boot Application Runtime Environment, how to build compatible applications, and how to leverage the environment from both a UEFI and PCAT perspective. Attendees will then write both offensive and defensive UEFI code that hooks and/or protects the Windows Boot Loader.

UEFI Course Outline:
* Introduction to UEFI
* UEFI Architecture
* UEFI Protocols & Services
* Windows and UEFI
* Windows Boot Application Environment
* Windows Boot Loader Internals
* EDK and Visual Studio Development
* Windows & UEFI Interfacing

* UEFI Protocols: UEFI Device Handles, UEFI Text and Graphics, UEFI Local and Remote I/O, UEFI USB & PCI, UEFI File System, Custom Protocols
* UEFI Services: UEFI Boot Services & Runtime Services, UEFI System Table, ACPI & UEFI, Custom Services
* UEFI Architecture: Measured Boot & Secure Boot, UEFI Stages & Layers (SEC, PEI, DXE), GPT Partitioning, Types of UEFI Binaries
* Windows & UEFI: Calling UEFI Services, Accessing UEFI Variables, Windows Boot Library and UEFI, BCD and UEFI, HAL and UEFI
* Windows Boot Environment: PCAT and UEFI Portability, Core Data Structures, Entrypoint and Callbacks,  Building a Windows Boot Application
* Windows Boot Loader: Boot Stages, Boot Loader Functionality, Security Services (BitLocker and more), Boot Structures, Handoff to Kernel
* UEFI Development: Obtaining and Installing the EDK, Setting up Visual Studio with the EDK, EDK Hello World, Interfacing with EDK Libraries, Obtaining and Installing OVMF
* Offensive UEFI: Hooking UEFI Services and Protocols, Windows Boot Environment Hooks, Persistence with UEFI
* Defensive UEFI: Checking for Boot Loader Integrity, Detecting UEFI Hooks and Bootkits



EDK-II upcoming Github changes

Laurie Jarlstrom of Intel announced on the EDK-II list about upcoming Sourceforge to Github hosting changes:

This message is an update on the transition from SourceForge to GitHub for EDK II development.  The schedule is currently targeting the last week of January or the first week of February to perform the transition.  The transition process should only take one to two days to complete.  A notification message will be sent the week prior to the actual dates that the repositories will be impacted.  This should provide adequate notification for the scheduled down time. As part of this transition some documentation and process changes have been required.  The updated process as well as other GitHub specific information can be found on the tianocore Wiki at the link provided below.  Feedback on this documentation is welcome and needed to make sure the transition is as smooth as possible.


Full message:

EDK II specifications updated

Laurie Jarlstrom of Intel has announced a documentation update to the UEFI Forum’s EDK II Specifications:

“Announcing the V1.25 and V1.26 updates to the EDK II Specifications. Go to the EDK II Specifications page to download the latest documentation.”

These are the specs beyond the UEFI Forum’s PI and UEFI specs, focused on development implementation details of Tianocore’s EDK-II.


UEFI gets more IPMI 2.0 features

Daocheng Bu of Intel added new IPMI libraries to UEFI’s public EDK-I dev kit. Earlier, IPMI 2.0 definitions were added, now a library to support a generic PIMI submitt command has been added:

Update Ipmi2.0 definitions header file and MdeModulePkg.dsc
file for Ipmi libraries. Add Ipmi realted libraries to support
generic Ipmi submit command. Also add Ppi/Protocol definitions
that will be produced by Ipmi Peim and drivers.

  MdePkg: Update Ipmi2.0 definitions header file.
  MdeModulePkg: Add IpmiLib and Ppi/Protocol header file.
  MdeModulePkg: Add BaseIpmiLib Null Library Instance.
  MdeModulePkg: Add PeiIpmiLibIpmiPpi Library Instance.
  MdeModulePkg: Add DxeIpmiLibIpmiProtocol Library Instance.
  MdeModulePkg: Add SmmIpmiLibSmmIpmiProtocol Library Instance.
  MdeModulePkg: Update MdeModulePkg.dsc file for IpmiLib.

   18 files changed, 803 insertions(+), 135 deletions(-)

More info: see the patch on the edk2-devel list:

Tianocore web site updated

As reported by the Intel UEFI Twitter feed, the UEFI Forum’s web team have done a complete overhaul to the TianoCore.org web site:



There are a few other web pages, not many more; most others are github-hosted web pages now.

This news was found on the Twitter feed of Brian Richardson of Intel, which was not on my previous 0.3 release of Twitter feeds, but will be in next 0.4 release:

On a related note, the edk2-devel mailing list finally moved from SourceForge to 01.org:

Tutorial on using EDK-II’s Linux emulator

Today Jey Jay (LinuxKernelSeeker) has a blog post on how to use TianoCore with Linux, using the EDK2 emulator.

“This post will explains the steps involved in compiling EmulatorPkg of Tianocore EDK2. Who wish to learn UEFI can use this emulator for writing UEFI samples.” …

It is a good article, some of the Tianocore readmes for Linux are fairly vague (and/or referencing outdated distro releases that’re no longer available), so it is nice to have a tutorial talking about a fresh release, including some screenshots to be even more user-friendly.

More Information:


EDK-II specs updated


UPDATE: Below I complain about lack of an announce mechanism to find these updates; TianoCore has an RSS feed that I’ve been neglecting to check, so they have been announcing it, but I’ve not been noticing…



Today, the EDK-II specs were revised.

“Announcing the 1.25 Updates to the EDK II Specifications (BUILD, DSC and FDF). Also Update to Visual Forms Representation (VFR) V 1.9.”

(I stumbled upon announcement on web page by accident; I wish these were announced on edk2-devel or somewhere else more easily-discoverable.)

More Information:


Two UEFI Form tools, plus one UEFI C Module complexity tool

UEFI has a “Browser”, and the browser shows various “Forms”. The browser is what you see when you get the OEM/IBV BIOS boot menu. OEMs/OBVs can reskin the browser, to add value, so the user experience will vary by vendor. In addition to the OEM/IBV, IHVs and ISVs can also add forms to a system’s browser. Each .efi binary contains resource strings, which get compiled into UEFI’s form language. The raw strings are IFR, Internal Forms Representation. The resulting view for the end user is VFR, Visual Forms Representation.  The UEFI browser is dynamic, you can programatically add new menu options by running an app. If you add foo.efi to your system, when you run the BIOS boot menu you may now see a new entry for the foo device, service, or application. For example, if you plug in a new device, that IHV’s config code will likely be now be in the BIOS boot menu. This is much nicer than having to run a DOS config.exe command (if you even have the ability to boot DOS), or boot into the vendor’s OEM firmware update CD (if they provide one).

At design-time, the EDK-II contains tools to build forms from source code. See TianoCore.org’s EDK-II tools and sample parsing code (in C and Python). Also see Intel SSG’s training courseware and labs, they have UI examples.


At run-time, existing ROM images or .efi images may have an IFR in the binary. If you don’t have the source code, how do you evaluate the UI included, besides running it?

1) One tool is the “Universal IFR Extractor”, by Donovan6000. This tool can extract the internal forms representation from both EFI and UEFI modules and convert it into a human readable format. It is a Windows-centric tool, being an old-school native GDI GUI appplication written in C++. It may work on *nix via WINE, I’ve not tried it yet.


2) Another tool is “Language applications for UEFI BIOS”, by William Leara. This was his University of Texas thesis; he is now a BIOS engineer at Dell. Besides the thesis, there is a github project with source code. He created an ANTLR grammar for VFR and a tool that gives an HTML preview of what the form would look like.

3) He also created an ANTLR grammar for UEFI-based C source code, and performs complexity analysis application uses general-purpose and domain-specific measures to give a complexity score to UEFI BIOS modules. This second tool isn’t form-centric, but it is also interesting, perhaps more interesting to some security researchers; it’s a good foundation to create more sophisticated tools of this kind, too…


Vim syntax highlighting for EDK2 sources

If you use Vim, there are a few projects with syntax highlighting support for TianoCore sources and config files. A recent one, from this year:
Two others from 2013, with different features from above one:

If you use Visual Slick Edit, one firmware engineer at Dell has created some files for EDK-II support:

I found no support found for Emacs, perhaps the FSF anti-UEFI campaign has impacted this? I don’t know of any EDK-II support in any other open source programmer’s editors or IDEs.

Besides highlighting C/assembly sources, EDK2 has 7 different build/config files, much more complex than a single Makefile to deal with. The specs for these files are listed below; it would be nice if you spend time in EDK2 sources, if your editor helps you understand these formats.

Ruby for UEFI

In addition to UEFI Shell scripts, Python, and Lua, you can also use Ruby to write code for UEFI.

Mruby is the Ruby compiler that was ported to UEFI. “mruby is the lightweight implementation of the Ruby language complying to (part of) the ISO standard. Its syntax is Ruby 1.9 compatible.

Mruby on EFI Shell is a mruby port to the UEFI Shell, ported by Masamitsu Murase. With mruby.efi, you can call UEFI BootTime and RunTime Services, and access UEFI data structures. For some nice examples, look at the home page of the project.

To build mruby for EFI Shell, look at the readme on the sources, you need to create a new subdirectory in the EDK-II AppPkg for it. Once built, you need to copy mruby.efi onto your UEFI System Partition (ESP) so you can access it via the UEFI Shell. From the UEFI Shell, sample usage is:

    mruby.efi hello.rb

This has been around for about 3 years, but I only noticed it a few weeks ago.

More Information:


BUILDRULEORDER support added to EDK-II BuildTools

Recently there’s been a lot of checkins to the EDK-II trunk. Most are new libraries for UEFI 2.5 support, but some are design-time improvements to the EDK-II toolchain. One recent change to the BaseTools package is to implement BUILDRULEORDER support for tools_def.  This adds increased flexibility for compilers and related developer tools, which EDK-II’s Build command calls behinds the scenes. Quoting it’s comments:

This feature allows the toolchain to choose a preference for source file extensions in tools_def.txt. The first extension is given the highest priority. Here is an example usage for tools_def.txt:

*_*_*_*_BUILDRULEORDER   = nasm Nasm NASM asm Asm ASM S s
*_XCODE5_*_*_BUILDRULEORDER   = S s nasm Nasm NASM

Now, if a .inf lists these sources: 1.nasm, 1.asm and 1.S
All toolchains, except XCODE5 will use the 1.nasm file. The XCODE5 toolchain will use the 1.S file.

Note that the build_rule.txt file also impacts the decision, because, for instance there is no build rule for .asm files on GCC toolchains.

For more information, view recent archives of the EDK2-devel mailing list, such as:

Book Review: Embedded Firmware Solutions

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.