Second port of Tianocore to OpenPOWER

Check out the Comments section of the recent post on Tianocore being ported to OpenPOWER:

So there are TWO ports of Tianocore to OpenPOWER, and a few days ago I knew about neither of them.

I wonder if OpenPOWER will officially adopt UEFI as a firmware option for their platform. I’ve heard indirect bragging from IBM that their systems can be 100% fully open source firmware, no blobs.

UEFI HTTP Boot whitepaper available

A few weeks ago the Tianocore project added a whitepaper on UEFI 2.5’s HTTP Boot:

If you were looking for instructions on how to setup Tianocore’s HTTP boot feature, on Windows-based systems, this document is for you!

I could be wrong, but I don’t think the TLS API has been added to Tianocore yet, so there is no HTTPS, only HTTP.

(Looking at the above SourceForge URL, it appears the Packaging Tool document was also recently updated, but not sure of the details.)

UDK2015 expected mid-October

The UDK github wiki has been updated to give information about upcoming UDK 2015 release next month. It appears to include most UEFI 2.5 features, plus a few new ones. Excerpt of changes:


Support UEFI 2.5 Updates:
 + Smart Card Reader & Smart card edge protocol (H file only)
 + Inline Cryptographic Interface Protocol (H file only)
 + UEFI USB Function I/O Protocol (H file only)
 + Add NVM Express Pass Thru Protocol
 + Add UFS stack
 + Add SD Device Path (H file only)
 + Add reconnect Browser Action
 + Ability to refresh the entire form
 + The default/options for the Ordered List question
 + Keyword Strings support
 + New CPER Memory Section (H file only)
 + Adding support for No executable data areas
 + Persistent Memory Type support
 + Add the Support for new PKCS7 Verification Services
 + System Prep Applications
 + Add SMBIOS3_TABLE_GUID in configuration table.
 + Exposing Memory Redundancy to OSPM
 + ESRT: EFI System Resource Table and component firmware updates
 + IPV6 support from UNDI
 + UEFI “Next” Feature –
    * IP_CONFIG2 Protocol
    * Boot from HTTP (Excluding IPV6)
    * DNSv4 and DNSv6

Support PI 1.4 Updates:
 + New MP Service PPI
 + Multiple CPU health info
 + PEI SetBootMode Service() clarification
 + GetMemoryMap Update for ReservedMemory
 + New Graphics PPI
 + New Capsule PPI
 + SIO PEI and UEFI-Driver Model Architecture
 + Extended File Size Errata
 + Add Reset2 PPI

Excluded from UEFI 2.5 Updates:
 + Bluetooth Support (H file only)
 + Errata Boot Manager Policy & SATA Device Path Node
 + RamDisk Device Path
 + UEFI “Next” Feature –
    * Boot from HTTP (Excluding IPV6)
    * WIFI support (H file only)
    * EAP2 Protocol (H file only)
    * REST Protocol
    * Platform recovery
    * Customized Deployment of Secure Boot
    * BMC/Service Processor Device Path

Other features:
 + Add ACPI 6.0 definitions.
 + Add SMBIOS 3.0 definitions.
 + Support OpenSSL version 1.0.2d.

Looking forward to the upcoming checkins to Tianocore’s EDK2 trunk!

Full roadmap article:

KVM Forum 2015 materials available

[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the link below instead. ]]

The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:

Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf

Using IPMI in QEMU
by Corey Minyard×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf

More Information:


Today on the UEFI development list, Laszlo Ersek of Redhat announced an OVMF BOF at the upcoming KVM Forum, including Paolo Bonzini speaking on adding SMM to OVMF for KVM and Tianocore. This is a massive checkin, and having SMM in OVMF makes it a lot easier to trace and fuzz. Event aside, the list of the last year’s worth of changes to  OVMF/AVMF makes for an interesting read. Heavily-edited announcement follows:

Let’s do an OVMF BoF at this year’s KVM Forum too. Paolo will present “Securing secure boot: system management mode in KVM and Tiano Core” on Thursday, August 20, in the 5:00pm – 5:30pm time slot. Right after that, the BoF section starts at 5:30pm. We should convene and discuss stuff. I don’t have an agenda, so people should bring their ideas and questions (famous last words).

As food for thought, I tried to collect the feature-looking patches from the git history that have been committed since last year’s KVM Forum, and to match them against patch sets on the mailing list:

git log –reverse –oneline –since=2014-10-14 — OvmfPkg/ ArmVirtPkg/ ArmPlatformPkg/ArmVirtualizationPkg/

I attempted to sort them into categories. You can see the list below. The ordering is totally random, it’s just what I ended up with. Corrections / additions welcome. One (missing) feature I’d like to see discussed is: “SataControllerDxe in OVMF”. SMM will require Q35, and the only “IDE” that Q35 speaks is SATA / AHCI. (And you can’t disable that controller on Q35.)

Features completed (… unless marked [pending])

– Xen guest:

  – PV block driver:
    [PATCH v4 00/19] Introducing Xen PV block driver to OVMF

  – Xen for ARM:
    [PATCH v5 00/29] Xen/ARM guest support

