Wednesday, May 24, 2023

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

I was a strong proponent of openness allowing for better security. One caveat I missed was that once the code is out there and bugs are found, then others will all lean in to help fix, at least for shared 'core' code, not https://en.wikipedia.org/wiki/Tragedy_of_the_commons



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 idea behind 'min tree' was to right-size things. One of the concurrent investigations was to subset the main edk2 upstream, including breaking down some of the existing packages https://github.com/tianocore/edk2/compare/master...jyao1:edk2:ReOrg. Many companies do git-filtering to pull a subset or curate a smaller list of packages, like https://microsoft.github.io/mu/ with https://github.com/microsoft/mu_tiano_plus. The platform clean-up was easier since we historically cloned-and-updated platform code per generation, whereas the core packages are often reused, with figures like below from http://masters.donntu.ru/2020/fknt/yakubov/library/article6.pdf

Then there is also the 'Tragedy of the Commons' allusion wrt core I mentioned above.

As such, the feedback from the ecosystem at the time was that convincing management types to change a code base, albeit for a slimmer one, was a hard sell since it would invariably lead to new issues, including potential bugs. The older core had the advantage of years of flight-testing, namely evidence-of-use. But I was told that if new capabilities were added to vet the quality, such as testing / unit testing, then it would be an easier argument. That was a tough story to sell 5+ years ago but today falls on more friendly ears with the community rallying around things like https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg. Even though there are a paucity of unit tests written today, the above package forms a foundation to get that trust such that more radical refactoring can be done with higher confidence. I remember the TPM TSS project lead telling me that they had 90+% code coverage and any potential commit that broke a unit test or dropped that % was automatically rejected. 

The same story holds for evolution of new techniques like memory-safe languages like Rust into a large extant code base. Although the rewrite of critical libraries in Rust https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf showed efficacy



given history like https://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf



the cost of integrating the language in mainline and the hardening since 2009 make it a hard sell. But for 'new code' with tricky attacker-controlled data types, perhaps the dialectic can lean toward embracing language-based security?

Speaking of wisdom of others, some of this work for a min* was motivated by a comment I heard from https://en.wikipedia.org/wiki/Window_Snyder, namely 'the security defender's best weapon is the "delete" key.' Specifically, deleted code cannot have CVE's or a lack of test coverage. So 'min' as a tactic for 'less code' is often a salubrious path to pursue.

Regarding the thread on platforms above, mentioning MPA doesn't mean that there are not other open opportunities beyond EDKII.  There are examples such as 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.


Speaking of the various platform code embodiment's, efforts like Universal Scalable Firmware Architecture (intel.com) https://universalscalablefirmware.github.io/documentation/ work to find reuse across these different environments


 This work also mentions accommodating Rust-based designs, including https://github.com/oreboot/oreboot, which is mentioned in the first of the two books above https://link.springer.com/book/10.1007/978-1-4842-7974-8, too.


 and https://github.com/u-boot/u-boot, too


 including its use in https://github.com/openbmc/openbmc


PS
Sometimes my blog posts are like Joyce's Finnegan's Wake where the last sentence and the first sentence of the book overlap.  Or maybe a snake eating its tail?  Whatever the literary motif or allusion, another of the slides from the 2015 prezo at the top of this post, namely



reminded me of more recent happening in the industry, namely the 2021 prezo from AMI https://www.youtube.com/watch?v=SeiigV8PJPE and the Aptio Open edition. It describes their variant of this 2015 vision for OCP realized in practice in 2021


This leverages the work out of the Open System Firmware (OSF) https://www.opencompute.org/wiki/Open_System_Firmware

https://docs.google.com/document/d/1pvb4cyQIdXzOtmCb1y6o_6JBnJOx9DkdrMHeYHb5LU0/edit#heading=h.6iuk77tyg1a

Sidebar - what a change between 2018-2023. Ron now at Samsung. David at Amazon. Isaac recently retired from Intel. And Gundrala sadly passed

https://ocp-all.groups.io/g/main/topic/in_memory_of_gundrala/87592963?p=,,,20,0,0,0::recentpostdate/sticky,,,20,1,80,87592963,previd%3D1611775656365391031,nextid%3D1638983329612768441&previd=1611775656365391031&nextid=1638983329612768441. Gundrala and I collaborated quite a bit when he was at Intel, including

and many others
Gundrala is missed. It was nice having an opportunity to roll down 156th with him and grab Indian Food across from Crossroads here in Bellevue during his MS (post-Intel) years.

Ok. Back to the topics of open source platform code. So this 'open platform code/mintree' is another 'recent-to-past' binding. In general the 2015 to 2021 hang time of 6 years is not unreasonable. I once recall a software VP in early 2000's telling me that 'nothing significant happens in less than 10 years.' In the world of internet time and AI I suspect the timelines are a bit accelerated, but I have definitely observed that looking for quick wins in the infrastructure space rarely occurs. 


PPS

https://twitter.com/kirkbrannock/status/1665121431519367169

 



saddened me.  Kirk this year and Sham last year



have left the building to retirement, or as I sometimes joke "had a sharp enough spoon to dig out of Shawshank." https://en.wikipedia.org/wiki/The_Shawshank_Redemption

Good times working on BIOS with both, Sham being a huge mentor to me starting in 1997. He was sort of the "BIOS Yoda" when I joined Intel. Sham's the guy who did the first SMM BIOS enabling on the 386SL, etc. And I met Kirk in 1998 starting on workstation BIOS, EFI, and then many things platform thereafter, including great design oppty's with both like https://patents.google.com/patent/US7392371B2/en


which ended up landing in https://uefi.org/specs/PI/1.8/V3_Design_Discussion.html#firmware-file-system-format

Or with guru Sham on SMM on https://patents.google.com/patent/US6775728B2/en

that lives on today with things like https://uefi.org/specs/PI/1.8/V4_MM_Protocols.html#mm-mp-protocol.



And Sham also dropped one of my favorite farewell messages, viz.,

            As many of you have already heard - after 32+ years at Intel, I have decided to retire and start the next phase of my life’s exciting journey. I had prepared a very long farewell message for all of you, filled with my sage wisdom and list of accomplishments etc. etc. but then, I looked at the address field and it struck me that I still really like most of you on the list – so here is a short version.

 

            For past three decades, I watched technologies change. An amazing Technological Symphony was being played at Intel and I was fortunate enough to be hired into the orchestra as a bell ringer. I hope my cow bell went “ting” at the right time to make the symphony even more brilliant and melodious to the world, and that it helped to harmonize and amplify the brilliant voices around me. Now, a time has come for me to pass on the bell to steadier and younger hands that would ring the bell even more vigorously and timely than I could. As for me, I would gracefully join the audience and keep nodding as you play along taking this complex orchestra to dizzying heights. 




Thursday, May 18, 2023

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 Hanrahan mentioned that when he won his Turing Award https://amturing.acm.org/award_winners/hanrahan_4652251.cfm, his congratulatory message from UW Ed Lazowska (the attendee sitting immediately in front of Pat H) 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 H'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?

Some folks call predicting things 'seeing around corners.' The challenge is when you see around the corner people push back that the effort isn't 'relevant,' but if you wait until the enterprise rounds the corner you are invariably 'late' because driving change in low-level infrastructure 'takes time.'