Open platforms snapshot - May 2023

From https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel there are a rich set of platforms for EDKII in the open. 

Other than emulation platforms like SIMICS or 32-bit IOT Quark, which are all open source, the rest of the platforms are based upon variants of the Intel Firmware Support Package (FSP) https://github.com/intel/fsp

 

But how did this journey begin?

The first public discussion of the need to have a simpler, more open set of platform code commenced in 2014. I described this 'min tree' effort in the following 2015 prezo  https://github.com/vincentjzimmer/Documents/blob/master/OSTS-2015.pdf

 

 

 

 with guidance around how to take a large internal, closed source corpus into something smaller

 

 The strategy included the following elements

 

 

I described the value of open source for security assurance in another venue https://www.intel.com/content/dam/develop/external/us/en/documents/stts003-sf15-stts003-100f-820238.pdf

including the Baytrail-based MinnowBoard and Quark

 

The challenge at the time was how to structure the code. We used Quark, since it was fully open, to model some of the software practices 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

 

 

 

 

The approach entailed a decomposition of the workflow for configuration, porting, and feature addition.

At this point we only had Atom-based Minnow in the open. During this time we worked w/ the business units to get permission to open up a big core based platform code, namely Kaby Lake, and a Xeon big core server, namely Purley. The work is described in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf

 

 

 

 

These studies provided a decomposition both logically

 

 

and in the source code

 

 

We updated the ecosystem on this work in https://www.platformsecuritysummit.com/2018/speaker/

This provided an overview of the server work and also a description of the software stacking.

Another view provided the workflow of the open source core on the left, the silicon packages in the middle, and the open source platform code on the right in order to curate a complete solution.

The best description of the overall workflow with a given SOC was described in https://www.intel.com/content/dam/develop/external/us/en/documents/uefi-firmware-enabling-guide-for-the-intel-atom-processor-e3900-series-820238.pdf in 2018
 

Just as we explicated security best practices in  https://link.springer.com/book/10.1007/978-1-4842-6106-4, we did describe some of this platform work that is now embodied as the 'min platform architecture' (MPA) https://github.com/tianocore/tianocore.github.io/wiki/Minimum-Platform-Architecture--MinPlatform.

Specifically, the book https://link.springer.com/book/10.1007/978-1-4842-7974-8 and its associated site https://github.com/Apress/Firmware-Development touch on this topic

 

With the evolution of a min-tree and min platform

and the MPA stack itself.

This work is also included in training material https://github.com/tianocore-training/PlatformBuildLab_MinPlatform_FW.

 

The arc of time...

 

PS

Mentioning MPA doesn't mean that there are not other open opportunities beyond EDKII.  There is https://github.com/slimbootloader/slimbootloader/tree/master/Platform

and https://github.com/coreboot/coreboot/tree/master/src/mainboard/intel

 

 

You can find info in https://link.springer.com/book/10.1007/978-1-4842-7939-7 https://github.com/Apress/System-Firmware

 

for slim bootloader

 

 

and coreboot, respectively.

Which software gets the 'least respect?'

During one of this week's sunny afternoons it was good to see the two Mike's at the Intel Ridgepointe office RPT1-3. Sightings of other humans on cubicle-land is rare in this post-COVID WFH generation. Our gathering in the corner reminded us of a ritual we started in 2000, namely getting coffee in the corner on the 4th floor of the DuPont Intel site DP2-4. The decoder ring is 'site | building #-floor #'. 

We cannot really reprise the event at DuPont given recent history of the site mentioned in http://vzimmer.blogspot.com/2018/07/the-march-of-time.html. 

For the above picture, I'm on the left, Mike Kinney is in the middle, and Mike Rothman in on the right.

Kinney way back machine of IDF 2003

Rothman way back machine of BB 2006.

Back in the early 2000's when we had a coffee corner in DuPont, Mark Doran was a fixture, too. Sadly Mark's commute to the new office is pretty challenging given the eastside of Seattle traffic, so we grafted him into the above image to reproduce the quartet as a virtual attendee.

Here's a way back for Mark

