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