Deprecation and introduction of interfaces

Specifications may appear to be static codifications set in stone, but they are often evolutionary species. One of the challenges in evolving a specification includes when, if ever, to deprecate content in lieu of new additions. Sometimes technology may fall out of use or be deemed by the market not to be the most viable. Often, though, this class of information is not elided from specifications unless they are hard scientific reasons, like elision of MD5 or SHA1 from specifications 

because of pre-image attacks https://en.wikipedia.org/wiki/Preimage_attack. I recall one person telling me that about 40% of the Wifi specification was relevant; the key was knowing 'which' 40% merited attention.

This blog will talk about a few specifications, such as the UEFI, PI and Intel SDM, that weigh in at several thousands of pages. To be with the UEFI and PI specification, one area that has potential for deprecation is Itanium support. The EDKII upstream has already removed Itanium related code from the various packages. There are vestiges of Itanium in chapter 2 of the UEFI Specification https://uefi.org/specs/UEFI/2.10/02_Overview.html#intelitanium-based-platforms for the calling conventions, though. Similarly, support for the Itanium reset paths https://uefi.org/specs/PI/1.8/V4_MCA_INIT_PMI_Protocol.html# and extended SAL https://uefi.org/specs/PI/1.8/V4_Sal.html services can be found in the PI specification. The latter of which was the EDKII adaptation of calling the Itanium System Abstraction Layer (SAL) (SAL) https://redirect.cs.umbc.edu/portal/help/architecture/24535901.pdf interfaces from a UEFI environment. 

As a quick background, Itanium had a platform scoped SAL and processor scoped Processor Abstraction Layer (PAL) set of firmware layers designed to provide both boot and runtime services. The RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv-non-isa/riscv-sbi-doc is sort of an amalgam of SAL and PAL since it provides both core, SOC and (potential) platform capabilities. SAL is interesting in that unlike UEFI, that goes into a virtual-only calling mode after SetVirtualAddressMap(), the SAL calls could be called in either physical or virtual mode throughout the life of the platform. This posed some challenges for writing UEFI code since position independent code (PIC) options for C compilers haven't been universally supported across all of the EDK toolchains, especially in the early days with Visual Studio, or for IA32 with its inability to read the instruction pointer address as possible in other architectures. For assembly-language Itanium code it was pretty simple to write PIC code. So the Extended SAL (ESAL) of the PI spec and EDKII provided a way to have non-fixed up and fixed up C code that would use a common data area. 

In addition to the SAL support, another fascinating aspect of Itanium was the support for floating point exceptions in the Floating-Point Software Assist (FPSWA) https://redirect.cs.umbc.edu/portal/help/architecture/24541501.pdf driver, as described in https://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143 

This driver was loaded from the EFI System Partition during boot and would provide runtime support for floating point exceptions. Regrettably soft-loading critical flows from disk like the FPSWA have not been pervasive, even in the face of relatively expensive $/byte of semiconductor NOR SPI flash. This stems from the supply chain challenge where the motherboard and fixed disk media may be provisioned, secured, and recovered by alternate parts of the ecosystem, namely OEM/ODM for the board versus OEM/ODM/integrator/VAR/IT for the disk and its bootloader and OS images, respectively.  

Another area that is an interesting artifact from the past is the BIOS interface in the Intel Software Developer Manual https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf. This interface is an Int15h API to manage microcode patches.

Starting in the early 1980s, the PC/AT BIOS exposed services through 16-bit 'int' calls or software traps, which the most famous being Int13h for disk access, Int 10h for video, etc. These API's all have correlatives in UEFI, with Int13h having the equivalent in EFI_BLOCK_IO_PROTOCOL, for example. The Intel Framework Compatibility Support Model (CSM) specification https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-compatibility-support-module-specification-v098.pdf provided a bridge from EFI into BIOS calls in the early days where there were few EFI native drivers, for example. But the CSM support was not introduced into the UEFI PI specification since the idea with PI commencing in 2006 would have UEFI-spec-defined APIs. In fact, Intel declared the PC/AT BIOS interfaces to be end-of-life in 2020 https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020 

and http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf.

That's where the Int15h API mentioned above is interesting. It can either go away as its the only BIOS API in the SDM, or it could be complemented by/replaced with a UEFI equivalent. To that end, the https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf design reads on this capability 

