PI 1.2.1 Specification Released

Well, UEFI has been going with smaller and smaller numbers in the revision numbers, trying to convince us all that "nothing has really changes". First, they did it with UEFI 2.3, going to UEFI 2.3.1 and now releasing UEFI 2.3.1c with small normative changes.
Now they are doing it again with the PI 1.2.1 specification. Let's dig in and take a look at what really changed:

1. The Security Architecture Protocol was cleaned up. The SAP is used by the DXE Core to authenticate an image before allowing it to be loaded. More recently, it is being used to handle pieces of the UEFI 2.3.1 Secure Boot infrastructure and TCG measurement. The problem with SAP (which was addressed in SAP2) is that it didn't actually pass in a pointer to the image buffer, which forced SAP implementations to effectively reload the image from the storage device in order to get a good look at it. SAP2 addressed that, and with clarifications, proves faster for faster book.
2. The SetMemorySpaceCapabilities function was added to GCD. Previously, the memory attributes (such as X and Y) were settable through SetMemorySpaceAttributes, but the capabilities were not changeable.
3. A new event, End-of-DXE was added. Previously, there was no clear way to define the end of DXE and the beginning of the Boot Manager portion of the BDS phase. As a result, drivers were attempting to latch onto all sorts of implementation-specific behavior to make sure they were executed before BDS started. The new UEFI event, End-of-DXE, is guaranteed to be invoked before any UEFI drivers or applications are launched and before the console devices are connected.
4. There is now a detailed Super I/O PEI and UEFI driver-model architecture to further standardize the process of adding super I/O device in a compatible way.
5. New signed Firmware File System sections were added, using a header similar to the UEFI certificates to sign the file section contents.
6. The new PCD Get Info Protocol and PPI add functions which return information about an individual PCD item.
7. Added methods for reserving interrupt and exception vectors.
8. Added support for weakly aligned Firmware Volumes. Previously a Firmware Volume's alignment was required and controlled the alignment of individual Firmware Files in the Firmware Volume. That is, if a Firmware Volume was aligned on an 8 byte boundary, it was impossible to include a Firmware File that required 64KB alignment. But this wasn't always useful or desirable, because Firmware Volumes were sometimes just used as containers of arbitrary files.

UEFI May Plugfest Presentations

Hey, UEFI held a plugfest on May 8-10 in Taipei. This was the first time that it was hosted by Phoenix Technologies in Taiwan. The previous two had been hosted by Insyde Software. [Disclosure: these are my previous and current employers, respectively] All of the presentations are availabe on the UEFI Learning Center site. Of note this year is the heavy emphasis on security. Why? Because Windows 8 is driving adoption of and providing world-class implementation of the UEFI Secure Boot feature found in the UEFI 2.3.1c specification. Also at the plugfest were representatives from RedHat and Canonical.

The emphasis on secure boot has raised a big issue for BIOS vendors, as OEMs and ODMs try to get the right set of keys into the flash part. Microsft has released certificates for signed UEFI drivers and signed Microsoft boot loaders for inclusion. And they are planning to open up a UEFI driver signing portal at sysdev.microsoft.com, the same place you go to sign Windows hardware drivers. Insyde (Kevin Davis) presented factory tools for packing up the certificates and keys needed to create a production BIOS. The idea of a BIOS engineer going into a locked room with a private key seems foreign to most OEM/ODM BIOS production processes.

Another interesting set of presentations from Phoenix (Dick Wilkins) and Microsoft (Tony Mangafeste) highlight likely security attack surfaces in UEFI BIOS, now that the boot loader has been secured using signing. They point to buffer overflow attacks, integer overflow and pointer manipulation in bad PE/COFF images as a likely attack. So both Microsoft and Phoenix have contributed fixes to the open-source sample UEFI implementation at http://www.tianocore.org to make the UEFI PE/COFF image loader more robust. They even added some of the security features previously only found in operating systems to the UEFI implementation, such as ALSR, usage of the NX bit and enabling of the Microsoft Visual Studio C/C++ compiler's stack checking and buffer overflow capabilities (the /GS option and /RTCs option).

Brian Richardson, from Intel (and formerly of AMI) went through the resources that Intel is putting out there, focused heavily on the IHV plug-in card vendors, including a nifty UEFI driver template tool and updated UEFI driver writer's guides. AMD rounded out the group with hints on writing good UEFI drivers for video cards, including one of the most common gotcha's: how to report EDID.

Finally, Andrew Sloss from ARM describes why they think UEFI is the standard of choice for firmware on ARM processors and how they are working to enable it for their many industry partners. Two up and coming tricky bits for ARM include ARMv8 (64-bits) and how TrustZone should work with UEFI.  From personal experience, most silicon vendors want to keep TrustZone locked up and tied tightly to their SoC. But at the same time, there are a number of features where an open firmware driver model would be extremely useful. This is something that x86 vendors have known for a long time with SMM, but the ARM community doesn't have its head wrapped around. So there have been proposals to load up TrustZone in SEC, even prior to PEI. Not a good idea, IMO. Part of this is also related to the fact that SEC has traditionally been in the built-in NOR flash, while the rest of the firmware was relegated to an off-chip NAND flash device, giving some trepidation about the security (even though it has always been signed in most commercial implementations). More on this later...