October firmware events

Apropos of the 25 year anniversary of the first IBI/EFI/UEFI boot services at week ago, as commemorated at the 20 year milestone in https://vzimmer.blogspot.com/2018/10/  

                                                        "Ken Reneris     Oct-14-1998"  

there was a question of the coding standards for UEFI https://twitter.com/bexcran/status/1701071379171619236 recently which made me think of Ken. I mentioned how that since Ken had come over to Intel from the Windows NT team at Microsoft it was natural to adopt the NT coding standard https://computernewb.com/~lily/files/Documents/NTDesignWorkbook/coding.pdf for the original IBI/EFI/UEFI work. This includes the EFI_ERROR macros, inf's, CR macro, TPLs as simplified IRQLs https://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html, etc. This made IBI/EFI/UEFI a sort of a cultural 'Windows BIOS' given that lineage. 

And Ken as the MS HAL owner continually interfaced with the platform. In fact, standards like ACPI pre-dated IBI/EFI/UEFI by starting in the mid-90's. Ken was deep into that work, too, as evidenced by his solo inventor ship of the now-expired S4 resume patent https://patents.google.com/patent/US6209088B1/en. 

These UEFI technology elements serve a counterpoint with coreboot, which was LinuxBIOS in 99. The latter have technology elements https://www2.cs.arizona.edu/~mccann/cstyle.html, KConfig, etc.  

https://link.springer.com/book/10.1007/978-1-4842-0070-4. So just as we have had parallel growth of Windows and Linux, there have been threads of 'Windows BIOS' (e.g., EDKII UEFI based) and 'LinuxBIOS' (e.g., coreboot and maybe less so u-boot?).

But then again, who uses 'BIOS' https://basicinputoutput.com/2014/08/will-i-be-jailed-for-saying-uefi-bios.html? 

So the blog title is firmware events. Over the last couple of weeks there was a UEFI plugfest in the Portland area and a Open Compute Project (OCP) event in San Jose. As I drove back from the former, I stopped by a bookstore and saw https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784

on the shelf.

On that same shelf I saw 

and

Though not the immediate book neighbor, the nearby https://www.amazon.com/ARM-Architecture-Reference-Manual-2nd/dp/0201737191 reminded me of Dave Jaggar. Back in the mid-1990's we were development hardware RAID controllers at Compaq and using custom ASICs alongside an AMD 29k RISC CPU. I recall Jaggar from ARM coming to visit and explaining the ARM architecture. Part of the discourse included showing a silicon die with a small portion highlighted for the ARM core itself. It was quite a shock for me to so such small mm-squared for a CPU. My firmware lead (lead == sole design & developer) work on the SMART-2SL 

https://www.amazon.com/Compaq-242777-001-WIDE-SCSI-CONTROLLER-242777001/dp/B0002FDXLQ is but a memory to be rekindled occasionally by seeing aftermarket examples of this device. In addition to being the first device to not have a non-volatile post write cache, this work gave me the opportunity to do some interesting firmware performance innovations with a colleague https://patents.google.com/patent/US6341342B1/en. 

Speaking of CPQ, it has been a strange migration of companies for me. My original internship was with Texaco, which in turn was purchased by Chevron. Then I did my first full-time firmware development at Daniel Industries, later acquired by Emerson Electric. My first foray into PC BIOS was at Texas Microsystems (TMI) working on industrial computers, which then was acquired by Radisys. Finally, my pre-Intel employer Compaq server group was in turn acquired by Hewlett-Packard, and then split into the enterprise side HPe. Luckily Intel is still Intel.

So speaking of the development event, it spanned 3 days. I presented on the first day (lower left image)

https://uefi.org/sites/default/files/resources/Tuesday_02_Kubacki%20and%20Zimmer_Final.pdf and final

day (rightmost image) https://uefi.org/sites/default/files/resources/Firmware%20Configuration%20%E2%80%93%20Past%2C%20Present%2C%20and%20Future_Zimmer.pdf. The first day of the event included a description of SPDM https://www.dmtf.org/standards/spdm and its support introduced into the UEFI 2.10 specification. SPDM is homed at the DMTF but has associated work-product having in groups like UEFI and the Trusted Computing Group (TCG). 