The mapping of the UEFI interfaces to the Int15h included

with the specific capsule itself having the following layout

The generic capsule overview flow is described in the UEFI specification https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#update-capsule 

and other write-ups https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://archive.fosdem.org/2020/schedule/event/firmware_culisfu/attachments/slides/3709/export/events/attachments/firmware_culisfu/slides/3709/FOSDEM_2020_Intel_Capsule_Update.pdf. As the code-base has been re-arranged in the open, the most recent location to find the FMP DXE Microcode Capsule support is https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/IntelSiliconPkg/Feature/Capsule and of course https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. 

This builds upon the generic FMP 

and capsule update flow 

widely deployed today. Maybe avoiding putting something 'post-Int15h' in the SDM is a wise move, though, considering the plurality of interfaces for firmware updates, from https://slimbootloader.github.io/security/firmware-update.html to https://uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf to https://uefi.org/sites/default/files/resources/PRM_Platform_Runtime_Mechanism_1_1_release_candidate.pdf to https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf to.... It's a veritable embarrassment of riches.

Co-authors then and now

 So I mentioned in my last blog that I could always talk about https://www.cisa.gov/news-events/news/call-action-bolster-uefi-cybersecurity-now.  Well, it turns out the UEFI Forum posted a pretty good read this week on the topic of UEFI and ecosystems, namely the top posting at https://uefi.org/learning_center/papers, in the document https://uefi.org/sites/default/files/resources/Decoding%20UEFI%20Firmware-Aug24-2023-Final_v2_0.pdf. 

The authors are folks I have enjoyed working with across various teams and decades. Some of the collaborations have spanned companies and different venues, such as papers, books, and presentations. 

To begin, I think Dong Wei https://www.crunchbase.com/person/dong-wei and I first appeared in print together with the original Beyond BIOS book in 2006, 

with Dong providing the forward

Next up was the 2008 UEFI Shell book

with preface

This 2008 book was followed with a 2009 whitepaper https://uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf

I was a bit excited about IPV6 at the time as I was in the throes of getting https://datatracker.ietf.org/doc/html/rfc5970 through an unfamiliar standards body, namely the IETF.

Next was the presentation circuit with 2010 presentation in Shanghai

and San Francisco

Shanghai https://en.sjtu.edu.cn/ was nice to visit since so many of my long-time collaborators in our Intel Shanghai office, like Jiewen Yao, are alumni of this institution.

Then the 2nd edition of the Beyond BIOS book in 2010 came next

with Dong reprising his preface-writing skills with

Finally a couple of proposals for UEFI and RISC-V for the 2015 

and 2016 conference

were created with Dong. 

All of the collaborations before 2023 with Dong were when he was at HP (and then HPe after the split). 

And now in 2023 with Dong as ARM Ltd's chief standards architect and an ARM Fellow.  The total collaboration instances makes nine per my accounting.

Speaking of 'chief's', Insyde Software's Chief Technology Officer  (CTO) https://www.insyde.com/company/executive-management was another rich engagement.

The collaborations with Tim commenced in 2008 with the UEFI Shell book first edition

and an IDF presentation that same year presented at both the Taipei and Shanghai events

The Intel Developer Forum (IDF) was an annual event in California show-casing various Intel and industry advancements. Today I believe it has been superseded by venues such as Intel Ignite. 

I co-authored an Intel Technology Journal https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf article with Tim in 2011

Tim and I also jointly presented in 2011 at the Intel Developer Forum in San Francisco

All of the preceding presentations were done when Tim was with Phoenix Technology. Tim had joined Insyde when the joint book-authorship was reprised with the 2nd edition of the UEFI Shell book in 2017 https://www.degruyter.com/document/doi/10.1515/9781501505751/html

Tim was also gracious to serve as the technical reviewer for Firmware Security https://link.springer.com/book/10.1007/978-1-4842-6106-4 book in 2020 

These collaborations with Tim look like they sum to seven.

Tim and Dong have made seminal contributions to the ACPI, UEFI, and PI specifications. In fact as late as 2010 Tim was the chair of the UEFI Security Subteam (started with the UEFI Forum in 2010). From the 2nd edition of Beyond BIOS

 

 

before I took over that subteam. In fact I drafted this recent overview of the UEFI Forum Subteam's