https://redirect.cs.umbc.edu/portal/help/architecture/idfefi.pdf

https://masters.donntu.ru/2020/fknt/yakubov/library/article9.pdf 

It doesn't look like we have many prezos or papers w/ all 4 of our names, but there are a few items like

These couple of drop-e's reminded me of my favorite paper w/ the drop-e that'll be 20-years old next January.

So speaking of firmware and history, rewind to 2012 when I presented at ToorCamp on UEFI, as mentioned in http://vzimmer.blogspot.com/2012/08/one-conference-down-one-to-go.html.

On one of the earlier slides in the deck I joked about how firmware gets 'no respect' in the slide below.

Why no respect? Well, hardware teams assume firmware is 'software' and the software teams look at the firmware folks as members of the 'hardware' clan. Rodney Dangerfield provided the ideal quotation https://www.youtube.com/watch?v=ZCVR_ajL_Eo https://www.amazon.com/I-Dont-Get-No-Respect/dp/0843101938 that inspired the slide.

This is one of my favorite quotes about firmware, along with the original IA64 platform manager in DuPont who provided me https://link.springer.com/book/10.1007/978-1-4842-0070-4 in the late 1990's.

Hale & I were definitely in the 'firmware is software' camp in the 2010 prezo associated with the paper http://masters.donntu.ru/2020/fknt/yakubov/library/article6.pdf "Firmware is software so can suffer well known software ills."

So why am I talking about Rodney Dangerfield in 2023? I suspect the Youtube and TikTok generation won't recognize the allusion. The reason comes from a recent event.  Namely, when I visited  https://www.cs.washington.edu/events/colloquia/details?id=3305   https://www.youtube.com/watch?v=uL4H1ct_-dI talk this week

I couldn't help but smile at the oration during the 2:00 minute mark. 

Pat mentioned that when he won his Turning Award, his congratulatory message from UW Ed Lazowska (the attendee sitting immediately in front of Pat) read something like "Congratulations on your award for computer graphics which is the 'Rodney Dangerfield' of computer science." If Pat Hanrahan's work is the "Rodney Dangerfield" of comp sci, then I guess BIOS/firmware and my Rodney allusion from '12 is misplaced. Maybe firmware isn't even part of the comp sci software corpus :) ?

Good stuff.

What I did like about Pat's talk included the fact that he focused on a problem no one else was looking at. It reminded me of the quote from Yan LeCun that the biggest impact in AI will not be in one of the explored domains but instead in an unvisited path. That's why I like reading old math or technology books and papers. They may not demonstrate the cutting-edge change upon the frontier of knowledge, but perhaps there are some alternate views or approaches buried that can be applied in a new context?

Ghosts and podcasts

