rust, oxide, corrosion,....

	Miguel de Icaza (@migueldeicaza)
12/12/19, 8:01 PM All of us writing C and C++ are living on borrowed time. The only safe future is Rust. Prepare your code to go out of scope.

 
inspired me last night to share some of the EDKII Rust work underway. I filed https://bugzilla.tianocore.org/show_bug.cgi?id=2367 to motivate the posting of
https://github.com/tianocore/edk2-staging/tree/edkii-rust.

Within this package you can find https://github.com/tianocore/edk2-staging/tree/edkii-rust/RustPkg which includes https://github.com/tianocore/edk2-staging/tree/edkii-rust/RustPkg/MdeModulePkg/Universal/CapsulePei 
as an example of using Rust to build an EDKII capability. The idea is not to fork-lift upgrade the entire 1 million LOC EDKII upstream to Rust but instead to migrate critical flows and libraries to a safer language. The capsule example is especially important since the capsule is an attacker controlled data object and the parsing flows are quite complicated https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. The UEFI PI modularity of PEIM's and DXE drivers, along with the language interop of the FFI of Rust to other languages, naturally lend themselves to this evolutionary approach.

And listening to folks like Alex https://hardwear.io/berlin-2020/training/hunting-uefi-firmware-implants.php reminds me of the value of assurance. Thanks Alex for the discussion on language-based-security, including Ada/Spark discussion. It also reminded me of my conversation with Aucsmith in DC http://vzimmer.blogspot.com/2018/09/.

Also interesting to see other plays on "Rust" in the market, such as 'oxide'
https://oxide.computer/blog/introducing-the-oxide-computer-company/
or my favorite 'corrode' https://github.com/jameysharp/corrode for converting C code to Rust. It'll be interesting to see usage of Rust for Oxide's firmware endeavors.

When I look at the above EDKII Rust work, I ask myself if it's a 'sustaining evolution' or 'disruptive innovation' https://online.campbellsville.edu/business/sustaining-innovation-vs-disruptive-innovation/.
Specifically, do examples of disruptive innovations regarding Rust and firmware include things like https://www.ics.uci.edu/~aburtsev/doc/redleaf-hotos19.pdf  with formal or https://github.com/oreboot/oreboot with all Rust and no blobs?

Interesting times.

I try to not to rewind the history machine, but I invariably find myself assessing my engagement with system software during pivots like this. Specifically, when I started working full time I joined a time chartered with writing firmware for a remote telemetry unit (RTU). It was essentially an embedded computer that would be strapped to a gas pipeline to control valves, measure gas flow, etc. It was IOT before IOT was vogue.

My first team requested that I write the code for an 8051 microcontroller in assembly. I asked for requirements and then requested purchase of a C compiler. I was able to produce the features in C and evolve quite readily with the ever changing requirements. Over time I bounced back to assembly for some severely resource constrained usages, but C has become my language of choice.

And worse I was afflicted by large legacy assembly code bases with rich algorithmic capability. For example, there was a PCI resource allocator written in assembly that had down bottom-to-top allocation based upon a specific hardware requirement. When the next generation design required top-to-bottom, the schedule became imperiled by having to rework thousands of lines of assembly to unwind this assumption. Although C doesn't necessarily yield 'better code'', it proved much easier to factor than assembly.

So C has made sense for development efficiency, but the last couple of decades have posed other challenges, such as making assurance claims. Modula-2 never made it https://cseweb.ucsd.edu/~savage/papers/Sosp95.pdf mainstream, nor has C# for OS's https://en.wikipedia.org/wiki/Singularity_(operating_system). And I've already mentioned my own less-than-successful earlier investigations into type safety for firmware http://vzimmer.blogspot.com/2016/12/provisioning-porting-and-types.html.

So nearly 30 years onward I'm happy to have another language transition, namely a assembly-to-C moment with C-to-Rust change.

Accessing UEFI UpdateCapsule from the operating system runtime

"Accessing UEFI from the operating system runtime" http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html 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 https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-capsule-specification.html, 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 https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery with a detailed code explication in https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. On the operating system side, there is infrastructure to support invoking the interface for both Linux https://lists.gt.net/linux/kernel/2149809 and Microsoft Windows https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/system-and-device-firmware-updates-via-a-firmware-driver-package.

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 http://fwupd.org/ to facilitate pushing out updates in a similar fashion to Windows Update http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_07_Microsoft.pdf. https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-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 http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html "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.

Provisioning, Porting and Types