From there you can see the various working groups.  I believe Dong and Mark Doran co-chair ASWG, Mark PIWG, Mark USWG, etc. Among the co-authors of this blog's showcase paper. Dick Wilkins is the Phoenix Board of Directors (BOD) rep, Bill Keown for Lenovo, and Dong for ARM, respectively. Co-author Brian Mullen chairs the new Software Bill of Material (SBOM) subteam, Dick chairs the UEFI Security Response Team, and I chair the UEFI Security Subteam. I elided subteams like graphics, configuration, and networking from the infographic as they are mostly dormant these last few years. I created the above image derived from earlier https://uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf as a companion to another mutation (from image in https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure) I crafted to give folks an idea about how SBOM's impact EDKII-style system firmware, viz.,

Well, that's it for today.  This is my small gesture to leave a bit of history since a lot of this system firmware work I've done will be unlikely to land in more esteemed repos like http://www.bitsavers.org/bits/ and is surely aging off the internet. I even recall that a request was required to get the Intel Technology Journal back on intel.com. Regrettably the same audible wasn't called for other publications like "Technology at Intel" magazine or most back-dated Intel Developer Forum prezos. An example of what gets lost on the internet can be found in citation curation sites like https://dblp.uni-trier.de/pid/34/5641.html; here I only see Tim mentioned once, for example.

UW PMP, Patents, T-shape, Job ladders

I haven't blogged in a while. Given things in the news like generative AI you'd think I'd dive into thoughts there, especially interesting aspects like the use of probability, with my usual meanderings to related topics like Terrence Fine, Cornell, and formalists versus frequentists, etc. Or posts like https://www.cisa.gov/news-events/news/call-action-bolster-uefi-cybersecurity-now where I could possibly opine for another 900pp+ (like https://link.springer.com/book/10.1007/978-1-4842-6106-4).

Instead I was reminded of late 90's when reading https://www.quantamagazine.org/complexity-theorys-50-year-journey-to-the-limits-of-knowledge-20230817/#, specifically my time of the University of Washington (UW) in the UW PMP (Professional Masters Program) https://www.cs.washington.edu/academics/pmp. The PMP started in 1997 and I was accepted prior to the 2nd quarter having commenced, or the '2nd wave of inductees'). This was fortuitous for many reasons.  One, Intel was the largest recruiter from UW at the time, including donating a lot of equipment, and two, the other regional software companies hadn't flooded the application pool with talent form Microsoft, UW, Boeing, etc. If I had waited a few more quarters, the probability of acceptance as an 5-year-in-industy-EE-undergrad may have been tough going.  

Also, I had my first daughter during that last quarter. New tech job + around-the-clock-diaper-change + after-work-hours-studying-and-projects nearly killed me.

My 6-month-old little Husky didn't look so happy in her purple onesie on that hot day back in 1999.

Fast forward to 2023

My 6-month-old turned out to eschew the UW path, but her younger sister ended up choosing UW and is in her 3rd year

and my 2023 Husky next to her older sister

and a couple of my favorite things my UW daughter gave me include a box years ago

and then this coin when she entered UW

that I keep in the box.

As part of that program, the computer science department hosted a welcome event at the Pacific Science Center in downtown Seattle next to the Space Needle. There were many UW professors in attendance, included a newly minted graduate from Caltech named Chis Diorio who had worked with Carver Mead on hardware neural nets. Part of his research entailed work on multi-level cell storage, and Intel had a significant history and products around NOR storage at the time, so Chris asked if I could connect him with any other Intel folks. Diorio has done pretty well in the intervening years https://www.impinj.com/library/blog/impinj-named-a-finalist-in-two-categories-2023-geekwire-awards with Impinj, too.  My learning from this interaction is as follows: always assess if the value others see in the conversation with you are because of the 'person' or the 'platform'. In this case I suspect it was the 'platform', namely my employer.

Speaking of Carver Mead, it's interesting to see the wisdom of pioneers potentially resurface. Namely, reading https://www.techradar.com/pro/nvidia-beware-ibm-has-a-new-analog-ai-chip-that-could-give-the-h100-a-run-for-its-money made me think of https://www.amazon.com/gp/product/0201059924/. This is definitely a contrast to the digital state-of-the-art sort of read I found in https://www.amazon.com/Efficient-Processing-Deep-Neural-Networks/dp/168173835X, for example.