– PCI / hw related:

  – PCI on ARM; detect VGA and USB keyboard:
    [PATCH v3 00/28] ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI
    [PATCH 0/4] ArmVirtualizationPkg: PlatformIntelBdsLib: dynamic console setup

  – support for Q35:
    [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type
    [PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

  – USB3 (ARM and x86):
    [PATCH v2 2/4] ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
    [PATCH v2 4/4] OvmfPkg: include XHCI driver

  – support TCO watchdog emulation features:
    [PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register

  – virtio-vga:
    [PATCH] Add virtio-vga support

  – support extra PCI root buses for NUMA-locality with assigned devices:
    [PATCH v3 00/23] OvmfPkg: support extra PCI root buses

– QEMU config integration:

  – fw_cfg, boot order, and -kernel booting on ARM:
    [PATCH v4 00/13] ArmVirtualizationQemu: support fw_cfg, bootorder, ‘-kernel’
    [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

  – support for “-boot menu=on[,splash-time=N]”:
    [PATCH v2 0/3] OVMF, ArmVirt: consume QEMU’s “-boot menu=on[,splash-time=N]”

  – ACPI tables for ARM:
    [PATCH v2 0/3] ACPI over fw_cfg for ARM/AARCH64 qemu guests

  – SMBIOS features: Type 0 default, and SMBIOS 3.0 support on ARM and x86:
    [PATCH] OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
    [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
    [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

– ARM specific:

  – “fun” with the caches:
    [PATCH v4 0/5] ArmVirtualizationPkg: explicit cache maintenance

  – secure boot:
    [PATCH v3 0/3] ArmVirtualizationQemu: enable support for UEFI Secure Boot

  – performance optimization:
    [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection

  – better handling for the typical Linux terminal (generic driver code, hooked up to ArmVirt):
    [PATCH V4 0/5] Add TtyTerm terminal type

– SMM for OVMF (in progress):
    [PATCH 00/11] Bits and pieces
    [PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32) [pending]

– Build system:

  – moving to NASM:
    [PATCH 0/7] Convert OVMF assembly to NASM
    [PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

  – accept UTF-8 in .uni files:
    [PATCH v4 00/10] Support UTF-8 in .uni string files

  – LLVM/clang support for AARCH64 (in progress):
    [PATCH v4 00/13] BaseTools: unify all GCC linker scripts
    [PATCH v4 0/7] small model and clang support for AARCH64 [pending]

– UEFI compliance:

  – support for OsIndications:
    [PATCH v2 0/9] OvmfPkg: PlatformBdsLib cleanups and improvements

  – signal ReadyToBoot:
    [PATCH 1/8] OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel

  – signal EndOfDxe:
    [PATCH v2] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
    [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

  – fix Serial IO Protocol issues flagged by SCT
    [PATCH V4 0/5] Some improvements on serial terminal

– other

  – big OVMF guests:
    [PATCH v2 0/4] OvmfPkg: enable >= 64 GB guests

  – IPv6 (conditionally enabled):
    [PATCH v2] OvmfPkg: enable the IPv6 support

  – many fixes for toolchain warnings and C language misuse

More Information:


Earlier this month, Laszlo Ersek of Redhat contributed a large patch to the TianoCore project, adding SMM support to OVMF.

“OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure, and in the UEFI variable driver stack. The purpose is (virtual) hardware separation between the runtime guest OS and the firmware (OVMF), with the intent to make Secure Boot actually secure, by preventing the runtime guest OS from tampering with the variable store and S3 areas.”

The changes require QEMU usage with these flags:

qemu-system-i386-machine q35,smm=on,accel=(tcg|kvm)-global driver=cfi.pflash01,property=secure,value=on -smp cpus=1 …

This new OVMF SMM works on the q35 machine, only in uniprocessor guests, and with TCG acceleration it only works on x86 not x64. Apparently the lack of 64-bit support is due to 64-bit code not available in TianoCore(?):

“In addition, using OvmfPkgIa32X64.dsc or OvmfPkgX64.dsc, the patch set even stops building after a point, *if* -D SMM_REQUIRE is passed. This is due to the unavailability of 64-bit open source components from Intel, and the build breakage is fully intentional — it shows that the -D SMM_REQUIRE feature is build-level incomplete for OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc, and marks precisely where further development is needed.”

More Information:

Check out the 58-part patch on the mailing list, the first and last messages have a lot more documentation:

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 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

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’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…

Dell Firmware blog and Intel UEFI training

I just became aware of another firmware blog, by William Leara of Dell:

If you’ve not seen it, it’s worth reading, if you care about UEFI.

In this article, he mentions some of Intel’s UEFI web-based training:

In addition to this Flash-based training, Intel SSG also has a 3-day class for Intel employees, which they upload the labs and presentation materials to the public. They maintain this courseware, new versions of the presentations/labs are occasionally updated. If you are a Windows/Visual Studio user, you’ll be right at home with the labs. If you are a Linux user, there is a small amount of content focused on Linux, otherwise you’ll have to ignore all the screenshots of Visual Studio users clicking and right clicking. In the future, I wish Intel SSG would add audio/video layers, in addition to presentation and labs. Download and the most recent Presentations<YYMMDD>.zip from:

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: