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.

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 http://vzimmer.blogspot.com/2022/02/25-or-anniversarynext10-and-early-22.html. 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 https://twitter.com/osfw_foundation/status/1629217731395350529 which pointed to the longer blog posting https://blog.osfw.foundation/breaking-the-boundary-a-way-to-create-your-own-fsp-binary/.

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 https://www.phoronix.com/news/Google-Intel-More-FSP-Flexible, too. 

This workflow aligns with the 'path to openness' arc mentioned in postings like http://vzimmer.blogspot.com/2020/12/musings-about-firmware-cultures.html. 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 https://twitter.com/UEFIForum/status/1628107294134108183

which describes an upcoming talk (now 'past' https://www.youtube.com/watch?v=BI9DMAOZR1I https://uefi.org/sites/default/files/resources/USF_Security_Webinar_Final.pdf) with Jiewen Yao, my Apress '20 https://link.springer.com/book/10.1007/978-1-4842-6106-4 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 https://twitter.com/siliconinsid/status/1628917395501813762 mentioned Robert Pease https://en.wikipedia.org/wiki/Bob_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 https://en.wikipedia.org/wiki/Jim_Keller_(engineer). I was reminded of Keller when reading/watching the interview https://morethanmoore.substack.com/p/interview-with-jim-keller-tenstorrent https://www.youtube.com/watch?app=desktop&v=fOUB73dZXEo. This was pure Jim. And his wisdom about 'the big ball of mud' https://blog.codinghorror.com/the-big-ball-of-mud-and-other-architectural-disasters/ https://www.cin.ufpe.br/~sugarloafplop/mud.pdf 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 http://vzimmer.blogspot.com/2020/10/silicon-valley-innovation-and-logos.html. 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.

PS
Speaking of my undergrad and Cornell, I couldn't help but think of Scott Galloway and his quotation " Hermes-ification of their institutions" https://www.businessinsider.com/scott-galloway-what-america-gets-right-and-wrong-college-education-2021-4 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.  

Yikes.

Beyond some of the headline-grabbing quotes of Galloway, though, I would recommend reading his book https://www.amazon.com/Algebra-Happiness-Pursuit-Success-Meaning/dp/0593084195. 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.

PPS

Speaking of authors whose work I enjoy and the spirit of engineering information sharing from the valley, https://www.righto.com/2023/02/8086-interrupt.html has a fascinating write-up on 8086 interrupt support. Ken's work is more generally described in his various talks, such as https://podcasts.apple.com/us/podcast/ken-shirriff/id1488187473?i=1000506639971 and https://www.youtube.com/watch?v=TKi1xX7KKOI.This reminded me of my first file & issued patent (now expired) https://patents.google.com/patent/US5940587A/en, which used some trickery of the segments and the interrupt table to save space in the BIOS.  Good times.

PPS+

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 http://vzimmer.blogspot.com/2021/01/memories-from-uw-and-cornell.html. Although Larry and I had similar Java challenges in the late 90's, it appears that our respective careers took different arcs.

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.