So after a couple paragraphs, how does this relate to the Quantum magazine article? Well, another professor was Richard Karp, viz., " In addition, the American complexity theorist Richard Karp proved that the universality property identified by Cook (and Levin, though Karp and Cook didn’t know of Levin’s work until years later) was itself all but universal".  More details on Karp can be found in https://en.wikipedia.org/wiki/Richard_M._Karp, including "Apart from a 4-year period as a professor at the University of Washington, he has remained at Berkeley. From 1988 to 1995 and 1999 to the present he has also been a research scientist at the International Computer Science Institute in Berkeley, where he currently leads the Algorithms Group."  And what was my interaction with this esteemed Turing Award winner?  After Karp introduced himself I replied, "ah, I guess you get to work on things like compilers and stuff." My learning from this interaction 20 years later is as follows:  always do your homework on the group with which you are interacting ahead of time.

The late 1990's had other great interactions. Having come up to Seattle from Houston, Texas, I couldn't but help to name my proposed Test Executive, or test framework for firmware, 'TEX", when working with Eric Hudnell. Or the spirited discussions with Andrew Fish in 1997 about ASIM (Advanced Server Information Modules), or a way to decompose our server firmware prior to the next of many, many 'modularization' initiatives, such as Intel Boot Initiative (IBI) and Davinci/Kittyhawk BIOS in 1998, EFI in 1999 Framework in 2000, ...... My retrospective learning: infrastructure evolution takes time. There are few 'short wins.'

A lot of those interactions above also entailed wisdom from others. I still recall a director who told me about the plan/clue matrix for engineers. Namely, you aspire to working with someone who has a 'Plan + Clue.'  They are effective and directed.  The 'Clue but no plan' are often visionaries/strategists in that they know where to go but not how. The 'Plan but no clue' are the scariest since they are akin to a bull in a china shop- they have a lot of kinetic energy to expel but perform the drunkard's random walk in plotting a path. Finally, the easiest to handle are the 'No plan and no clue' since they are largely inert/ignorable. Cook reminded me of this early 2000 wisdom in his posting https://www.johndcook.com/blog/2010/12/27/dumb-and-gets-things-done/. 

Speaking of wisdom, I was asked to give some patent training last week. One of the pieces of wisdom I always offer to folks on patents is to have a sense of urgency, especially with the normalization of invention primacy with 'first to file' and the American Inventors Act a few years back. I often put this urgency in the context of the industry, namely invoking Joy's Law "no matter who you are, most of the smartest people work for someone else,” https://en.wikipedia.org/wiki/Joy%27s_law_(management). What that means for inventors is that given similar problem statements and the frontiers of knowledge, others may come up with similar ideas. But what you have within a large company is perhaps earlier access to the problem and/or the frontier of knowledge since Fortune 100's like Intel often 'create' said knowledge. 

I also try to temper the patent presentation to put patenting in context. First the positive where I mention the ability to get patents as a software person in a hardware company (data also mentioned a year ago in http://vzimmer.blogspot.com/2022/09/new-milestones.html), viz.,

but then I remind the audience that patents are part of delivering value, not a means in-and-of-themselves (including quoting this blog from 10 years back http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html), viz.,

From the patent milestones you see the title "Fellow." This is one of the highest designations of a technical-track employee, as distinct from management-track, employee at Intel. Many tech companies have similar designations, and I culled a comparison of the Seattle area shops below https://www.levels.fyi/?compare=Amazon,Intel,Google,Microsoft&track=Software%20Engineer

NB
Someone might question why I continually show an image from a website that others can find themselves. I guess I have two answers. One, I learned that content on the web ages out or evolves, such as top inventor Wikipedia started to subset its listing. And two, for better or worse a colleague introduced me to the MS Windows 'snippet' tool and the barrier to image creation was significantly lowered for me :)

Speaking of old blogs in 2013, I should probably reprise http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html since I discovered the T-shaped model https://collegeinfogeek.com/become-t-shaped-person/ and have used it a lot since in mentoring people. Then the other part of me notes that I also usually advise people that 3-7 years is optimal occupancy time in a grade level, say 9, prior to becoming a 10. Too short a time and you don't have time to generate sufficient evidence to prove you delivered at that last level, and too long you become stale and people ask 'why now?' As I roll into year 10 as a Senior Principal Engineer or grade 11, I am in the 'why now' camp where people can dismiss earlier accomplishments in the decade as not fresh or of insufficient merit since if they were, I would have been acknowledged then. As such, I challenge myself as to whether I am the right person to be dispensing 'career growth wisdom' if my career isn't growing. 