When the topic of banned function like memcpy https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/memcpy-wmemcpy?view=msvc-170 come up I have to smile since sometimes 'compatibility' (aka 'the software you choose to run) argues that this is still inherent service for software. This includes 'copymem', the UEFI variant of memcpy, as a fundamental system service in UEFI https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-copymem and encouraged in https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/4_general_driver_design_guidelines/44_optimization_techniques/443_copymem_and_setmem_operations.html#443-copymem-and-setmem-operations. 

So if existing software still uses these services, what to do? One option is to provide isolation to contain the damage, viz,  https://uefi.org/sites/default/files/resources/Enabling%20RUST%20for%20UEFI%20Firmware_8.19.2020.pdf

with EBC or ring's https://cdrdv2.intel.com/v1/dl/getContent/671411

or virtualization http://masters.donntu.ru/2020/fknt/yakubov/library/article5.pdf https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer08.html

Moving forward, though, leveraging modern languages and types to enforce safety https://stanford-cs242.github.io/f18/lectures/07-1-sergio.html still feels like the right trend. Speaking of Rust in firmware https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf, the GSOC produced first-class UEFI support in Rust in the form of the UEFI crate https://crates.io/crates/uefi for applications. As noted in the above prezo, the retrofit is touch for a large codebase, but a smaller unit of execution like a UEFI application, namely OS loaders, makes sense, especially in light of incidents like https://vulcan.io/blog/boothole-vulnerability-cve-2020-10713/.

And it looks like beyond all-Rust efforts like https://github.com/oreboot/oreboot, coreboot is now pursuing adding Rust support https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/3QRO6A5BCFWCGHE7ZUCFGR7VL7AJ2XKQ/. The mention of payloads first makes sense since this is a stand-alone entity and doesn't entail the challenges of mixing non-borrow-checker aware C code with Rust. 

This Rust-as-a-payload aligns with https://universalscalablefirmware.github.io/documentation/ POL thinking, too

I cannot recall if I mentioned in the past how even chatting w/ the Google Chrome folks from Kirkland WA and VMWare Research guy from their Bellevue office during UW lunch event how they eschew the mixing and instead are targeting Rust for more stand-alone execution regimes like plug-ins for the browser and a service for the virtualization environment, respectively. 

As noted in the Stanford lecture, types can help but there has been a complaint that subsets of type-safe languages like Ada Spark are the true gold standard. That's where work on 'Ghost types' is so interesting with the Rust community. I first heard about this from Parno and followed-up on some of this work in https://arxiv.org/abs/2303.05491 https://arxiv.org/pdf/2303.05491.pdf https://github.com/verus-lang/verus and discussions with the community in https://docs.rs/ghost/latest/ghost/ https://github.com/rust-lang-nursery/wg-verification/issues/14. Ghost types will allow for no-harm source augmentation to have more verification-ready language conditions, as opposed to going to some intermediate or non-standard verification-friendly language like Dafny or F*. The important part of adding software assurance is to avoid taxing the developer as much as possible. 

As always, keep watching the Rust space for firmware.

Beyond languages, I recently received

shirt in the mail. 

That same day I was listening to the podcast on PTAB https://www.aurorapatents.com/blog/patent-wars-innovators-revolutionaries-and-the-race-to-reform on commute back from the office. My tidy cube is shown below with my friendly panopticon image nearby.

A few interesting fragments caught my attention, such as hedge funds bringing cases to PTAB. This reminded me of Trammell Hudson and his Two Sigma hedge fund https://www.twosigma.com/ and some of the rationale for research like Thunderstrike https://trmm.net/Thunderstrike2_details/ agsint folks like Apple when we chatted in person years back.

Other discussions about recusal for conflict of interest made me smile. I hearken back in the mid 90's when in my Compaq Computer Corporation new employee orientation down in Houston how I was chided not to transact stocks in 'customer, competitor, supplier,...' of Compaq. At the time this pretty much covered most companies on the stock exchanges. This early career lesson has stuck with me in that for the past 30 years working in tech I have been afraid to buy any shares outside of my employer and outside of my employer's stock program.

The other interesting podcast I caught was https://www.lawfareblog.com/lawfare-podcast-rob-joyce-nsa-director-cybersecurity. Hearing the director of the NSA casually opine on large language models and post-quantum cryptography is such an amazing change from my recollection of the NSA growing up. In my early years it was 'no such agency' typified by reading books like https://www.amazon.com/Puzzle-Palace-National-Intelligence-Organization/dp/0140067485. Quite the change.

Well, so much for banned functions, Rust, and podcasts. On to the next weekend to-do's.

Upgraded view

My last cubicle with a windows view was the south Seattle Union Station office mentioned in http://vzimmer.blogspot.com/2016/02/firmware-configuration-or-is-feature.html. Today I'm happy to be camped in a 3rd-floor cubicle in the Bellevue Washington Intel Ridgepointe office with the following view snapped earlier today

I need to be a bit wary on the sojourn across the street, though, as the https://www.geekwire.com/2023/suspect-in-alleged-stabbing-of-fellow-microsoft-employee-pleads-not-guilty-to-attempted-murder/ event was a block away.

Luckily if you go the other direction you'll find an oasis of food.

And after hours the neighbors across the floor here are a bit noisy, especially the duck.

Speaking of noisy, I noticed that https://www.scmagazine.com/podcast-episode/bts-6-vincent-zimmer went live today. I recorded this interview from a conference room on the 2nd floor of Ridgepointe. 

 

Interesting times.