Wednesday, August 9, 2017

Accessing UEFI UpdateCapsule from the operating system runtime

"Accessing UEFI from the operating system runtime" represents my most frequently accessed blog posting. In fact I scrawled this quick posting in response to an engineer having recently sent me a mail referencing the above posting and decrying lack of information on access to the UpdateCapsule interface from the various OS's.

To begin, let's start with the API exposed by the UEFI firmware is defined as followed:
The capsule in memory follows:

From my perspective as a 'builder' of firmware I often focus on the underlying constituent elements, but that's a smaller audience than the consumers of the firmware. At the time of the posting, the UEFI Variable interface was the more important interface in order to access both UEFI specification defined variables, namely those {GUID, Unicode String} named pairs codified in the UEFI specification, and vendor-defined variable GUID's and Names.

In the five years that have followed that posting, there's another important extensible run time interface that has been exposed to the operating system run time, namely the UpdateCapsule interface. The Capsule infrastructure began as part of the Intel Framework corpus, but was eventually donated into the UEFI Forum in a similar specification arc as HII. Recall that much of the Intel Framework specifications, such as PEI and DXE, became pillars of the UEFI Platform Initialization (PI) specifications, but when an interface needs interoperability between the pre-OS ISV's and OS runtimes, that is purveiw of the UEFI (and ACPI) specifications. Microsoft complemented this Framework-era capsule infrastructure with the ESRT, or a list of updatable elements in the platform defined by a list of GUID's.

Although the UpdateCapsule API can be used to convey any information from the run into the pre-OS, including crash-dump, management information, etc, the 'firmware update' usage is the most important from a business perspective.

And regarding the API, having a definition of the interface and the data enveloping mechanism are necessary but not sufficient. You also need producers of the update interface on system boards and infrastructure software to invoke the interface. To that end, the EDKII community has published a rich set of infrastructure code to provide the interface with a detailed code explication in On the operating system side, there is infrastructure to support invoking the interface for both Linux and Microsoft Windows

The Linux kernel exposes the capsule loader interface via sysfs in a similar fashion to how the UEFI variable interfaces are exposed. The Windows implementation, though, doesn't expose the direct interface but instead conjoins issuing capsules on top of the infrastructure for installing drivers. This is where the distinction between capsules as a mechanism to pass a GUID-named data payload with a scatter-gather list in memory back to firmware compares to usage of this interface to pass payloads that are a firmware update. On the latter point of updates, the Linux community has build out the fwupd service to facilitate pushing out updates in a similar fashion to Windows Update provides an interesting view into steps involved in plumbing a Linux distribution for this end-to-end use case, too.

You can think of the UpdateCapsule invocation as a syscall back to the firmware. This is different than UEFI Variables where the expectation that the 'set' call persists immediately without and intervening platform restart. Instead, by having the UpdateCapsule take effect (typically) across a restart, the update of the underlying firmware can occur in the early boot of the firmware Trusted Computing Base (TCB) prior to running third party code. Or a capsule can just be passed through, such as the case of the OS runtime sending its panic screen to be displayed across a restart to its UEFI OS loader.

Philosophical postlude -
The difference between UpdateCaspule versus the Get/Set Variable interface is that the latter has been available in the EFI (and then UEFI) OS's since 1999. Update Capsule, and the corresponding ESRT, have only appeared more recently. If I had a chance to invoke George Cox's "I could do it better the 2nd time" penchant of engineering, I would have argued that art such as UEFI Authenticated Variables would have been better built as signed UEFI Capsules versus UEFI Variables since authentication-at-reset in the PI phase (BIOS TCB) is much easier to build than an authentication agent in the firmware that is isolated from the OS or hypervisor run time, as needed by the UEFI Authenticated Variables.
Sigh. Hindsight is 20/20.

Tuesday, August 1, 2017

Black Hat USA 2017 - Firmware is the new black?

Happy to be back from Black Hat in Las Vegas. I usually capture photos of my journey, but I must have lost my head on this trek

since I only captured a couple notable shots, including


Regarding the event itself, our presentation for can be found at I can  nowsafely hang my badge

among my dog pile of other badges.

In that archaeological pile I can find residue of preceding security conf presentations - ToorCamp 2012, BSides 2013, ToorCamp (again)  2014, and CanSecWest 2015.   

I was honored to be among the list of other speakers.

Surprisingly, I wasn't the last name on the list.

My Intel colleagues included Rodrigo from the offense side, I treated defense, and Bruce talked about response.
The talk began with an overview of the ecosystem, including the supply chain that often begins with the open source upstream. Within that upstream many of the core protection, detection and recovery UEFI-based EDKII features were reviewed. This section of the talk culminated in many of the open source EDKII platforms upon which these protect/detect/recover features can be integrated. 

These platforms allows for marrying the rich set of core components with representative platforms The most evolved includes the first Intel(R) Core-based open source platform using EDKII platform code, described in The chipsec project was also reviewed as one means by which to assess if the platform was configured correctly.

After the ecosystem and defense intro, the talk moved into the data set of issues and a proposed methodology. This portion of the talk generated the most interest, at least as evidenced by the number of people taking screen shots of the content.  This taxonomy included:

and a histogram of issue appearances

This class of information can help inform test strategies and investigation into new defenses.

After the data review, a cursory discussion of threat modeling was presented. This class of erudition also informs what type of defenses and testing needs to occur. Like the former topics, this portion of the talk wasn't intended to be complete so much as argue for the need to have this type of review with the broader research and platform building community.

And for any large effort, the collaborators for the deck and our colleagues are the most important part of the adventure.

The talk was picked up by the press ahead of time We were approached by other publications to give an interview but interleaving day-job and conference ate up the available hours, I fear. Thanks to a Charlie Miller tweet at least there's some evidence that we made it to the stage

To close today's blog, this should not be the end of this material for 2017. I promised to reprise this talk for at the lodge in my backyard here in WA

    The TENTATIVE schedule for DC206 Meetings:
    Sep: Josh, Coffee Roasting
    Oct: Taylor, intro to Bash
    Nov: Vincent Zimmer of Intel, UEFI security
    Dec+: CfP open

Hopefully I can recruit my co-presenters to trek up I-5 to help out, too.