In the Insyde talk Tim Lewis mentioned the growth of attacks on the UEFI network stack after many years of battering SMM. This reminded me of a recent posting I saw https://www.linaro.org/blog/ledge-blogs-uefi-http-and-https-boot-in-u-boot/ where the U-Boot community discussing using https://savannah.nongnu.org/projects/lwip/ which is a similar approach taken in https://github.com/tianocore/edk2-staging/tree/MpNetworkStack mentioned in https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf. From the days of discussing HTTP booting in 2009 https://dblp.org/rec/conf/csreaSAM/Zimmer09.html?view=bibtex and having the URL boot option mentioned in https://www.rfc-editor.org/rfc/rfc5970.txt has come a long way. Just as EDKII consumes cryptography as a submodule from another community, maybe it's time to do so for the basic networking capabilities.

Given that AWS started in 2006, it may have a bit short-sighted of me to have said "...emergent compute models such as cloud computing." in that SAM 09 paper.

Maybe I was keying off the 09 date of what I thought was the definitive paper on the cloud, viz., https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.

So back to the topic of this blog, namely firmware events. On that topic, the next week came the Open Compute Project (OCP) event in San Jose. I first presented at OCP in 2015 with Mallik Bulusu https://cdrdv2.intel.com/v1/dl/getContent/671185 

and then again in 2016 on firmware updates http://files.opencompute.org/oc/public.php?service=files&t=1f7831234dce58bb875b1b5b24f7154d. 

This session last week was on the universal payload

I have been engaged on server platforms since I was hired into Intel in February 1997 to lead the IA-64 (Merced, Itanium) firmware. Along the way we devised ways to facilitate ease of firmware development, like multi-socket cache-as-RAM https://patents.google.com/patent/US7254676B2/en 

and similar for IA-32 https://patents.google.com/patent/US8078862B2/en. Palsamy and I also collaborated on UEFI and ACPI for RAS and error support https://cdrdv2.intel.com/v1/dl/getContent/671067. 

And all of these threads come together in these recent talks. The SPDM prezo mentioned at the top of the posting here entail facing the post-quantum cryptographic migrations like all of the other standards, including UEFI https://uefi.org/, TCG https://trustedcomputinggroup.org/, and others. The proposal for augmenting UEFI is mentioned in https://bugzilla.tianocore.org/show_bug.cgi?id=4087 and some prezos on the topic can be found at https://uefi.org/sites/default/files/resources/Post%20Quantum%20Webinar.pdf and https://uefi.org/sites/default/files/resources/USF_Security_Webinar_Final.pdf. The specific study on SPDM was posted as a pre-print to https://eprint.iacr.org/2022/1049 and then a journal submission in https://www.mdpi.com/2410-387X/6/4/48. 

Since SPDM has fixed message sizes, the concept of 'chunking' or breaking up the larger payloads demanded by these post-quantum algorithms is a common concern other hardware-based messaging interfaces will face, like the Trusted Computing Group's Trusted Platform Module (TPM). Interestingly this topic of post-quantum impacts on firmware standards that motivated the SPDM paper

 listed above was inspired by the study https://eprint.iacr.org/2021/041 from Cisco.

And during Q/A with the CISA presentation during the UEFI developer event I asked about formal methods for this domain. Since this talk followed the SPDM talk one recommendation was to use formal for the SPDM wire protocol. It turns out the above MDPI SPDM paper is referenced by a few formal studies of SPDM, including https://www.usenix.org/conference/usenixsecurity23/presentation/cremers-spdm and https://ieeexplore.ieee.org/abstract/document/10149352/. 

And speaking of security and standards, this upcoming week is the TCG members meeting at the Google campus in Kirkland, WA. I am Intel's representative on the Technical Committee, assuming that role after Kirk Brannock retired. 

 

But the TCG is not unfamiliar to me. I have been engaged with TCG https://en.wikipedia.org/wiki/Trusted_Computing_Group even when it was called TCPA, as evidenced by work-product like https://patents.google.com/patent/US7200758B2/en and delivering the Itanium and EFI API and platform specification, respectively.

When reading https://research.tue.nl/en/publications/communication-in-a-world-of-pervasive-surveillance-sources-and-me from the mention of Jacob in https://www-theregister-com.cdn.ampproject.org/c/s/www.theregister.com/AMP/2023/09/19/marvell_disputes_claim_that_cavium/, I hearkened back to my first ToorCamp presentation 

Based upon the slide

and discussion around the TPM, Jacob told me that we should design a TPM so that it could quickly be removed from board and chewed up/swallowed if someone tries to take your computer. Quite the privacy-preserving dietary strategy.

