The Tale of Three Conferences

This week has been a blizzard of news and announcements from three conferences that I care about, all this week. First, there was EELive! in San Jose, CA which focused on embedded systems (or, as they now like to call it, the IoT). Second, there was Intel's Developer Forum in Shenzhen, China where my company (Insyde Software) was exhibiting and speaking. Finally, there was Microsoft's Build 2014 which I was watching with avid interest with live streaming and press releases flowing. UEFI was there, to either be promoted or vilified or both, in all three.

At first glance, at EELive, you would think that no one is paying attention to UEFI. Part of this was because Intel was busy promoting FSP, touting how it could be plugged into any boot loader, including coreboot. But the Galileo board that they were showing comes with a UEFI solution. And, under the hood, FSP is really extracted firmware drivers from Intel's UEFI-based reference code, packaged in UEFI-standard firmware volume format, with a little director binary inserted to allow direct calls into the driver entry points. The other reason is that 32-bit and smaller processors still dominate the IoT space and many of those are ARM designs. ARM platform 32-bit designs have used other boot loaders traditionally, but with 64-bit ARM itself is heavily pushing UEFI as a standard boot architecture. Many discussions around UEFI have to do with complexity. And there is something to these discussions, since the very power and flexibility of UEFI has led to implementations (like that on tianocore.org) which are broken into hundreds of pieces, where assembling the right one requires the right recipes. Most embedded vendors don't need their firmware distribution to be as complicated as their Linux distribution (see yoctoproject.org).

Then there's IDF. Of course, there was the Insyde poster chat: Implementing Dual OS Solutions with UEFI FIrmware" (how to switch between two active OS sessions w/just firmware support). Intel delivered their obligatory Quark and FSP remarks. But it also put out two additional UEFI-related notes. The first appeared in the unlikely session titled "Delivering Compelling User Experiences on Intel® Platforms: Audio, Voice, Speech and Fingerprint Sensors and Biometric Authentication" But in the very back of this presentation, they talked about security issues pertinent to BIOS, including replay-attack prevention related to Real-Time Clock battery removal and secure firmware updates using the UEFI capsule update method described in the UEFI 2.4 specification. It really seemed out of place, but hey... They also recommend adding their new CHIPSEC tool, which performs security checks on chipset and firmware settings. It is available on github.

And then the Intel Android team showed their Android build tool which would create a BSP for your platform and hey, it would also customize your firmware at the same time. It leverages the Unified Binary Management Suite (UBMS), which you can see here at about the 21 minute mark. This shows the increasing co-design process required for configuring your firmware and your OS installation. Many times, the firmware and the OS need to know the same types of information about the platform. For example, which drivers to include, GPIO routing, etc. Especially on OS' that don't use ACPI and that don't rely on the firmware passing them anything (like Android).

Finally, there's Microsoft Build event. We got a definitive date for the Update 1 (with no major new BIOS requirements! Sigh of relief), Microsoft's plan to offer Windows for $0 for certain platforms, Windows booting on Quark(!). And a lot of advice about how to integrate off-SoC sensors and how to write apps that span Windows and Windows Phone.

Hard to breathe. Need air. Next week I'll have a chance to reflect further on what some of these mean. How can we take advantage of vertical integration? How can we reassure folks of security in a world where firmware is increasingly decentralized and under attack? (Did I mention EELive! had a Black Hat track???) More later....

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