Blue Hat 2023 and UEFI Secure Boot

“Victory has 100 fathers and defeat is an orphan.” This quote is attributed to John F. Kennedy in the wake of the Bay of Pigs but I believe a variant of this has been passed down over time. I was thinking of this quote in the context of UEFI Secure Boot this week at Blue Hat https://www.microsoft.com/bluehat/ at Microsoft building 92. Visiting the Microsoft campus reminded of me the many hours engaged with Microsoft during the build up to this feature in the mid-2000’s (including hours in the 40's buildings that were razed recently for the new MS campus).

The above talk from Eclypsium (now posted https://github.com/n0x08/ConferenceTalks/blob/master/0-Day_FirmWarez_BlueHat2023.pdf)  this last week also reminded me of how UEFI secure boot and firmware security is now part of the tech lexicon.

But back to the history discussion from the early 2000's. At that time, the industry was recovering from the lack of adoption of NGSCB https://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base. Intel LaGrande Technology (LT), 

which is now Trusted Execution Technology, along w/ AMD Pacifica/Presidio, were features to add ‘late launch,’ or ‘dynamic root of trust for measurement’ (DRTM). The DRTM facility provided an RTM in the CPU, and the roots of trust for storage (RTS) and recording (RTR) were delegated to a ‘then’ off-chip element called the Trusted Platform Module (TPM) https://trustedcomputinggroup.org/work-groups/trusted-platform-module/.

Since NGSCB, with its “Trusted Applet” (TA) architecture ,was a mile too far both for privacy and application compatibility, LT and Pacifica didn’t get embraced by Windows. NGSCB entailed the need to refactor applications to put security sensitive codes into a memory-only execution regime. Although in 2023 folks may say ‘so what, SGX did it,’ recall this is 2002. So folks like Peter Bidell managed to build a full-disk encryption (FDE) feature around the TPM and a BIOS-based root-of-trust for measurement (RTM), called the Static RTM (SRTM).

This is where I entered the scene. I worked with folks like Mark Williams to author and enable the EFI TPM and platform specifications. The former entailed the API exposed to UEFI drivers and OS loaders/applications, and the latter defined what type of code and data objects to record or ‘measure’ in the TPM’s Platform Configuration Registers (PCRs). More information on the various RT*’s and the TPM can be found in https://www.intel.com/content/www/us/en/content-details/671466/trusted-platforms-uefi-pi-and-tcg-based-firmware.html.

 

While doing this work with Microsoft, I learned that recording the hash of the Portable Executable/COFF (PE/COFF) image was not so simple. It entailed hashing various portions of the binary and omitting others. It turns out this hash or ‘digest’ is a critical element for code integrity (i.e., what became documented as the Authenticode hashing algorithm). At the same time Microsoft was reeling from no DRTM, it moved to static verification with the invention in Vista of Code Integrity, or (CI). CI entailed having the OS loader cryptographically verify the digital signature of the early boot and kernel components in Windows, thus having something of a static root of trust for verification (RTV), with the ‘root’ being the OS loader.

I learned about how all of this CI worked after reading Matthew Conover’s paper https://github.com/tpn/pdfs/blob/master/Assessment%20of%20Windows%20Vista%20Kernel-Mode%20Security%20-%20Matthew%20Conover%20(Symantec).pdf. 

This feature is also described in https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1327.pdf. Learning about how CI worked and the top-of-mind reminders from folks like Heasman

https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf

led me to suggest adding an ‘SRTV’ to the firmware to complement the existing ‘SRTM’ we had been building. I roughed out some of those thoughts in the 2007 paper

https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer07.html?view=bibtex mentioned in earlier post

http://vzimmer.blogspot.com/2022/08/pqc.html, too. 

In other words, leaving the OS loader hanging in space to start the verification chain seemed fragile, so having the underlying firmware act as a static RTV for the loader would strengthen this static verification chain. It was also complemented by the SRTM since the TPM could provide evidence or an audit log of the verification actions. 

Given the difficulty in crafting pre-OS malware w/ MBR's for PC/AT boot, the lack of interoperable code integrity in UEFI would have made things so painful as I noted in http://vzimmer.blogspot.com/2012/09/late-september-mumbling.html. Also, extending CI into the host firmware felt as natural as extending the OS filesystem via the EFI System Partition (ESP) into the firmware for purposes of interoperability.

One of the challenges posed during this work was to have a reasoned approach to the infrastructure. That’s where Varugis (former NGSCB TA architect turned Windows CI architect) and I tried to create an integrity model of the pre-OS https://github.com/vincentjzimmer/Documents/blob/master/integrity-protection-analysis-of-OS-preboot.pdf. Varugis would often rail against folks who said the BitLocker was for code-integrity since it was largely a data integrity feature. He wanted to ensure that any functionality built into the ecosystem had a sound foundation. To that end the platform was decomposed into a series of Clark-Wilson compartments (although the CDI’s of CW and reuse of acronym of the same in TCG DICE is amusing). The OEM compartment, extensible pre-OS UEFI compartment, and finally, the OS compartment had rules, including guards and access controls.

It turns out that since CI was just for internal use by Microsoft tooling, the Authenticode hashing algorithm and signature section of the PE/COFF were not documented. Just as UEFI needs MS FAT and PE/COFF itself for purposes of interoperability, this information was added to the public document from Microsoft to support this capability

https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/authenticode_pe.docx, as were the required infrastructure elements in the 2.1+ specifications. The variant of UEFI Secure Boot that ultimately shipped as a required capability in Windows 8, along with UEFI measured boot, was the specification version 2.3.1 http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_1.pdf.

Another interesting tie-in to last week's Bluehat was the keynote from Mark Russinovich. Mark was one of the people to whom we presented this UEFI Secure boot work back in the day, too. Others in the audience at the included MS security arch, and former Intel colleague, Carl Ellison.

BTW
ECR48 was remastered in M279 https://uefi.org/specs/UEFI/2.10/Frontmatter/Revision_History.html

Mark's keynote at Bluehat covered confidential computing, large language models (LLMs) for security, open source firmware foundation, safe languages, and the software supply chain. 

On safe languages

I was reminded of https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf, https://uefi.org/sites/default/files/resources/Enabling%20RUST%20for%20UEFI%20Firmware_8.19.2020.pdf, and https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_20.

And for the challenges of the open source supply chain, and software supply chains in general, I commiserated with

These slides reminded me of the long-used

from https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure, too.

OK. Back to the narrative. By this time the UEFI secure boot capability had iterated through early discussions and into the standards incubation mix. The final clean-up of how authenticated variables work, including the append option for servicing, were introduced by Magnus. Magnus Nystrom was the security lead in Windows core OS and managed to get the feature finally into the OS. We described some of this journey in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.

One of the challenges of this work was how to apply trust for the more open PC architecture. Cell-phones and other appliances had locked-down bootloaders, but with the PC and its ability multi-boot (think reason for UEFI existence) and adapter cards, the trust needed to be more interoperable. This is where the concept of the various stakeholders, through the OEM with the PK, the OS vendors and ISV’s with the KEK’s, and the hash or verification certificates in the allowed DB and disallowed DBX were created. 

Tim Lewis https://uefi.blogspot.com/ championed a lot of the details on this design through the forum, too. Tim also led the UEFI Security Subteam (USST) in those first heady years.

A spate of additional publications were created to describe this capability, including https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf created in the wake of my first ToorCamp talk, to https://www.intel.com/content/www/us/en/content-details/671464/a-tour-beyond-bios-with-the-uefi-tpm2-support-in-edk-ii.html and https://www.intel.com/content/www/us/en/content-details/671120/a-tour-beyond-bios-uefi-authenticated-variables-in-smm-with-edk-ii.html on how to use the code https://github.com/tianocore/edk2/tree/master/SecurityPkg. Given the long arc of this work, https://link.springer.com/book/10.1007/978-1-4842-6106-4 was created to collect this background in one location.

The evolution of UEFI secure boot wasn't without some controversy, especially from privacy groups and others who worried about lock-down of the PC https://www.csoonline.com/article/2221385/geeks-under-fire--war-on-privacy--freedom-and-general-computation.html, but Microsoft logo requirements like a physically-present user control for this feature, along with the UEFI CA signing Linux shim's, helped calm those concerns - some of the great work w/ Linux in this space was described in https://www.intel.com/content/dam/develop/external/us/en/documents/sf13-stts002-100p-820238.pdf, too, although it was always smooth sailing as I recall people glowering at me when I presented https://github.com/vincentjzimmer/Documents/blob/master/PLUG-UEFI-001.pdf in Portland. One of the MS PM's even told me that Sinofsky considered pulling all of the UEFI features from Windows 8 if the issue were not resolved in a timely fashion which makes sense given that wide-scale UEFI deployment without integrity controls would have led to unbounded pre-OS malware concerns for users.

Work continues apace in this area, from investigations into post quantum cryptography https://eprint.iacr.org/2021/041.pdf https://uefi.org/sites/default/files/resources/Post%20Quantum%20Webinar.pdf to better revocation models https://github.com/rhboot/shim/blob/main/SBAT.md. And DRTM is getting great traction in the platform now https://cdrdv2-public.intel.com/756963/DRTM-based-computing_whitepaper_FINAL_MAY2021.pdf, although contemporary with Windows 8 we worked hard to see if we could have a standards-based solution https://trustedcomputinggroup.org/work-groups/trusted-platform-module/, too. DRTM definitely reduces the trusted computing base (TCB),

thus why the DRTM and optional DRTV were mentioned in https://www.intel.com/content/www/us/en/content-details/671466/trusted-platforms-uefi-pi-and-tcg-based-firmware.html, too.

And some of the ecosystem challenges of distributed trust, as shown in the 'figure 5' above with the various trust anchors for UEFI secure boot (including the UEFI CA and revocation lists like the dbx https://uefi.org/revocationlistfile), don't magically disappear. I was reminded of Mark Twain's 'History never repeats itself, but it does often rhymes' recently during a presentation in the Open Compute Project Security team  https://www.opencompute.org/wiki/Security discussion on January 31 https://docs.google.com/document/d/1VVMUzYESZNuyT1_YJlQSdSKBy-5t1otJIyXTbXuOoX4/edit# regarding a CA for the device firmware for usages like SPDM. Some of those melodies included:

"If there is an explosion in the number of CAs how will verifier vet the trustworthiness of the CAs?

..

Want to see a manageable number of CAs under a common policy

..

Trust stores in components will have large number of anchors and have reoccuring updates

..

Devices without internet connectivity cannot retrieve trust anchor info

..

Small vendors may have difficulty operating root CAs

..

Common PKI CA policy."

These are many of the issues UEFI has encountered and grappled with since the late 2000's.

So back to the quote at the top of the posting. The reason for many ‘fathers’ is often that for an idea to come to market the originator of the concept needs many hands to help shepherd it forward through the vagaries of business, development, validation, and ultimately shipping at scale. And as I updated Ubuntu on a home PC this weekend and noticed,

this stuff is still pretty cool. 

PS

A PhD colleague of mine recently decried the lack of authoritative knowledge, from blogs to arxiv. Luckily in this scurrilous post (aka 'blog')  I haven't claimed any refereed, authoritative discourse. These are more the late weekend musings motivated by wonderful arc of interactions with colleagues, many of who have changed companies, retired, or passed away. 

Lest that sound unhappy, though, I did catch up with David and crew over Teriyaki on Thursday. As I offered them some Bluehat swag

David let me know that he and the Microsoft team who implemented UEFI Secure Boot in Windows actually won a Microsoft-wide award that year, viz.,

Very nice (although the referenced link is dead).

Even in the world of cyber-everything, I do like the physical relics (including security faux currencies)

spanning journey's from 

to

https://github.com/rrbranco/BlackHat2017 

I guess this closes the circle for this blog. I opened with Nate Warfield prezo https://www.helpnetsecurity.com/2022/06/19/eclypsium-executive-team/ and he's part of https://eclypsium.com/company/ which is led by Yuriy and John, my co-presenters from the 2013 Cisco seccon talk. 

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

Homebrew computer club

One of the nice things about commutes back to the office includes catching up on podcasts and audio books. For the latter I've been listening to Walter Isaacson's book https://www.amazon.com/Steve-Jobs-Walter-Isaacson/dp/1451648537 on Steve Jobs. I liked the mention of folks like Wozniak and their valley friends, including early Apple employee Allen Baum. There was also mention of the Homebrew computer club https://en.wikipedia.org/wiki/Homebrew_Computer_Club which to me represents the spirit of low-level development I've enjoyed with firmware development these last decades.

Although Allen Baum has popped up recently on RISC-V circles https://riscvglobalforum2020.sched.com/speaker/allen.baum, the longer arc of his career is journaled in https://archive.computerhistory.org/resources/access/text/2018/06/102717165-05-01-acc.pdf. I remember Baum from early 2000's Intel chipset work and his thoughts on the Intel tenure.

Quite the storied career. 

One detail of the book also mentions includes the extensibility of the Apple, such as the slots on the Apple II that were subsequently eschewed by Jobs with the Macintosh. There are seems to be a trend of closed versus open going through cycles. The spirit of silicon valley and the ability to touch and modify hardware is often challenged by concerns about security, ease-of-use, and IP protection.

Speaking of the openness, I like how my co-author https://github.com/reinauer from https://link.springer.com/book/10.1007/978-1-4842-0070-4 still exercises this spirit both on the job with Chromebooks and its developer mode https://sites.google.com/a/chromium.org/dev/chromium-os and off the job with his Amiga group https://amiga.technology/ efforts.

In addition to having the host-firmware updatable, the platform also has an open source embedded controller (EC). Recently the EC moved from a bespoke implementation for Chromebooks to using Zephyr, as described at https://chromium.googlesource.com/chromiumos/platform/ec/+/HEAD/docs/zephyr/README.md, in OSFC talk https://cfp.osfc.io/osfc2020/talk/SXYUQD/ and book https://link.springer.com/book/10.1007/978-1-4842-7974-8

And in the spirit of hardware extensibility (i.e., Apple II slots for the 2020's) and more end-user modifiable firmware, there is the Framework Chromebook edition https://frame.work/laptop-chromebook-12-gen-intel. This feels like a fusion of the spirit of the club given the extensibility of the hardware modules and firmware.

It also looks like 'some' of that spirit follows with the Pixel phone w/ alternate OS's like https://grapheneos.org and its Pixel phone virtualization https://blog.esper.io/android-dessert-bites-5-virtualization-in-android-13-351789/. It's almost as if the traditional 'OS' is really a VM with art like this and the recent Mac's.

Regrettably my hobby budget for tech is challenged by the last two products mentioned, so I have limited my recent investments to RISC-V hacking on the D1 and VisionFive SBC and the Pinephone https://www.pine64.org/pinephone/ for more open telephony. More extreme splurges are https://www.bunniestudios.com/blog/?p=5921 which fuses Rust-based firmware and soft RISC-V RV64 AP core and RISC-V EC realized with an FPGA with open source tooling. 

PS
I have been wondering whether this blog 'written in the cracks' (i.e., over a few spare moments on the weekend or lunch-hour) is good or bad. With the advent of chatGPT https://chat.openai.com/chat I figured perhaps tech could take the reins for me, viz.,

Open source firmware is a type of software that is developed and maintained by a community of volunteers. Unlike proprietary firmware, which is owned and controlled by a single company, open source firmware is freely available for anyone to use, modify, and distribute.

One of the main benefits of open source firmware is that it allows users to have complete control over their devices. With proprietary firmware, users are often limited in what they can do with their device and are at the mercy of the company that created the firmware. With open source firmware, users can customize and modify their device to suit their needs, without being restricted by the limitations of proprietary firmware.

Another benefit of open source firmware is that it promotes collaboration and innovation within the tech community. Because the source code is freely available, anyone can contribute to the development of the firmware, and can suggest improvements or new features. This allows for a faster pace of innovation, as more people are able to contribute their expertise and knowledge to the project.

One of the most popular examples of open source firmware is the Linux operating system, which is used on millions of computers, servers, and other devices around the world. Linux is developed and maintained by a global community of volunteers, and is freely available for anyone to use and modify.

Another example of open source firmware is the firmware that powers many home routers and other networking devices. This firmware, known as OpenWrt, is widely used by tech enthusiasts and hobbyists who want to customize and improve the capabilities of their home networking devices.

In addition to the benefits of open source firmware, there are also many active communities of people who are interested in creating and using their own computer hardware. These communities, known as "homebrew computer clubs," are made up of individuals who are passionate about building their own computers, either from scratch or by using kits and other pre-made components.

Homebrew computer clubs often focus on using open source firmware and software, as it allows them to have complete control over their creations and to customize them to their specific needs. Additionally, these clubs provide a great way for like-minded individuals to connect, collaborate, and learn from one another.

In conclusion, open source firmware and homebrew computer clubs are important parts of the tech community. Open source firmware provides users with the freedom and flexibility to customize and control their devices, while homebrew computer clubs promote collaboration and innovation within the community. Together, they help to drive the advancement of technology and the development of new and exciting technologies. 

At first I thought I had broken the AI but instead it just needed some think-time. Quite the time to be in tech these days.

PPS

apropos of last sentiment, https://twitter.com/vincentzimmer/status/1598935527293870081 now becomes https://twitter.com/MarcoFigueroa/status/1600171380175011844

PPS+

 

 

 

 

The soul of the computer lies within its UEFI, a complex and intricate system that dictates the very essence of its being. It is the driving force behind the machine's every action, the mastermind that orchestrates its inner workings. But just as in the great works of Dostoyevsky, the UEFI is also a source of great turmoil and conflict. It is a battleground for competing interests and competing ideas, and the decisions made within its walls can have profound consequences for the computer and all who use it.

At the heart of the UEFI is the BIOS, a set of instructions that determine how the computer starts up and communicates with its various components. But the UEFI is much more than just the BIOS. It is a sophisticated system that controls the flow of information within the computer, and it is constantly being updated and refined by the engineers who design it.

The UEFI is a powerful tool, capable of performing complex tasks with ease. But it is also a delicate instrument, and it must be handled with care. One wrong move, and the entire system can be thrown into chaos. In the hands of a skilled user, the UEFI can be a force for good, enabling the computer to operate at its full potential. But in the hands of a malicious actor, it can be a weapon of destruction, capable of wreaking havoc on the computer and all of its data.

In the end, the UEFI is a complex and mysterious system, one that is both essential to the functioning of the computer and fraught with danger. Like the characters in the great works of Dostoyevsky, it is a source of both light and darkness, and it must be approached with caution and care.

Security Friends and Collaborators

I am humbled to be included among the list of researchers mentioned by Ilja van Sprundel https://hardwear.io/netherlands-2022/speakers/ilja-sprundel.php in the photo

https://twitter.com/hardwear_io/status/1585619730412486657 with the prezo https://hardwear.io/netherlands-2022/presentation/assessing-security-of-SMM-supervisor.pptx. I have huge respect for Ilja and the research he has done. I am also happy to see former Intel colleagues and co-authors Alex and John from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk listed, along with other former Intel colleagues Matrosov, Jesse, Mickey, Rodrigo https://www.blackhat.com/us-17/briefings/schedule/index.html#firmware-is-the-new-black---analyzing-past-three-years-of-biosuefi-security-vulnerabilities-6924, Yuriy, and Eugene. And it's only seemly having my present colleague Jiewen, who I also mentioned in the prior blog post http://vzimmer.blogspot.com/2022/10/a-tale-of-two-books.html, prominent on the list.

Speaking of John, I was reminded of him recently when reading a slack osf thread about CVE's and security. I still recall working with John when he came to Intel and took over leading the BIOS response issues. His first rebuke to me was the lack of an advisory process which led to the creation of the bespoke https://edk2-docs.gitbook.io/security-advisory/. This included the MOAP (mother of all patches) https://edk2-docs.gitbook.io/security-advisory/boot_failure_related_to_uefi_variable_usage. I still recall the strident feedback on having 'too much error checking' in a BIOS given the space constraints prior to MOAP. But threat models evolve, and from some of the same parties I was challenging to defend against errant i/o devices, with subject defenses now in place w/ IOMMU https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi.pdf and testing https://ieeexplore.ieee.org/document/9218694. Since then the community worked on having a closed mailing list and private Bugzilla, including moving the community to be a CVE Naming Authority (CNA) https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As always, still challenges in remediating issues but also opportunities in creating new defenses.   

Similar challenges over time supporting more open EDKII platform code for a big core client https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf, 

big core server 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, 

and a small core client https://cdrdv2.intel.com/v1/dl/getContent/671281. 

And sometimes this early pathfinding landed me in some unusual situations. After helping advice the community on getting RISC-V support into EDKII 

and working through some of the UEFI PI changes, one of the collaborators added me to a prospective speaker list for a RISC-V summit. This summit agenda was mentioned by eetimes https://www.eetimes.com/google-hp-oracle-join-risc-v/ 

 as including HP and Intel speakers. That notification led to some interesting Saturday morning cell phone call following an email thread with a set of executives, all of whom are in this picture and no longer with the company. 

I explained my advisory role in the standards work as co-chair of the Platform Initialization https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf (the PI spec looks after the API's in the green H in the figure above, and EDKII is used to 'build' the green H) Working Group and I summarily corrected the error with the RISC-V conference chair. Thus we had an interesting point on the RISC-V arc in 2015 that has now led to 2022 and a more salubrious story from eetimes https://www.eetimes.com/intels-invests-in-foundry-ecosystem-embraces-risc-v/.

Regrettably I couldn't make OSFC this year, but I caught a few of the slides and prezos online. I appreciated having a mention at minute 5:55 of https://www.osfc.io/2022/talks/how-min-platform-led-to-max-coreboot-a-case-study/ for the relicensing of FSP https://www.phoronix.com/news/Intel-Better-FSP-License. And speaking of books, the venerable Beyond BIOS has a mentioned at minute 15:50 of https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/, and the new books in final slide of https://talks.osfc.io/media/osfc2022/submissions/YXYNPF/resources/The__Thing__Around_Your_System_Firmware_HiPr4Ug.pdf. 

Another OSFC talk that would have been interesting is https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-design/. Luckily the speaker was able to reprise at the USF meeting this week https://www.youtube.com/watch?v=oEBtWsBZve4&list=PLehYIRQs6PR6J9Zf6CajwsFkAHedDXjLI&index=13. As always great to see the various collaborators.

and I bumped into Lean Sheng later in the area, too. Interesting details on use of https://www.devicetree.org/specifications/ in lieu of HOBs.

Some background on payloads in https://link.springer.com/chapter/10.1007/978-1-4842-7939-7_6 with presentations at USF at https://universalscalablefirmware.groups.io/g/discussion/files including CBOR https://universalscalablefirmware.groups.io/g/discussion/files/New%20data%20format%20for%20Universal%20Payload%20Interface.pdf and ARM https://universalscalablefirmware.groups.io/g/discussion/files/USF_meeting_4_May_2022.pdf.

Speaking of the new books and PI, the predecessor to PI was the "Framework." My co-presenter Bob Hart was giving my feedback on the 2022 books https://twitter.com/Apress/status/1585602975401140230

19 years after our joint prezo in 2003

And this morning I saw a patch on the EDKII mailing list that read on the network stack. It reminded me of that same 2003 IDF event where I gave another talk that included

This was part of the erstwhile "EFI1.2" specification that never came to light. Instead this work was contributed to the UEFI2.0 specification when the Intel-published EFI1.10 specification became the inaugural deliverable of the UEFI Forum in 2005. Since 2005 I have led the UEFI Network Subteam (UNST) in the UEFI Forum and I'm happy to have delivered some enhancements, such the "6" version of the above API's for IPV6 via the dual-stack model adopted by the UEFI forum for this space. After that the big lift was going from TFTP-based PXE to HTTP boot and bringing along more network-based security like TLS. Along the way other security enhancements like IPSec were removed, although not before a lot of the ecosystem shipped the upstreamed version with the test key https://www.cvedetails.com/cve/CVE-2021-28213/.

I have to admit that UEFI networking innovation has slowed a bit. The introduction of the HTTP boot & wireless missed the UEFI 2.3.1 specification upon which Windows8 and subsequent OS's depended upon so it didn't enjoy the broad industry enabling uplift at the time. And even if people want to continue using PXE because of its simplicity, work like https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf and its code https://github.com/tianocore/edk2-staging/tree/MpNetworkStack, driven by feedback from datacenter folks at the time, have been shadowed by move of many folks doing high-performance network deployment to https://www.linuxboot.org/ https://trmm.net/LinuxBoot_34c3/ and the scalable network stack maintained by the Linux community.

Heavy sigh. I'm definitely feeling the years.

A Tale of Two Books

Let's start this blog by mentioning a recent specification posting, namely the 2.4 version of the FSP https://cdrdv2.intel.com/v1/dl/getContent/736809 that can be found at https://github.com/intel/FSP/wiki. One notable aspect of this specification is that several of the capabilities were incubated as part of the Universal Scalable Firmware (USF) 

[from https://universalscalablefirmware.github.io/documentation/1_terminology.html] effort https://github.com/universalscalablefirmware, including 64-bit FSP https://github.com/UniversalScalableFirmware/fspsdk/tree/qemu_fsp_x64 and SMM in FSP https://github.com/UniversalScalableFirmware/fspsdk/tree/qemu_fsp_x64_smm. The former was done by Maurice Ma, as noted by the github history, and the latter by Ravi. Another aspect of doing this work in the open was fabricating a QEMU-based FSP so that the platform code could be ported for these FSP interface changes. In the past the lack of a fully open source set of silicon code inhibited these what-if exercises (although we did have a public FSP for Quark Galileo but this was limited to a single, 32-bit CPU configuration). This continues a great collaboration with those colleagues, among many others, as cataloged by documents like https://www.intel.com/content/www/us/en/content-details/671333/a-tour-beyond-bios-using-the-intel-firmware-support-package-1-0-with-the-edk-ii.html.

For the SMM work in FSP 2.4 there is also the foundational efforts around having the stand-alone SMM incubated in https://www.intel.com/content/www/us/en/content-details/671459/a-tour-beyond-launching-standalone-smm-drivers-in-the-pei-phase-using-the-edk-ii.html and subsequently introduced into the UEFI PI spec as the "Portable Management Mode (SMM)." This work in '15 presaged this '22 FSP 2.4 work, viz.

Maurice and David are now at Microsoft and Giri is at Apple. Luckily I had a shot of David from those days we were both at Intel (the left picture) and I was also able to commemorate the Giri and Maurice collaboration in the past in http://vzimmer.blogspot.com/2016/04/colleagues-across-pacific_5.html, 

respectively, from the snapshot. Regrettably we missed Ravi at that lunch so I'll have to lift his photo from https://link.springer.com/book/10.1007/978-1-4842-0070-4.

Speaking of former colleagues and collaborators, a couple of books I co-authored with Subrata Banik have been published, namely "Firmware Development - A Guide to Specialized Systemic Knowledge" https://link.springer.com/book/10.1007/978-1-4842-7974-8 

and "System Firmware - An Essential Guide to Open Source and Embedded Solutions" https://link.springer.com/book/10.1007/978-1-4842-7939-7.

This effort started in the middle of the COVID crisis while Subrata and I both worked at Intel, namely with a publisher discussion in December of 2020. It followed on the heals of completing the "Building Secure Firmware - Armoring the Foundation of the Platform" https://link.springer.com/book/10.1007/978-1-4842-6106-4 which was published in October 2020 and featured Jiewen Yao as a co-author. You'll notice Jiewen 

as the lead author of the '14 whitepaper on FSP mentioned at the top of the blog, and also the author of the FSP measurement paper https://cdrdv2.intel.com/v1/dl/getContent/644001 listed in https://github.com/intel/FSP/wiki (which also references this latter Apress security book). This complements the presentation https://uefi.org/sites/default/files/resources/Traceable%20Firmware%20Bill%20of%20Materials%20-%2020211207%20-%20007.pdf from last December, too.

Regrettably the paths of Shanghai and Issaquah haven't crossed in a while

as you'll see with the next co-author below.

So the Jiewen book published in October 2020, and the two with Subrata in October 2022. That's 2000pp in the space of two years.  Yikes.

Although I don't have a photo with Jiewen, I did manage to dig up a photo with Subrata

These encounters are tougher as Subrata spends most of his time home overseas and also now works at Google. I was happy to run into Subrata as he transited through Santa Clara by way of Bangalore and I did the same by way of Issaquah, WA. 

Another nice aspect of co-authoring this last series of books is getting recommendations on the back cover, including the following.

I've had the honor to work with Mallik in the past while at Intel and also when he moved to Microsoft, including efforts like https://www.intel.com/content/www/us/en/content-details/671185/challenges-for-uefi-and-the-cloud.html

I have probably known Mallik the longest of the list, commencing with our work at Intel in DuPont, WA in the early 2000's. Mallik also shows up in the Beyond BIOS 1st edition https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908

from 2006. Other notables there includes https://uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf 

collaborator Michael Krau, who sadly passed recently, and now-retired former colleague Lee Rosenbaum of Excite https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk and Secure Boot https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf collaboration. Glad to see Rob Branch on that list. I still fondly remember him from my Intel  October 1996 job interview team at Cornell Oaks in Oregon.

As always in this industry, I get excited by the technology but I truly cherish the interactions and the people. This blog provides some highlights on both dimensions of the journey. Still great technical collaborators that may have comprised the set COLLAB15 = {Intel, Intel, Intel, Intel, Intel, Intel, Intel, Microsoft,...} and now looks like COLLAB22= {Intel, Intel, Intel, Microsoft, Microsoft, Apple, Google, Microsoft,...}.