There are many great engineers in the Sr. PE community, including the two I mentioned in the last blog who retired, Sham and Kirk. And as the company matures, this cohort continues to grow in cardinality. But it does make me wonder if it's a terminal level, or sort of a tech elephant's graveyard

 

I couldn't help but use that metaphor since found the image arresting from reading Tarzan? or some such as a youth.

More likely it's the other career advice I give folks, namely that getting promoted is a lot like real-estate opportunities, namely 'timing and location.' Since promotions are a meld of business impact, technical acumen, and leadership, not all role or organizations afford opportunities for the same, or that triple may not be as business relevant as the market moves or the exigencies of the employer change.

I like to stand outside of the phenomena and observe it sometimes. Thanks Marcus Aurelius and Seneca, too, for the classical doses of introspection and stoicism, respectively.

Maybe part of it is the reality expressed by Corey Quinn

Corey Quinn (@QuinnyPig) / X

Twitter

https://twitter.com › QuinnyPig

From what I can see, getting promoted at a big tech company is roughly four times
harder than getting that job at another company.

(I apologize for the rough copy-paste of a Google-search-of-a-Tweet).  The gist of the sentiment above is that the new company wants to believe in you and leans in, whereas your present employer knows all of the defects of an internal candidate and perhaps subconsciously over-indexes on them. Another area where I have seen Quinn's assertion in practice is that if things are not going well in a company, outsiders from successful companies are seen as more attractive since the internal candidates are the ones who 'contributed to the company and its ills' (i.e., why promote the arsonists?); of course this confuses correlation with causation on both internal and external candidates to a first order since rarely is a single individual responsible for the ills or gains of any large company. Finally, one reason that Quinn's logic holds is that as the business evolves, it is necessary to important new skills for the new business domains, as distinct for taking the time or risk of 'up-skilling' the present bench; I still recall in my early days why hiring was prolific that the 2nd line manager told us 'we need the exact skills. There is no slack in the schedule to train someone up over three months.' 

Or maybe it's related to the business cycle? Just as Ben Horowitz opined about 'wartime versus peacetime' CEO's https://www.linkedin.com/pulse/wartime-vs-peacetime-ceo-insights-from-hard-thing-things-pandey/, maybe there's a similar dynamic that applies down the stack, including technologists? The market dynamic might argue for loading the bench with more 'wartime'-minded folks? Or does the company need more 'referees' versus 'risk takers?'

So the magic bullet is job flipping employers then?  Maybe, or maybe not. I've always found the promotion-through-job-change risky in that the grass isn't always greener. You'll see from zoom in of above 

that my present job code overlaps with Microsoft 'Partner,' for example,  I recall one Partner Architect at Microsoft, now retired, telling me that at MS the title 'Partner' is also code for "throw the other Partner under the bus" job description. Namely, it's an understandably competitive peer group when total compensations can easily exceed $1million/year. Similar for my slight overlap with Amazon Sr. PE. I recall asking an Amazon executive what happened when someone was hired at too high a grade level. His glib reply was 'Oh, that?  We take care of those situations quickly.' Woof. 

So what's my parting advice on this blog postings sidetrack on careers? Enjoy the trip. Add business value. Learn. Appreciate contributing to and receiving wisdom from others. And promotions are a Faustian deal, too. As Goethe expressed in this epic, be careful what you wish for. namely the pursuit of power can entail a deal with the devil, etc. The $1million/year compensation isn't because the employer admires your bio and portrait as a 'new partner.' Instead, it represents an expectation of output against both business goals and your new peers commensurate with this compensation. And these days it's delivering value on 'internet time.' 

I've never worked in the high-flying world of silicon valley or startups either, but I suspect that there's no 'rest and vest' on a California tech building roof like https://silicon-valley.fandom.com/wiki/Big_Head in almost all cases. But if you enjoy the trip, moving up the tech job ladder can be awesome. You will be at a technical level aligned with Vice-President+'s of the management track and the role should provide more of an opportunity to make a dent in the universe as a technologist as you advocate for and drive insanely cool technical progress.

  

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.