Wednesday, December 31, 2014

Given it is the final day of 2014, I thought that my final blog of 2014 would treat the year.next which commences in a few hours, maybe with another one of my infamous TL:DR-style postings? Specifically, I'd like to build upon missive from Tim Lewis at http://uefi.blogspot.com/2014/10/security-to-eclipse-user-features-as.html wherein he shared his belief that security concerns in the platform firmware will predominate as the top user story of 2015. Given the sampling below from 2014, he may be observing an unenviable trend line.

The other CCC talk was on EFI and Thunderbolt https://www.youtube.com/watch?v=5BrdX7VdOr0. Glad to hear from the Matthew Garrett question to the presenter near the end of the talk that the option ROM vulnerability could have been mitigated if the Apple platforms implemented UEFI Secure Boot with option ROM verification (i.e., UEFI Driver Loading) enabled.

These security events and broad use of UEFI and edk II-based platforms definitely argue for the need to have additional industry coordination. This is a role that CERT has done admirably, but as Tim noted, they are now joined by the UEFI Security Response Team (USRT) http://www.uefi.org/security. This effort has been followed by a more code base-specific effort, too http://tianocore.sourceforge.net/wiki/Security. I am happy to be involved in both and although my CVSS-Fu isn't too evolved yet, I'm trying my best in writing technical advisories and doing the associated grading.

It is interesting that the references for both BH and CCC https://www.youtube.com/watch?v=5BrdX7VdOr0 talks above cite the Intel Framework Specifications at www.intel.com and not the superseding UEFI Platform Initialization (PI) specifications http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. This might contribute to some of the ambiguity seen in the boot script implementations, for example, noted in the CCC talk, since the Intel Framework specifications are frozen after having been contributed to the UEFI Forum. Maybe posting a ZIP of the PI specs and a PDF of the Framework makes the latter more search-engine friendly?

Jiewen and I designed features like the Lock Box protocol https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h to allow for protecting the boot script memory, via SMM or other container, back in 2009. But issues in seeing the protections deployed are compounded by the sheer difficulty in implementing S3 resume in platforms. Specifically, getting the functionality correct and having less-easily testable properties like securing the boot script has proven challenging. As a platform developer the last call you want to hear during product development is from the SQA team, saying "Everything works great, but our S3 resume testing fails once out of 10,000 times."

"An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded."

These Compatibility Support Module (CSM) behaviors are something that only the platform implementation can deduce and are difficult to detect via a later test, although heuristics like scanning 0xC0000p through 0x100000p in the address space 'could' be done.

The HSTI interface builds upon the Adapter Interface Protocol (AIP) class of structure defined in the UEFI 2.4 specification http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf. Since AIP producers are boot service only, a pre-OS agent needs to query the HSTI interface in order to cull the settings and convey the results into the operating system run time, if needed, in a vendor-specific fashion.

Who knows, at some point maybe these reporting and testing efforts will all align?

Well, if you have gotten this far, the 'Didn't Read" portion of "Too Long, Didn't Read" (TL;DR) hasn't been the case for you. I'm not sure whether to reward you for your stoicism or not for wading through this entry.

To summarize, 2014 has shows a spate of security-related activities, both by the attackers (BH, CCC) and the defenders (USRT). The firmware-producing and consuming community is acutely aware of assurance concerns and new testing methodologies have been deployed in '14 and are coming in '15, too, including HSTI. I don't necessarily subscribe to the 'Spy versus Spy' aspect of security, or fall into existential angst that the "Defenders Dilemma" is not solvable. Instead, I see many parties passionate about having robust, usable systems and collaboration on art to achieve those goals. Open source, open documentation, open specifications, open platforms,.... All help in the cause.

And if you're still working these last hours of today, pause and have a coffee.

Saturday, December 20, 2014

Yesterday my last day in DuPont after nearly 18 years, 15 of those in the same cube, here at this WA Intel site. Off to work at the Seattle office in early '15. So long, DuPont, and thanks for the memories. And all of the Fish, although in this case 'Andrew Fish.' Although Fish doesn't work at Intel any longer, the inventor of the "Intel Boot Initiative" (IBI), which became EFI/UEFI, still lives in the South Puget Sound. We broke bread for the final time at our favorite local restaurant.

During my final days at Compaq in late 1996 I talked to Intel about joining, and my options were "Join Portland for Xeon, or DuPont for Merced." I was inspired by the thought of joining the 64-bit revolution, so there was no doubt in my mind as to which locale to choose. Also, having grown up in Texas, the Pacific Northwest was a large unknown, so the distinction between OR and WA didn't even factor into my decision.

And my whole tenure at Intel in DuPont since February 1997 has been boot firmware. I began with a PC/AT BIOS underneath the Merced System Abstraction Layer (SAL), with the original OS loader interface of SAL_PROC (0x13), as a 64-bit mapping of BIOS 13h. Same for video mapping of SAL_PROC (0x10), keyboard of SAL_PROC (0x13), etc. The OS community wasn't amused.

As the OS interface evolved to C-based IBI, then EFI, the underlying boot infrastructure changed. I moved from driving some of the SAL-on-BIOS for server (aka "FrankenBIOS"), to the short-lived Workstation Product Division (WPD) where we evolved a C-based boot solution. The latter pioneered art such as the Furball and interposer, which were the predecessor of the Intel Framework Compatibility Support Module (CSM) and CSM16 binary. We called the former 'furball' because it was something we imagined a native 32-bit (IA32) and 64-bit (Itanium) firmware solution would eventually 'cough up', with a less than pleasant imagery derived from the world of cats.

In 1999 we had evolved the workstation firmware to binary modules called "Plug-In Modules", or PIM's. I recall a fateful meeting with the lead on that effort and my colleague visiting from OR. The conversation went something like 'And we can also put the PIM's into option ROMs, too.' At that point I realized the trajectory was ill-fated since the problem with open platforms and option ROM's isn't factoring code to run in that storage container so much as 'how' to interoperate with the system firmware, namely what API's to expose, where to define them, and how to evolve this art. And to that end, I realized that EFI would win as it was the only man standing to solve this problem.

Specifically, EFI nailed down the interface methodology to the OS loader and option ROM community where the broad interoperability was needed. Moving the underlying initialization firmware to a new methodology, such as what became Intel Framework and then UEFI PI was valuable, but not the necessary first step. The first step was to lay the foundation for broad interop in order to have time for the top-level OS and IHV ecosystem to start moving their dependent infrastructure.

At that point in my career when I had that realization, I was lucky enough to have a friend and Intel colleague like Andrew Fish who suggested I have lunch with Mark Doran. Afterward I on-boarded to the EFI team in 1999 and the rest has been a great 15 run on helping evolve EFI into UEFI, EFI-on-BIOS into Framework and then UEFI PI, and the open source offering from "EFI Sample" to EDK to today's EDK II. Since then a lot of code and specifications have ensued

with hopefully more to come in 2015+. Not sure if there is another 15 years into the run. Although one co-developer of Tiano, the code-name for the underlying Framework (and now PI work) quipped a few years ago "We said Tiano was the '20 year' BIOS replacement solution, so when did you start counting?"

Speaking of 2015+, I had better get back to work if I want to get a head start on the next way of the firmware revolution started in South Puget Sound, WA.