It's interesting to see people in person after the years of COVID seclusion and event cancellation or wholly-virtual events. Just like the psychic shock and fatigue of crowds, continual interaction and noise, it is taking a bit of effort to get re-acclimated. Part of the symptomology is falling behind on blogging, I guess, since I had intended to post this entry on the day of the EFI 25-year anniversary, not a week later. Oh well. Only so many free moments on the weekends these days.

And the world keeps changing

 I'm a long-time fan on Twitter. I still recall merging onto I-5 years ago and listening to some tech podcast about this new 'micro-blogging service', namely Twitter. I still keep up with https://twitter.com/vincentzimmer and don't worry so much about the vagaries of ownership or management. But I was intrigued by the discussion of other services like https://mastodon.social/explore. As such I setup an account and posting some material akin to what I saw from another Twitter person regarding some personal metrics for 2022 https://mas.to/@vincentzimmer/109549960566794774, including a reply to myself with another random observation this week https://mas.to/@vincentzimmer/109550056099262201.

This is my first post to mastodon: 

"Interesting 2022. First journal pub https://www.mdpi.com/2410-387X/6/4/48 although waiting for red box on https://dblp.uni-trier.de/pid/34/5641.html. I also had oppty to collaborate on an IEEE conference http://www.ieee-smart-world.org/2022/uic/index.php mentioned in http://www.ieee-smart-world.org/2022/uic/uic-2022.htm. Then a couple of unrefereed items https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://eprint.iacr.org/2022/1049. Then 2 books https://link.springer.com/book/10.1007/978-1-4842-7939-7 and https://link.springer.com/book/10.1007/978-1-4842-7974-8. A podcast https://www.youtube.com/watch?v=wqcUWAEHcVg. 6 US patent filings and 7 issued.  Whew."

and

"Speaking of https://eprint.iacr.org/2022/1724, it was referenced by https://eprint.iacr.org/2022/1724. 

Latter doesn't read in on PQC aspects of SPDM but provides a formal verification of extant SPDM protocol using a theorem prover https://github.com/tamarin-prover/tamarin-prover with public proofs https://github.com/AnalysisSPDM/FormalModel. Perhaps this is a use-case to leverage for achieving a long-held ambition, namely axiomatize and 'prove' some tricky parts of UEFI, viz https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html?highlight=authenticated#setvariable and EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS?"

I try to be pragmatic about formal. I recall reading once that even in the days of the Orange books with A-level certification requiring 'formal proof' it was hard to achieve, but the attempt at least 'provided better documentation.' And at a professional level I've always mutated the 'culture trumps strategy' aphorism to be 'implementation trumps architecture.' A painful reminder of this dichotomy is having studied https://www.cl.cam.ac.uk/~lp15/papers/Auth/tls.pdf back in the day and then meeting Marsh Ray and learning of his work https://troopers.de/events/troopers10/242_history_of_the_tls_authentication_gap_bug/. Networking has been close to my heart for a couple decades as I helped grow our EFI network stack from its nascent PXE equivalent in 1999 through IPV6 https://www.rfc-editor.org/rfc/rfc5970.html and into HTTP and TLS (e.g., HTTP-S boot). I still recall reading the Rescorla book on SSL/TLS while waiting for my older daughter to be born in 1999 at the University of Washington hospital.

Perhaps if I have the opportunity in the future to use my sabbatical

I can do some thinning of the archives. Rescorla and Rudin have aged well, but I suspect I can sunset the Java duo of Aglets and JavaOS. On the other hand, though, I'm a fan of keeping around some documents of 'old tech' since there is often wisdom to be gleaned from the past.  Hmm. Decisions, decision.

Well, to close on formal, specifications, and networking, I should tie off that thought at least with a re-invocation of as always, there is no 'silver bullet.' 

These mastodon posts feel like my usual terse blog posts. Perhaps my posts are 2xM or 3xM (i.e., 2 or 3 times the text length of a Mastodon post).

This blog is usually pretty low traffic, too. The sources of eyes are either google searches or link via https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A (which included the blog links) or blogroll like https://blogs.coreboot.org/. 

With the removal of the former, I suspect there will be less traffic. That should be fine. I don't do sponsored ads or other revenue-generating activities here. It's more of a personal set of footprints in the sand to chronicle the journey.  

And luckily https://en.wikipedia.org/wiki/List_of_prolific_inventors has been curated to just the top 100, so watching my slow descent down the leader board, such as http://vzimmer.blogspot.com/2022/09/new-milestones.html and its earlier ilk, are no long a nagging distraction.

Ah well, so much for a mastodon experiment and clone+amplification to my OG blog. Back to work. Need to figure out how to add an abstraction service to code I wrote 20 years ago before 9am tomorrow....

