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

New milestones

 A year ago I commented on co-workers and patent achievements http://vzimmer.blogspot.com/2021/07/patents-and-co-inventors.html. One aspect of that note included https://en.wikipedia.org/wiki/List_of_prolific_inventors and its new metric of 'patents / year', or what I'd call 'patent velocity.' Let's call it Vp. And of course it's a marathon, not a sprint. As such, the other interesting metric from the latter link is the 'patent years.' So doing basic calculus we can compute the integral of Vp over 'patent years' to yield Xp, or 'total patents.'

And it's that Xp that is interesting. From a 2003 posting by Tom Dunlap https://intelretiree.com/wp-content/uploads/2015/06/Tom-Dunlap-LAI.pdf which included the following snippet:

On the list you'll see some of the prolific inventors on https://en.wikipedia.org/wiki/List_of_prolific_inventors. Most are still with Intel AFAIK, too. 

And from the list you can at least track US issue milestones.

• Glenn Hinton was the first to 100 US patents in November 2006
• Robert Chau was then the first to 200 US patents in March 2010
• Zimmer was first to 300 in July 2014 w/ Chau a close second to 300 in October 2014
• Robert Chau was the first to 400 in October 2017
• And as of this week, Jack is first to 500 in September 2022

            Results of Search in US Patent Collection db for:
            (APT/1 AND IN/Kavalieros-Jack$): 500 patents.
            Hits 1 through 50 out of 500

Nice to see that the IP leaders Robert and Jack https://spectrum.ieee.org/2021-inventor-of-the-year are keeping Moore's Law alive in components research https://www.intel.com/content/www/us/en/newsroom/news/where-tomorrow-begins-intels-components-research-labs.html#gs.bgt8t0. Good times.

PQC

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

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

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

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

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

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

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

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

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

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

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

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

100 posts

This marks my 100th blog posting, spanning 3 decades of blogs 1999-2022 https://vzimmer.blogspot.com/. 

This corresponds with 3 decades of publications https://dblp.org/pid/34/5641.html.

 

I start spilling across another decade, though, with 4 decades of patents https://en.wikipedia.org/wiki/List_of_prolific_inventors 1999—2022 , which generally tracks my Intel career of February 1997 to this date in 2022 touching 4 decades, too, namely 1990's, 2000's, 2010's, 2020's, respectively.

These are some pretty rough blogs hosted on a free blogging platform comprised mostly of rambling thoughts, with a few repeats, and little to no editing.

This effort is definitely not part of the day job. For after hours there are already a lot of other non-day job writing activities queued up historically, including patents, papers, books.  As such, this blog has often been often log-jammed behind those. It's hard to priority boost, other than signaling events like IDF STM unleashed http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html I posted right after delivering https://www.intel.com/content/dam/develop/external/us/en/documents/stts003-sf15-stts003-100f-820238.pdf in San Francisco in 2015. Latter took a winding path. Showed up in coreboot  https://review.coreboot.org/c/coreboot/+/33234 https://www.platformsecuritysummit.com/2018/speaker/myers/ and a variant in ppam https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm-based-computing-whitepaper.pdf. OG info can still be found at https://www.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching-stm-to-monitor-smm-in-efi-developer-kit-ii-819978.pdf  and  https://cdrdv2.intel.com/v1/dl/getContent/671411 and   I guess that I should go back and update the 'released' blog posting, too since so many of the referenced sites have come and gone over time. I can easily see how much history (I was about to type 'wisdom' but I cannot claim to discern wisdom signal from information glut noise easily) is lost during our age of everything online. 

While running into a colleague during the first visit to Oregon after COVID quarantine ended I was given a recommendation to read https://www.amazon.com/Inside-Intel-Worlds-Powerful-Company/dp/0452276438. The book ended in 1997, the year I joined Intel, so I cannot claim to have experienced the environment first hand. But some aspects of the culture described did map to my early Intel years. One quote I especially liked, though, was about how to work with an long-lived culture of technology, namely:

"Respect the past, be honest about the present, be optimistic about the future"

Or something like that. The stories about Hungarian Grove, whose signature I picked up as a recent hire shown in http://vzimmer.blogspot.com/2014/02/, reminded me of the manager in Oregon with whom I interviewed in October 1996, Mil Travniceck and then offered me the job, although I hemmed and hawed a few months while still working at Compaq prior to ultimately joining Intel in February 1997. From the first edition of https://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908

Mil coached me on many things, including life at Intel. He would always have the paper notebook and record meticulous details of our 1:1's, following the style described in Grove's https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884. Mil was also from eastern Europe and had a deep accent. I never asked him his origin story, though. He was pretty legendary in the Intel BIOS community at the time and I appreciate the opportunity to have been hired by, learned from, and mentored by him in those early years in DuPont, WA. I still recall the last conversation I had with him. Although I was hired by him to lead the 64-bit Merced firmware in the High End Server Division (HESD), I had since moved on to the EFI team in the Microcomputer Software Labs (MSL) of the microprocessor division MD6. Mil was always a bit skeptical of the move from legacy BIOS, and in the hallway that day he challenged me "Is this move to EFI a good idea. A move away from legacy? You know legacy, we're really good at that here at Intel." 

Those are some words I'd like to carry forward, too. In this blog, though, maybe I'm starting to repeat myself.  As I close blog posting 100, maybe the universe is telling me that this blog stream is 'done'. Or maybe it's still an opportunity to practice respect, honesty, and optimism.

fin (100)