I'd like to begin this posting with a review of work presented years ago. Specifically, my friend Harry H provided me copies of my first three Intel Developer Forum (IDF) presentations from 2003  https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf and 2004 https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf, respectively.

The first presentation was jointly delivered https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf with Bob H and Michael K. This work informed some of the information in chapter 7 of the UEFI Book. The basics of the architecture haven't changed, with the notable exception of advocating the use of Intel(R) FSP https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf and associated marriage with open source platform code on http://www.tianocore.org.

That same 2003 event featured a solo talk on security features https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. This talk included an introduction of the modular network stack which we internally ear-marked for a never-released "EFI 1.2" specification. These API's on slide 15 ended up appearing in the UEFI 2.0 specification circa 2006 http://www.uefi.org/sites/default/files/resources/UEFI_Specification_2_and_Errata_Sept16_08.pdf and later in the open source https://github.com/tianocore/edk2/tree/master/NetworkPkg. Beyond these API's, though, other elements like the EAP-Teanie method were never realized in the market. The best documentation of the latter appeared in a paper on using UEFI in the Cloud on pp. 4-5  https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf. Custom EAP methods violate the design precept of UEFI, namely leveraging well-known art, including authentication methods. Thus the recent focus on TLS for HTTP-S and EAP-TLS for our various network use-cases.

From 2004, other items that landed on the cutting run floor included the EFI_SECURITY_SUPPORT_PROTOCOL on page 20 of the presentation. In the ensuing ten years I attempted to standardize an interface like this in the standards body, but we have ended up instead with a library class https://github.com/tianocore/edk2/tree/master/CryptoPkg which can be layered directly on a static library such as OpenSSL or a private protocol. Finally, the pp 23-24 "COB's" of the EFI_CONFIGURATION_OBJECT_PROTOCOL never appeared in the open source or the standards, but the configuration aspects of slide 30 finally appeared in the UEFI standard from the original OEM-scoped HII Framework standard http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf.

So much for IDF in 2003. In 2004 we presented on EFI Security extensions again in https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf. In this talk we elaborated on the 2003 talk with more details, including slide 17 for PE/COFF EFI image integrity. Since that talk we have evolved a UEFI image integrity model in https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf (2007),
https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Networking-and-Pre-OS-Security.pdf (2011), and https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf (2012).  Same story on the rest of the vision, though. The vision of smart objects like COB's was not realized in the market.

A common theme on the IDF 2003 and 2004 presentation was the topic of provisioning, though. With the UEFI 2.6 specification, x-UEFI, and HTTP boot, the vision has been realized in a different figuration in 2016 https://github.com/vincentjzimmer/Documents/blob/master/UEFI%20Plugfest%202015%20-%20UEFI%20and%20the%20Cloud%20-%20003%20Bulusu%20-%20Zimmer%20.pdf https://github.com/vincentjzimmer/Documents/blob/master/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf. As such, I can claim the ball has been moved down the field in the last decade.

Another topic that perhaps hasn't progressed as much in the last decade entails language-based security (LBS). Back in the early 2000's I investigated how technology like http://www.cs.cornell.edu/talc/ might be applied to the EFI firmware https://patents.google.com/patent/US6978018B2/en, including a failed port to https://cyclone.thelanguage.org/. That's why I am excited to see efforts like https://firmwaresecurity.com/2015/09/04/rust-and-uefi/, including the write up http://ceur-ws.org/Vol-1746/paper-15.pdf. These efforts show promise to complement other security efforts in this space. I also enjoyed the reference in the latter paper to the EFI memory map white paper, UEFI book, and Cloud presentation. To me this affirms the value of openness, from publications down to the source code, in evolving an ecosystem.

Another interesting intersection of Rust and system software is http://www.tockos.org/ which a colleague at a nearby company mentioned to me over lunch. I need to dig into this work in the future.

Speaking of ecosystem evolution, I also want to cite our write up on the recently upstreaming capsule design https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. If this paper work were to have pre-dated the Rust paper perhaps it would have been the capsule reference in lieu of the "BZ15" one? This latter white paper reads on 'platform recovery,' such as described in the UEFI PI specification. As a complementary overview of operating system (OS) recovery there is https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf which explicates some of the technology in the UEFI specification and touched upon by me at the last UEFI plug fest.

Now off from working in an urban area

to a more suburban office

I'm not sure which is spookier.

Well, enough of looking in the rear-view mirror today. Let's instead face the wind screen and continue forward down the road.