Cheers

PQC

I haven't blogged in 3 months, so I thought I would create a short post this evening.

One thing that I've noticed in my behavior lately is that I often say "I understand" versus "I agree." Latter implies I have a vote on the topic. I also find myself demonstrating the behavior that "as you age in industry you become more 'historian' than 'expert'". But the plurality of ambitious folks who believe they are 'expert' often fight when you lean too much into history mode. Their behavior reminds me of the quote 'the person may be wrong but is never in doubt.' 

As I get older I am tacking the opposite direction of confidence in all matter.  I find I doubt things more as I apprehend the huge swaths of knowledge I haven't penetrated on this life journey. I don't like Bukowski's "The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence." quote in this area, though. It implies the issue involved is one of intelligence. I rather prefer to chalk it up to intellectual humility. 

Hopefully I demonstrate some of that behavior in my interactions. If I were up to the challenge of watching myself on video, I'd audit my revisit to Chips & Salsa https://www.youtube.com/watch?v=wqcUWAEHcVg. I recall blogging about that venue a while back http://vzimmer.blogspot.com/2021/11/books-old-age.html, too.

Regarding a topic area that reminds me of the of breadth of knowledge and progress, I'd like to recall the post quantum cryptography (PQC) talk https://uefi.org/sites/default/files/resources/Post%20Quantum%20Webinar.pdf. Readiness for PQC includes recent UEFI specification code-first readiness https://bugzilla.tianocore.org/show_bug.cgi?id=3413 and https://bugzilla.tianocore.org/show_bug.cgi?id=3725. A 2022 augmentation of a feature first conceived 15 years ago https://www.semanticscholar.org/paper/Platform-Trust-Beyond-BIOS-Using-the-Unified-Zimmer/0bd3bdeb6dcadf088137e13c00adc7e4390fa0de

I was enthralled with the various RT's.  Roots of Trust for Storage & Reporting (RTS/RTR) in the TPM, Root of trust for measurement (RTM) and Root of trust for enforcement/verification (RTE/V) for the platform firmware. This predated the RTU and RTD from https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf years later.

Beyond UEFI there are other industry standards that require PQC accommodations. These include protocols like SPDM https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.0.1.pdf. The cryptography eprint https://eprint.iacr.org/2022/1049 posted today describes some of this work. This is definitely an 'application' of cryptography versus cryptographic research. The latter is especially challenging, as demonstrated by recent findings like https://thequantuminsider.com/2022/08/05/nist-approved-post-quantum-safe-algorithm-cracked-in-an-hour-on-a-pc/. I am a fan of this type of analysis. I did feel a little bit like we were guilty of Pike's 2000 diatribe "Mostly, though, it's just a lot of measurement" http://doc.cat-v.org/bell_labs/utah2000/utah2000.html. 

This news story reminded me of former co-worker Ernie Brickell's knapsack paper https://link.springer.com/content/pdf/10.1007/3-540-39568-7_27.pdf. Ironically Merkle https://en.wikipedia.org/wiki/Ralph_Merkle is related to a present co-worker and I was able to grab an autograph for my book on Merkle's original knapsack work

Ernie was a rare combination of PhD and leader. I still recall Ernie trying to recruit me to join his team a decade ago. Ernie did fascinating work on zero-knowledge proofs, including co-inventing Direct Anonymous Attestation (DAA) https://eprint.iacr.org/2010/067.pdf that was eventually included in the TPM 2.0 specification. Definitely a different eprint than item mentioned at top of this blog https://eprint.iacr.org/2022/1049.pdf. Ernie also introduced me to David Chaum https://en.wikipedia.org/wiki/David_Chaum of zero-knowledge proof fame, too, at an Intel event. 

One cautionary tale I learned from Ernie was avoiding going all in on a given position. The combination of drive, technical depth, and passion for a topic can create a lot of p=mv momentum https://www.calculatorsoup.com/calculators/physics/momentum.php when slamming into the walls that one often finds in bigCo.  

Speaking of years ago, I am happy to see progress https://github.com/UniversalScalableFirmware/fspsdk/tree/qemu_fsp_at_reset toward the vision of 

from page 143 of https://link.springer.com/book/10.1007/978-1-4842-0070-4. This is yet another reminder that the march of technology takes a long time. 

musings about firmware cultures

In a quick journey around firmware cultures in this posting, I'll talk a bit about the recent Open Source Firmware Conference (OSFC) 2020.

