Friday, February 24, 2023

26 or Anniversary.Next^11 and Wisdom of the "Age"s

True to form, as today is my work anniversary, let's follow-up on the tradition of posting a blog. Recall last year's entry When I am posed with the challenge of posting on a given day, sometimes my mind alights upon various data points observed during the earlier hours. The first thing I noticed today was which pointed to the longer blog posting

This is penned by Subrata and describes some of the techniques to minimize the size of the Intel FSP. I appreciate the review of this work at, too. 

This workflow aligns with the 'path to openness' arc mentioned in postings like And as always it's great having the opportunity collaborate with Subrata, such as the late '22 Apress books.

Speaking of Apress co-authors, today on the Twitter-stream I also saw

which describes an upcoming talk (now 'past' with Jiewen Yao, my Apress '20 co-author and long-time collaborator. 

Since these two data points are about sharing knowledge, and today's post entails a milestone on my career, I was reminded of some wisdom I received from an engineering luminary early in my career. Specifically, the posting mentioned Robert Pease

Speaking of the wikipedia bio, I can say that Rob used 'RAP' in his personal, correspondence.

" Although his name was listed as "Robert A. Pease" in formal documents, he preferred to be called "Bob Pease" or to use his initials "RAP" in his magazine columns."

When he was he was 54 when he shared some thoughts with a 24 year old engineer.

I picked up my undergraduate degree in electrical engineering and my first job was doing embedded systems for real-time data acquisition. I was a big fan of Electronic Design magazine and an avid reader of Pease. When my job expanded from the real-time control firmware into working on the analogy-side of the sensor subsystem, I reached out to RAP with some questions.

I dug up the correspondence, with the following envelope

And my letter to Rob. I had not yet realized that writing simply is the best way to convey your thoughts. I cringe at some of the constructions below, but it definitely has my literary 'fingerprint.'
In response to this mail, I was amazed that I received a 3-page response from Pease

(1 of 3)

(2 of 3)

(3 of 3)

To me Pease was my first encounter of the silicon valley culture wherein engineers revel in helping each other and sharing knowledge. Fast forward to a few years ago and Intel. The spirit of helpfulness and wisdom were something I also observed in folks like Jim Keller I was reminded of Keller when reading/watching the interview This was pure Jim. And his wisdom about 'the big ball of mud' and the need for modularity and re-writes echoes some of the Intel-time wisdom he relayed. At the time KKeller was probably 60, and I was much closer in age to him.

I recall a specific encounter in a conference room at the Robert Noyce building with a nearby view similar to the images from Jim would come into the discussions aggressive and strident, but if you had your data and could defend your position, he'd enjoin the discussion deeply.

To me Pease and Keller were similar souls, having traveled through myriad engineering projects and collected learnings that each would happily share.

Although I lack both the wisdom and charisma of the two, I try in my own small way and encourage others to be similar mentors and purveyors of their learnings in the engineering community.

Speaking of my undergrad and Cornell, I couldn't help but think of Scott Galloway and his quotation " Hermes-ification of their institutions after seeing the following statistic, viz.

Coming from Texas I didn't know much about the Ivy League, but arriving in NY I learned that Cornell was the more accessible of the Ivy's, as composed to Harvard and Yale.  


Beyond some of the headline-grabbing quotes of Galloway, though, I would recommend reading his book I've heard said is that the mark of a good book is one you'd read twice. I have to admit the Algebra of Happiness is one that I've at least iterated twice.


Speaking of authors whose work I enjoy and the spirit of engineering information sharing from the valley, has a fascinating write-up on 8086 interrupt support. Ken's work is more generally described in his various talks, such as and reminded me of my first file & issued patent (now expired), which used some trickery of the segments and the interrupt table to save space in the BIOS.  Good times.


I just saw the following image 

 I had similar struggles with Java in 1997 in building the web crawler I had to build at UW for Weld's AI course mentioned in Although Larry and I had similar Java challenges in the late 90's, it appears that our respective careers took different arcs.

Sunday, February 12, 2023

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 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  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 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)

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


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

This feature is also described in Learning about how CI worked and the top-of-mind reminders from folks like Heasman

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 mentioned in earlier post, 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 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 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, 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

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.

ECR48 was remastered in M279

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

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, 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

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 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 created in the wake of my first ToorCamp talk, to and on how to use the code Given the long arc of this work, 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, 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, too, although it was always smooth sailing as I recall people glowering at me when I presented 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 to better revocation models And DRTM is getting great traction in the platform now, although contemporary with Windows 8 we worked hard to see if we could have a standards-based solution, too. DRTM definitely reduces the trusted computing base (TCB),

thus why the DRTM and optional DRTV were mentioned in, 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, 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 discussion on January 31 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. 


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 


I guess this closes the circle for this blog. I opened with Nate Warfield prezo and he's part of which is led by Yuriy and John, my co-presenters from the 2013 Cisco seccon talk.