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. 

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.'

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.

Continued march of time

This week I hosted another retirement lunch for an Intel colleague Harry (middle on left-hand-size of the picture below) from the Ridgepointe office, namely the cubicle next to the 2017 denizen described in the http://vzimmer.blogspot.com/2017/10/the-march-of-time.html posting. I caught a picture of a few of the attendees at the nearby buffet, 

luckily for all omitting myself from the photo. A couple of years ago there was talk of manic recruiting, folks reveling in their 'fun-employment' between jobs, quiet quitting, etc.  Now the word 'layoff' permeates the air, with added 'quiet firing,' and folks taking the opportunity to retire. For retirement and the retiree Harry, he was on my interview team back in October 1996 and I still recall his vivid description of underwater hockey and his forays therein. Since then our paths have crossed often through BIOS, Itanium, EFI, UEFI, EDKII..... 

I still remember my first job in the early 90's. I was off-site working with a contractor when at the main campus the layoff message was delivered. When I returned to the office the next day folks had ravaged my cubicle, taking my office supplies, chair, etc. assuming I was part of the RIF. Ah, the cycle of tech.

At the lunch, the fortune cookie I selected seemed appropriate, too, for the eastside tech scene.

Grinding at tech is definitely the mood of the last few decades. Disruptions often make one more thoughtful, though. I am reminded of the quote from Elon Musk that the biggest mistake engineers make is working on the wrong problem, or the image of "Lancelot in Retirement" from Lex Fridman #345. 

Speaking of Leahy and the recent progress in RISC-V I was again reminded of the 2016 coreboot conference https://www.youtube.com/playlist?list=PLiWdJ1SEk1_AfMNC6nD_BvUVCIsHq6f0u I mentioned in http://vzimmer.blogspot.com/2016/11/conferences-forums-and-writings.html. Lots of the folks who presented have switched companies, landing at places such as Rivos, Meta, Apple, and Google. But I still giggle when I recall Ron M. mentioning that he had Andrew Waterman https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html speak to the Google executives just to see the latter's expressions when Andrew would drop the F-bomb. Classic tech.

Speaking of Google in PNW and the future of tech, https://www.cs.washington.edu/events/colloquia/details?id=3264 provided some inspiration on the set of open problems to solve

and also offered an oppty to drop in on the new UW CSE building

In the firmware domain there are still interesting problems to solve, including how to better share source code across execution phases. Host firmware is strange, such as PI-based code w/ sec, pei pre mem, pei post mem, dxe pre BdsEntry, dxe post bds (the uefi phase), uefi runtime, smm. And then there are the other platform components like embedded controller (ec), bmc, soc uc's, not to mention other host firmware like slim bootloader, coreboot, u-boot, ....

And to evolve something you need to ship. It was far-sighted on part of Google to use Fuchsia on a class of Nest devices. I recall a lunch w/ MS engineer years about about the Singularity/Midori  OS fail. He claimed the focus was wrong, namely not having a memory safe driver model but instead the lack of focus on the application model. Maybe if it shipped (or provided user-land usages or deployed on MS 1st party devices?

And around Seattle I enjoyed reading Welsh's article https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming/fulltext. This work reminded me of item I studied during my late 90's UW masters on Simonyi's intentional programming https://en.wikipedia.org/wiki/Intentional_programming.

I have tried to move some of my public-facing posting from https://twitter.com/vincentzimmer to https://mas.to/@vincentzimmer but I continue to find myself replying on the blue bird. From re-tweeting https://twitter.com/acmeducation/status/1636806692519256064 

to answering questions on UEFI firmware, such as making a distinction between interfaces and implementation https://twitter.com/vincentzimmer/status/1633880381610164224

along with not being an apologist for either, with critique of the former https://twitter.com/vincentzimmer/status/1633890390041587712

And finally I reinforced Matthew Garret on his defense of some of the UEFI security features https://twitter.com/mjg59/status/1637661444270587906

with a shout-out to the corresponding embedded computing article https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure.

I also dropped into the Dasharo user group and had a chance to talk with Andrew Cooper. He brought up his concern about running UEFI runtime with hardware control-flow enforcement from December 2021 https://osfw.slack.com/archives/CV510QZ0D/p1639105740058800

I let him know that we had implemented this in the UEFI 2.10 specification as part of the UEFI Memory Attributes Table https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table. 

The problem statement is described in https://bugzilla.tianocore.org/show_bug.cgi?id=3726

This is another example of using the community to help drive a security feature. The other notable example includes the exchange with Kees Cook on Twitter https://twitter.com/kees_cook/status/1290095780984786952 that led to https://bugzilla.tianocore.org/show_bug.cgi?id=3519 which is now required in https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memory-mitigation-requirements-for-signing/ba-p/3608714, namely the EFI_MEMORY_ATTRIBUTE_PROTOCOL.

Speaking of the UEFI spec, it has been interesting working across different standards bodies, including IETF https://www.rfc-editor.org/rfc/rfc5970.txt to the various UEFI https://uefi.org/specs/UEFI/2.10/ and UEFI Platform Initialization https://uefi.org/specs/PI/1.8/index.html specifications. Each has a different way to share IPR, from IETF's public https://datatracker.ietf.org/ipr/ to the UEFI forum's internal sharing. I still recall working w/ the Intel team to draft 

                                

for the PI SMM items. This cites the same SMM patent mentioned in https://www.intel.com/content/dam/develop/public/us/en/documents/a-tour-beyond-bios-launching-standalone-smm-drivers-in-pei-using-the-efi-developer-kit-ii.pdf, viz.,

This work was prior to the standards efforts. And the above document also demonstrated the type of behavior taken post-standards, namely a more public, code-first approach to new work. That document describes what has become the 'stand-alone MM' https://uefi.org/specs/PI/1.8/V4_Overview.html#initializing-mm-standalone-mode-in-sec-phase work in PI 1.8, for example.

Finally, I was hoping to reproduce the stacking image from http://vzimmer.blogspot.com/2021/01/books-and-computers.html for the last couple of Apress books, but I didn't have the energy to hunt all of the books down that have been published since 2006. Instead I opted for the 'COVID Triad', namely the 3 books that appeared between October 2020 and October 2022, viz.

https://link.springer.com/book/10.1007/978-1-4842-7939-7 https://link.springer.com/book/10.1007/978-1-4842-7974-8 https://link.springer.com/book/10.1007/978-1-4842-6106-4

That's about 2000pp that appeared on the market in the span of 2 years. Yikes.

A final curious note that also relates to this blog series is 

Someone had posted a link to my BlueHat stream of consciousness blog http://vzimmer.blogspot.com/2023/02/blue-hat-2023-and-uefi-secure-boot.html. I'm glad no one picked up on this since the HN https://news.ycombinator.com/ discussions can get pretty rough.

OK. Enough for Sunday blogging and back to Sunday work.

PS
I was saddened to hear the news of Gordon Moore's passing https://www.moore.org/article-detail?newsUrlName=in-memoriam-gordon-moore-1929-2023. Beyond Moore's Law https://hasler.ece.gatech.edu/Published_papers/Technology_overview/gordon_moore_1965_article.pdf, he provided guidance and wisdom to the industry throughout the years https://www.youtube.com/watch?v=gtcLzokagAw. My favorite image of him has to be the portrait composed of keycaps 

along with the painting

from Intel HQ alongside Robert Noyce.