The Open Source Firmware Conference (OSFC) started in 2018. It was a broadening of the coreboot conference to include other open source firmware projects. Some examples of the earlier coreboot conference include the 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016 where Intel talked about the ‘then recent’ UEFI Payload project https://youtu.be/I08NHJLu6Us and Intel FSP 2.0 https://youtu.be/uzfiTiP9dEM. I was invited to give the keynote of the inaugural OSFC conference in 2018 https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf  There common themes such as chipsec, Slim Bootloader, Min Platform, coreboot, and Intel FSP were noted.

 

Now have FSP SDK   https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 mentioned in that keynote, too.

Fast forward to OSFC 2020 https://cfp.osfc.io/osfc2020/schedule/ and you see many of the same sentiments being reiterated. Intel talked about extending Intel FSP for programmable service engine support https://cfp.osfc.io/osfc2020/talk/TNTFYV/, a more modern configuration mechanism https://cfp.osfc.io/osfc2020/talk/AS7EZR/, and the efforts https://cfp.osfc.io/osfc2020/talk/VUNDSC/ to have a more reusable payload  https://github.com/universalpayload. From those talks we then go to the efforts to remove dependencies upon SMM, including the Platform Resource Monitor (PRM) https://cfp.osfc.io/osfc2020/talk/MCJASB/. 

Beyond those talks, Jiewen Yao co-presented on the Security Protocol and Data Model (SPDM) https://cfp.osfc.io/osfc2020/talk/ECQ88N/ along with Xiaoyu Ruan. SPDM is a new standard from the DMTF for device and host firmware security that is critical for upcoming security initiative support. openspdm is a sample implementation of SPDM specification. It will be used in multiple device and host firmware implementations including UEFI EDK II and possibly other platform firmware, such as a Baseboard Management Controller (BMC) based upon OpenBmc, etc.

Beyond SPDM, Jiewen also shared the background and efforts with Virtual Firmware for Intel Trust Domain Extensions (TDX) https://cfp.osfc.io/osfc2020/talk/CRKZB8/. This effort entails open source efforts to help scale enabling for TDX and provides a venue to discuss aligning enabling with other confidential computing efforts like AMD Secure Encrypted Virtualization (SEV). The TdShim is also used as a foundation for any service Trust Domain (TD) for TDX advanced feature in an EFI-light environment, such as the virtual firmware for a container or virtual TPM services. It bridges the gap between TD startup and applications running, and it enables the customers building their own use cases on top Intel TDX.

Andy Jassy during re:invent this year also spoke about how change in large companies is often driven by outsiders since long-time employees are often reluctant to replace what they've built in the past. And in the spirit of change, Rust was a topic of a few https://osfc.io/ talks this year, including the virtual hallway track discussion.

Specifically Jiewen Yao and I presented on Enabling Rust in UEFI firmware https://cfp.osfc.io/osfc2020/talk/SLFJTN/. This is a complementary talk to those by Google on enabling Rust in oreboot https://cfp.osfc.io/osfc2020/talk/SLFJTN/ and Rome https://cfp.osfc.io/osfc2020/talk/TBSHA8/, respectively. Although these are early days, there is definitely a groundswell of interest to evolve how critical infrastructure code such as firmware is written, especially given the needs for more robust code and efficiency of the developer workflow. And as an example of that sentiment, since OSFC is a virtual conference, the closest thing to the ‘hallway track’ was commentary in the sharing tool, including the following exchange on Rust

  

Open Source Firmware Conference 2020

Bret Barkelew6 hours ago

I agree with Ron that now I've worked with Rust it's like pulling teeth when I have to go back. ;)

.

J. Redpath5 hours ago

a sign of something good

.

Vincent Zimmer5 hours ago

yes. moving from C to Rust feels like the same dynamic of moving from assembly-based firmware to C 20 years ago.

.

Diego Rodríguez5 hours ago

^this

In addition to that hallway track discussion above, there were other hallway discussions in the Facebook session about UEFI versus coreboot complexity.This reminded me of the culture of UEFI and coreboot, or as I sometimes think, a "windows-bios" versus a "linuxbios." By that I mean the EDK code is written in the style of Windows kernel code and coreboot is written in the style of Linux kernel code.

To begin, coreboot literally started as "LinuxBIOS", as mentioned in chapter 4 of https://www.amazon.com/gp/product/B01JC1LDTY/. EDKII history is described in the "Beyond BIOS" article https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.  

The reality of the latter is that Ken Reneris, mentioned in http://vzimmer.blogspot.com/2018/10/ghosts-of.html, created the original IBI/EFI core. He was a OS/2 and Windows kernel/Hal veteran who joined Intel in '98 around the time of the initial IBI effort. Ken brought along the same Camel Case coding style as Windows kernel code, the Containing Record (CR) https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/8_private_context_data_structures/81_containing_record_macro macro from ntddk.h into efi.h, TPL's from Windows IRQL's, .inf's, and the build command-driven build of the original EFI sample which became the EFI Developer Kit's I and II. CR's are pretty interesting in that it allows for a 'public' interface in a structure to have some appended, implementation-specific instance 'private' information. This allows for C++ keyword functionality for public/private to be emulated in C code.

Speaking of the legacy of ex-MS Ken, the prevalent use of GUID's in EFI, along with the 'protocols', or GUID-named API's, bear not a small resemblance to COM https://en.wikipedia.org/wiki/Component_Object_Model. Think iUnknown versus HandleProtocol, etc. but forging COM's C++ infrastructure in C.

Ron, on the other hand, notes that the original LinuxBIOS was derived from Linux, thus it has stutter-case/Indian Hill https://www2.cs.arizona.edu/~mccann/cstyle.html coding standard, basic make support, and Kconfig as LinuxBIOS became coreboot. coreboot also started out as fully-open, whereas EDKII slowly released more sources of the last 20 years.

Beyond coding standards, the EDK-based implementations of UEFI always vied to cover the entire boot flow, from the tuple of {reset, silicon init, platform init, OS bootload phase} as {SEC, PEI, early DXE, late DXE}. DXE is both platform initialization and the UEFI core. coreboot, on the other hand, supports the same tuple as {bootblock, romstage, ramstage, payload}. The payload for coreboot could always have been a full kernel, as CSM-like compatibility module like Seabios, or today even a EDKII-Dxe implementation in the core of the UefiPayloadPkg. 

The richness of the OS bootload phase in coreboot is separated from the basic silicon and board initialization. With the DXE phase doing both platform initialization and OS bootload, the complexity of the latter ends up encroached on the former. The OS bootload code is highly reused and rich, per the UEFI specification, whereas board initialization is a high traffic area where board specific changes often occur and is the venue to host a lot of the bring-up and debug experiences.

Popping up from my trip down memory lane, OSFC also had debates between MS and others on the chat channel about the distinction between the general purpose platform where the OS producer may be different from the platform producer, versus a more vertical platform with the firmware and OS provisioned under the same authority.

Or the distinction between a full feature platform that supports a plurality of shrinkwrap OS's versus doing the minimum and letting the OS do the rest.

Another big distinction between the two is that EDK grew up initially closed and any of the open elements were released under a permissive BSD license. whereas coreboot grew up open with the GPL license. I was curious about the value of the GPL in firmware and received the following comment from Marc Jones many years ago  via the question 'why hoard SATA bug fixes?' EDK BSD allows for snapping the open source instance and not redistributing changes, such as bug fixes, whereas the GPL of coreboot, Linux, and u-boot obligate the party changing the GPL code to redistribute their fixes.

Luckily, there are more than a few common points of alignment between EDKII and coreboot today.  These include EDKII-based UEFI Payload Package for shrinkwrap OS support, both communities are pursuing unit tests w/ cmocka, ACPI is the predominate runtime interface, etc.

From those present-day alignments there are also some similar trends, such as the oreboot from C-based coreboot and the RUST-on-edkII investigation versus full EDKII C code

Speaking of EDKII implementations, in addition to the PDF of some of the OSFC talks, the videos of talks for OSFC 2020 can be found at https://vimeo.com/showcase/osfc-2020.

Beyond the OSFC talks, one can find the recently-published "Understanding the Trusted Boot Chain Implementation" at the following links  https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.pdf, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.mobi, and https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.epub. These binaries are compiled from https://github.com/tianocore-docs/edk2-TrustedBootChain. This material is above-and-beyond the recent book https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation-dp-1484261054/dp/1484261054/ and was created in order to provide guidance to communities, such as the Trusted Computing Group and TianoCore, on consuming and producing the measurements in a more interoperable fashion.

I also just noticed another security related EDKII publication, namely an insightful analysis of PE/COFF image loading https://arxiv.org/pdf/2012.05471.pdf.  This is close to home for UEFI and EDKII. The work reminds me of the more generic studies like https://eprint.iacr.org/2019/564.pdf.As you may have guessed from my earlier blogs and writings, I'm a fan of more formality and rigor in the pursuit of future-looking designs and validation, respectively.