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

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

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

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

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

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

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

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

Open Source Firmware Conference 2020

Bret Barkelew6 hours ago

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

J. Redpath5 hours ago

a sign of something good

Vincent Zimmer5 hours ago

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

Diego Rodríguez5 hours ago

^this

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The PC industry has followed an interesting arc, beginning with the hardware and firmware details of the original IBM PC http://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf and the closed source Microsoft (MS) operating system MS/DOS https://github.com/microsoft/MS-DOS. The former allowed for the ability to have clones of the IBM PC, whereas the latter ensured some consistency in the platform design as compatibility with DOS, and then Windows, helped provide for the open platform that non-MS OS's like Linux today enjoy.

Was the distinction between MS as an OS vendor (OSV) and the industry as a platform provider always so stark? In fact, the existence of MS-written firmware, as one example, has had various examples spanning the 90's up through today's news.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To begin:

In the early days of Windows NT, including 3.51 and 4.0, Microsoft wrote the ARC boot firmware for their DEC Alpha and MIPS NT platforms. ARC stands for Advanced RISC Computing https://en.wikipedia.org/wiki/Advanced_RISC_Computing and the document http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf provided guidance on both platform hardware and firmware. A couple of MS engineers wrote the first ARC firmware and the ARC specification, along with IEEE 1275 Open Firmware (OF) https://www.openfirmware.info/data/docs/of1275.pdf, were considered as a solution for 'how to boot Itanium' during the early days of the IBI/EFI specification. 1275 came up because the PowerPC port of NT booted via OF. EFI ended up looking more like ARC, see similarity between the ARC Firmware Function Vector and UEFI System Table, although OF does have some advantages, especially for security https://www.cs.cornell.edu/~kozen/Papers/acsac.pdf.

Another interesting aspect of the ARC Alpha firmware was that the NT NDIS miniport drivers from NT were embedded in the firmware for purposes of pre-OS networking, such as network booting. Other than boot loaders like U-Boot which liberally leverages portions of device driver code, this OS and firmware code sharing helps solve one of the main challenges of boot firmware, namely having to create a firmware version of a device driver for the block, network, and console services in the pre-OS and another variant for the OS runtime.

Fast forward to the early 2000's. At that time there was a project called FlexGo https://en.wikipedia.org/wiki/Microsoft_FlexGo which allowed for a metered, or subscription PC. There was MS firmware integrated into the code morpher, or microcode-like firmware of the Transmeta device https://en.wikipedia.org/wiki/Transmeta https://www.extremetech.com/extreme/76602-amd-to-resell-transmetas-payasyougo-chip. For some of the standard PC's at the time, there was exploration of having the monitoring agent from MS as an additional handler in System Management Mode (SMM) of the BIOS

In the early 2010's, the industry was moving from a TPM 1.2 to 2.0. One of the learning's from the 1.2 era was that the specification for the commands lent themselves to various interpretations. As such, the TPM 2.0 specification was written in 'literate code' where the C based implementation of the commands could be extracted. The latter C code has formed the underlying implementation https://github.com/microsoft/ms-tpm-20-ref for all of the integrated and discrete 2.0 devices. This code was born of the 'firmware TPM' work described in the technical report https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2015-84.pdf.

In the 20-teens, there emerged from Microsoft Project Mu for BIOS https://microsoft.github.io/mu/. Although this is officially referred to as a downstream fork of EDKII on tianocore.org, there are many unique aspects, especially features like DFCI in https://github.com/microsoft/mu_plus.

A more recent example includes MS writing the SMM supervisor for AMD SecureCore PC https://www.microsoft.com/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/ variant mentioned during OSFC '20 'hallway chat.'

And for the broader industry MS wrote many SMM audit and checking tools in Mu to help prepare the OEM ecosystem for having their handlers running in the jailed context of the SecureCore PC SMm supervisor.

In the future, MS hardware Pluton hardware and firmware https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ may be even more deeply integrated.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Beyond the long run of the MS examples above you can see a similar, albeit shorter in time, arc for Google, especially Google as an OSV with respect to ChromeOS. It begins with the Google Chromebooks leveraging coreboot + vboot https://www.coreboot.org/ where Google employees are many of the upstream maintainers.

More recently, the Titan/OpenTitan https://opentitan.org/ has emerged. This is a root of trust with the CPU based upon RISC-V and the operating system based upon the Tock OS https://github.com/google/tock-on-titan written in Rust. Interesting stuff.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And you cannot have firmware without hardware, of course. Google Titan-M and the OpenTitan are one example.

For Microsoft, MS already has its XBox360 https://en.wikipedia.org/wiki/Xbox_360_technical_specifications and XBox One https://en.wikipedia.org/wiki/Xbox_One, which were custom PowerPC "Watermoose" and AMD "Jaguar" based SOC's, respectively.

There are also always rumors in the air for MS, such as recent one on ARM https://arstechnica.com/gadgets/2020/12/microsoft-may-be-developing-its-own-in-house-arm-cpu-designs/ and earlier one on custom designs like E2 https://www.theregister.com/2018/06/18/microsoft_e2_edge_windows_10/.

For Google we already have ample public details on their Tensor Processing Unit (TPU) https://semiengineering.com/knowledge_centers/integrated-circuit/ic-types/processors/tensor-processing-unit-tpu/ and the above-listed Open Titan first party silicon, but these are not general purpose system on a chip (SOC). Of course even Google has the rumor mill swirling on occasion with stories like "Whitechapel"https://www.theverge.com/2020/4/14/21221062/google-processor-pixels-chromebooks-whitechapel-samsung-qualcomm, too.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So how does the OS impact the firmware? Well, since the firmware is closely tied to the overall platform and hardware design, OS 'requirements' documents http://download.microsoft.com/download/7/0/e/70e74967-b0fe-477a-974f-c1ed16ee31df/windows8-1-hardware-cert-requirements-system.pdf and https://source.android.com/compatibility/10/android-10-cdd can dictate some of these choices. And even for more open firmware implementations like Chromebooks you can see the coupling https://www.chromium.org/chromium-os/2014-firmware-summit.

In reading Bezos' book 'invent and wander' https://www.amazon.com/Invent-Wander-Collected-Writings-Introduction-ebook/dp/B08BCCT6MW he mentioned a couple of different problem solving techniques. The first includes a skills-forward problem solving approach where a team leverages what it knows to create products. This is more common in the industry and represents an amortization of an established set of capabilities and perhaps a given moat.' This is in contrast with a customer-problem first approach where you may need to invent a solution or build a competency. Bezos cited the Amazon Kindle which represented an approach to a customer problem, namely handling their library. And in pursuing solution of this problem, Amazon had to acquire skills in hardware development, create new models of cellular downloads, and evolve screen technologies..

Reading this passage coincided with the recent update of my patent list, namely hitting the 450 milestone of issued US patents, viz., http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=0&p=1&f=S&l=50&d=PTXT&Query=apt%2F1+and+in%2FZimmer-Vincent$

As always with invention, I am as excited by the problem being addressed as my collaborators and co-inventors, including the following parties:

Yao, Chaganty, Ma, Rangarajan, Poornachandran, Aggarwal, Mudusuru, Zimmer, Yarlagadda, Chan, Das, "Enhanced Secure Boot," Issued 1/5/2021, US Patent #10,885,199

This small incremental increase cannot stem the tide of getting pushed further outside of the top 100 https://en.wikipedia.org/wiki/List_of_prolific_inventors

I fear, but the absolute number of patents was never the figure of interest. It has always been about supporting business-driven innovation http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html.

Speaking of numbers, https://link.springer.com/book/10.1007/978-1-4842-0070-4 passed 300k downloads, too, during this same week.

The downloads on this book are probably 10x those of https://link.springer.com/book/10.1007/978-1-4842-6106-4, which speaks to the power of the open access model. I see similar diminutive numbers on other pay-walled publications, such as the Simics fuzzing paper with small double https://ieeexplore.ieee.org/document/9218694 and single https://dl.acm.org/doi/abs/10.5555/3437539.3437751 digit downloads, respectively.

Beyond downloads, another interesting statistic is citations. https://scholar.google.com/citations?hl=en&user=9fW87_IAAAAJ has the broadest collection of citations, whereas https://dblp.org/pid/34/5641, https://www.scopus.com/authid/detail.uri?authorId=26325201900, https://dl.acm.org/profile/81464676924, https://www.semanticscholar.org/author/V.-Zimmer/46617443, and https://ieeexplore.ieee.org/author/37088526460 find differing subsets.

2020 was quite an interesting year. Let's see if 2021 offers the same vicissitudes. Hopefully these ramblings about invention and numbers auger well for 2021. As I heard once, put a number next to someones name on the internet and they will obsess or do what they can to increase it. Twitter followers, LinkedIn connections, video views...... Hopefully I don't subscribe to that numeric obsession.

This is something of a random blog posting.

As the new year rolls around, I became thoughtful of the page of milestones. These include my time at the University of Washington here in Seattle https://www.cs.washington.edu/ getting my CS Masters during the 1997-1999 time frame.

I spoke a bit about the UWCSE in http://vzimmer.blogspot.com/2018/06/ along with the now-closed https://www.livingcomputers.org/. Given the recent interest in retrocomputing https://www.nytimes.com/2021/01/08/style/retrocomputing.html the museum would be overrun with aficionados if it were open.

I frame many of my UW memories via the professors. These included John Zahorjan https://www.cs.washington.edu/people/faculty/zahorjan on computer performance. I recall one project with a classmate Amanda Barrett (then an employee at Teledescic, Macaw's attempt at a satellite communications network in the late 90's) on modeling different web server scheduling policies, such as Round Robin DNS (RR-DNS) using C++Sim. The most interesting part of the effort was the ability to drive the simulation with anonymized, real-life web traffic from Metacrawler by way of UW alum Brian Pinkerton alumni https://en.wikipedia.org/wiki/WebCrawler https://www.w3.org/Conferences/WWW4/Papers/169/.

The next professor I recall is Anna Karlin for algorithms https://www.cs.washington.edu/people/faculty/karlin. She taught my first class at UW. The take-away I have from that course was the value and extent of mathematical rigor behind algorithms. From my undergraduate and 5 years prior industry experience I saw algorithms more as rote recipes than evolve mathemtical objects.

Next up was the artificial intelligence course with Dan Weld https://www.cs.washington.edu/people/faculty/weld. Like the performance class above, my strongest impression was the project course. The specific project included writing a movie recommendation system for movies. We would create Java wrappers for websites, such as for the recently launched https://www.imdb.com/, to support queries written in Datalog https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_968. It would allow the end user to write queries, such as 'Show me all of the movies in Seattle starring Tom Hanks.' The downside of the system is that this work predated the semantic web and the website wrappers had to continually get updated based upon the changes in sites like IMDB.

The other part I recall from the AI adventure is that my partner was a local Intel DuPont employee in another team. His manager was much more liberal about taking classes so he had the opportunity to work on the course during the work day. My management, who had initially replied to me when I requested funding for the masters project with 'why do you want to take classes, you are already smart enough?' didn't permit such liberties. So like my patent writing of the last 20 years, my masters work was always a late-night after-hours and predominately weekend activity.

From AI I recall taking a second algorithms class with Richard Ladner https://www.cs.washington.edu/people/faculty/ladner. I still recall a quote from Ladner early in the quarter, namely "I cannot teach you everything about algorithms since the field is so broad and continually changing, but what I can do is teach you have to do research and learn on your own." The deep project work done in that class involving assessing recent publications has stayed with me. And the wisdom still holds true today, every field is continually changing. Sort of the academic analogy to the pre-Socratic Heraclitis quote "You cannot step into the same place in a river twice."

Another part of the UW journey was sorrow, too, including the passing of my advisor https://s3-us-west-2.amazonaws.com/www-cse-public/publications/msb/msb11.1.pdf.

Just like my undergraduate journey, I didn't have the luxury to take so many courses, so I calculated the exact number of credits I needed to get my degree. For undergraduate urgency the timing was economic based, whereas for my masters it was lifestyle based (i.e., high pressure job with hardware power-ons, new-borne daughter, etc). As such, one way to complete the requirements was through research credits, and one effort involved working on a project with Susan Eggers https://homes.cs.washington.edu/~eggers/. She was a huge influence on me in computer architecture, and after meeting her, some of the stories I late reach https://egc.yale.edu/how-job-yale-1960s-set-susan-eggers-groundbreaking-path-computer-science did not surprise me at all.

Since distance learning was a bit nascent in the late 90's, I still recall hurrying from DuPont, WA Intel site to the U District in Seattle. I tried to time my arrival such that when the street parking became free at 6pm I could find a slot.

And the old CS building Sieg Hall, ah......

Definitely quite a change from the new EE/CS building, especially the Amazon auditorium. I luckily managed to catch a couple of interesting talks there in the last couple of years, including Patterson preaching about RISC-V https://www.youtube.com/watch?v=mD-njD2QKN0 (and getting one of the single-page ISA descriptions printed on green paper) and David Bacon on the evolution of quantum computing https://phys.washington.edu/events/2019-12-10/cse-colloquium-quantum-computer-versus-supercomputer.

An interesting aspect of the university, versus industry, is that the rank of a professor is much more explicit, such as the laddering of associate versus assistant versus full versus emeritus professor, respectively. Compare this with the wild variability of job titles in the technology industry https://www.levels.fyi/, for example. A principal at one company versus a partner at another versus....although https://news.ycombinator.com/item?id=25758663 recently had an interesting discussion thread on the topic.

Speaking of partner title, I still recall one MS partner architect telling me that partner is the 'throw the other guy under the bus' job band. This spoke to the highly competitive nature of the job category since like many domains the higher you advance leads to few openings and broader expectations with the competition to advance and challenge to sustain the level being commensurately intense.

Even in my early late teens I saw a glimpse into this. At Cornell I recall a fellow undergraduate who had interned at Goldman. He related tales of other interns sniping at each other openly during presentations each was required to make. The same calculus applies - exclusive job category with high compensation, thus some 'throw them under the bus' behaviors.

Speaking of Cornell working on my BS EE https://www.ece.cornell.edu/ece during the 1988-1991 window, a few memories come to mind. The first includes the luminaries who visited campus, such as Normal Mailer and Roger Penrose to give talks. Penrose, Kip Thorne, and other physicists were drawn to a department that still had Hans Bethe https://en.wikipedia.org/wiki/Hans_Bethe. This was the same physics department that hosted the Feynman lectures. And for literature Cornell was the abode of the likes of Vladimir Nabakov, too.

Just like UW the professors made some of the largest impacts. These include Dynkin for real analysis https://news.cornell.edu/stories/2014/11/mathematician-eugene-dynkin-dies-90, Terrence Fine on probability https://www.engineering.cornell.edu/faculty-directory/terrence-fine, and the father of information retrieval Gerard Salton https://en.wikipedia.org/wiki/Gerard_Salton for discrete math. Cornell didn't just send TA's to instruct undergraduates but instead offered access to world class researchers in their fields.

Moving from maths to engineering, Prof Torng https://news.cornell.edu/stories/1997/12/cornell-professor-honored-intel-corp-his-computer-chip-improvement taught the course on digital design. K-maps, Mealy-Moore machines, etc. Good stuff.

And closest to home there was Professor Gries https://www.cs.cornell.edu/home/gries/gries.html class on computability theory. This started with computational complexity, big-O notation, and other rudiments, leading into Hoare triples, such as pre-conditions, post-conditions, and invariants. I still remember walking down the hall of the computer science building and seeing a room filled wall-to-wall with silver-covered Springer-Verlag "Texts and monographs in computer science."

Beyond visiting speakers and professors I recall lots of lake-effect snows and winds during the winter, and beautiful changes of seasons and the rugged environment of Ithaca, New York. There was a common theme on T-shirts and car stickers of 'Ithaca is gorges' as a play on the terrain and 'gorgeous' scenery up upstate New York.

Since I was so far from home and living on a budget, I would only return back to Houston for events like Christmas or summer. I recall one thanksgiving holidays eating at gas station since I had forgotten to do grocery shopping ahead of time. Other times I would travel to visit my aunt in New Jersey by way of New York Port Authority. Port Authority was definitely a stark contrast from bucolic Ithaca, NY or suburban Houston. I recall one trek through Port Authority when there was a body in a wheel chair parked outside of the bathroom. A sheet covered the bulk of the person but the hands were protruding with what looked like the stiffness of rigor. The crowd in the bus terminal where walking around the body as if it were just another obstruction on the path of their daily routine. Another trick I learned going through Port Authority with my suitcase was to put my money in my shoe. I'd leave $5 in my wallet so that when someone invariably wanted to 'help me' find my connecting bus terminal and then requested a gratuity because "you know I could be doing much worse to make money", I could satisfy the request and not get rolled for all of my traveling money.

When I think of growing up in Houston, or the US Southwest, doing undergrad in Ithaca in the US Northeast, and now leaving in the US Pacific Northwest, I'm mostly covered the continental US. Heat in the SW, cold in the NE, and rain in the NW. I'm only missing living in the US Southeast, such as Florida. But after reading Thomas McGuane's 'Ninety-two in the Shade'https://www.goodreads.com/book/show/51598.Ninety_two_in_the_Shade in my youth, I wasn't so anxious to move to that area.

I always liked books. I used to drive my bicycle to Half-Price books in Houston as a teenager. As I got older, I would drive myself to the various stores across the city.

In addition to used book stores, there are the annual library book sales. The best book sales ever was Cayuga County library in Ithaca, near Cornell. I walked there every year from my college resident on top fo the hill. The downside was walking back w/ hoard of books.

When I first moved to the Pacific Northwest in 1997 there was a one time book sale at UW Seattle hosted by the university. A few years later the Seattle Public library system would hold the sale in an old hanger at Sands Point.

The ideal, though, are university venues or sales proximate to them, like half-price books in Houston U. Village, Cornell's Cayuga County or the now-shuttered Half-Price Books on Roosevelt in Seattle U. District near the main UW Seattle campus given the donations from students and professors.

So this blog is a collection of some of those old books, and some that I've written, that have a common theme of Intel-related technologies.

Beginning in the 1980's, Intel-related books were published by McGraw Hill

https://www.amazon.com/Programmers-View-Intel-432-System/dp/0070477191

Moving forward into the 1990's, McGraw Hill and Intel had a hybrid publication model

https://www.amazon.com/Real-Time-Systems-Programming-PCs-McGraw-Hill/dp/0070674604/

https://www.amazon.com/Intels-Architecture-Designing-Applications-McGraw-Hill/dp/0079113362/

For my Intel career, I have worked at Intel during the leadership of author CEO's, namely Andy Grove (when I joined in 1997) and Pat Gelsinger (starting 2021). Their author careers commence with technical books, and their later writing includes business texts. None of these are Intel Press, though.

https://www.amazon.com/Physics-Technology-Semiconductor-Devices-International/dp/0471329983

https://www.amazon.com/Juggling-Act-Bringing-Balance-Family/dp/1434768740/

https://www.amazon.com/Only-Paranoid-Survive-Exploit-Challenge/dp/0385483821/

https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884/

https://www.amazon.com/Programming-80386-John-H-Crawford/dp/0895883813/

Regarding Gelsinger, there is an interesting quote in the juggling book

During the 2000's Intel Press emerged. This was my first encounter with technical book publication. My journey started with technical and has stayed with technical. I co-authored a few editions of beyond bios, a couple of the shell, an embedded book, and finally a firmware security book to round off the stack. The corpus includes 7 texts spanning 3 different publishers and 8 co-authors from 2006 to 2020.

https://www.springer.com/us/book/9781484261057

https://www.degruyter.com/view/title/526442

https://www.degruyter.com/view/title/526433

https://www.springer.com/us/book/9781484200711

https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/

https://www.amazon.com/gp/product/1934053147/

https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908

One of the publishers was Intel Press https://www.bookdepository.com/publishers/Intel-Press, who also published the Intel Technology Journal (ITJ) first published in 1997 https://www.intel.com/content/dam/www/public/us/en/documents/research/1997-vol01-iss-3-intel-technology-journal.pdf, my first year at Intel. I really admired the issues and was thrilled to have the opportunity to lead an issue in 2011 https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf

Regarding the title, the 'compute continuum' was trending that year, with the ability to scale from IOT to server. I haven't heard the term used in the last few years, though. Maybe the broad class of device support is just assumed with modern software stacks?

I co-authored 3 articles in that edition of the journal, including an overview of UEFI, one on silicon enabling, and finally one on security & networking, as shown below.

I later cited that 3rd article in my last book

Namely

I do regret not writing more on firmware networking over these last 20 years. I mention it in the article above and provide some prospective views in the 09 SAM paper on Cloud Computing https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer09.html?view=bibtex. More on this on a subsequent posting.

Speaking of articles, citations, and the latest APress security book, I was pleased to have a copy of the Shannon 1949 paper http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

and then quoting and citing the same

in the firmware security book. I was not so diligent in providing references in my earlier books I fear. Regarding Shannon and the Apress book, that's a window of 1949 to 2020. Quite a run of 70 years for security.

Finally, my book journey started with Intel Press, traveled to De Gruyter, and ended with APress. APress is actually an imprint of Springer-Verlag. And I was lucky enough to have an opportunity to co-author a chapter for a Springer-Verlag book in 2009

https://www.springer.com/us/book/9781402094354

This chapter has aged reasonably well, other than some of the descriptions of Itanium SAL. Regarding the other books, it will be interesting to see how some of this material ages. For Beyond BIOS I discussed platform types in chapter 7. The evolution begin in '06 where I had an example of the ARM XScale work I had done in '01, but I elided this in the 2010 2nd edition in lieu of the SOC Intel chips. Fast forward to 2017 third edition the chapter again evolved to describe the Intel Firmware Support Package (FSP). Other portions of the text, such as the description of handles and protocols, have stood the test of time much better.

And I am still grateful for the opportunity to write the long-removed "Update at Intel" article on EFI and the Framework in 2004.

"Update at Intel" was a web-hosted set of short articles on timely technology topics at Intel. It was much lighter-weight than the Intel Technology Journal. It was this January 2004 publication that attracted the attention of one of the Intel Press editors to approach me about writing the initial Beyond BIOS book. And it's my one publication with the nostalgic drop-e in the logo, too, since the '06 Beyond BIOS coincided with the logo change

Ah....good times.

"Accessing UEFI from the operating system runtime" http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html represents my most frequently accessed blog posting. In fact I scrawled this quick posting in response to an engineer having recently sent me a mail referencing the above posting and decrying lack of information on access to the UpdateCapsule interface from the various OS's.

To begin, let's start with the API exposed by the UEFI firmware is defined as followed:

The capsule in memory follows:

From my perspective as a 'builder' of firmware I often focus on the underlying constituent elements, but that's a smaller audience than the consumers of the firmware. At the time of the posting, the UEFI Variable interface was the more important interface in order to access both UEFI specification defined variables, namely those {GUID, Unicode String} named pairs codified in the UEFI specification, and vendor-defined variable GUID's and Names.

In the five years that have followed that posting, there's another important extensible run time interface that has been exposed to the operating system run time, namely the UpdateCapsule interface. The Capsule infrastructure began as part of the Intel Framework corpus https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-capsule-specification.html, but was eventually donated into the UEFI Forum in a similar specification arc as HII. Recall that much of the Intel Framework specifications, such as PEI and DXE, became pillars of the UEFI Platform Initialization (PI) specifications, but when an interface needs interoperability between the pre-OS ISV's and OS runtimes, that is purveiw of the UEFI (and ACPI) specifications. Microsoft complemented this Framework-era capsule infrastructure with the ESRT, or a list of updatable elements in the platform defined by a list of GUID's.

Although the UpdateCapsule API can be used to convey any information from the run into the pre-OS, including crash-dump, management information, etc, the 'firmware update' usage is the most important from a business perspective.

And regarding the API, having a definition of the interface and the data enveloping mechanism are necessary but not sufficient. You also need producers of the update interface on system boards and infrastructure software to invoke the interface. To that end, the EDKII community has published a rich set of infrastructure code to provide the interface https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery with a detailed code explication in https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. On the operating system side, there is infrastructure to support invoking the interface for both Linux https://lists.gt.net/linux/kernel/2149809 and Microsoft Windows https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/system-and-device-firmware-updates-via-a-firmware-driver-package.

The Linux kernel exposes the capsule loader interface via sysfs in a similar fashion to how the UEFI variable interfaces are exposed. The Windows implementation, though, doesn't expose the direct interface but instead conjoins issuing capsules on top of the infrastructure for installing drivers. This is where the distinction between capsules as a mechanism to pass a GUID-named data payload with a scatter-gather list in memory back to firmware compares to usage of this interface to pass payloads that are a firmware update. On the latter point of updates, the Linux community has build out the fwupd service http://fwupd.org/ to facilitate pushing out updates in a similar fashion to Windows Update http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_07_Microsoft.pdf. https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-update provides an interesting view into steps involved in plumbing a Linux distribution for this end-to-end use case, too.

You can think of the UpdateCapsule invocation as a syscall back to the firmware. This is different than UEFI Variables where the expectation that the 'set' call persists immediately without and intervening platform restart. Instead, by having the UpdateCapsule take effect (typically) across a restart, the update of the underlying firmware can occur in the early boot of the firmware Trusted Computing Base (TCB) prior to running third party code. Or a capsule can just be passed through, such as the case of the OS runtime sending its panic screen to be displayed across a restart to its UEFI OS loader.

Philosophical postlude -
The difference between UpdateCaspule versus the Get/Set Variable interface is that the latter has been available in the EFI (and then UEFI) OS's since 1999. Update Capsule, and the corresponding ESRT, have only appeared more recently. If I had a chance to invoke George Cox's http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html "I could do it better the 2nd time" penchant of engineering, I would have argued that art such as UEFI Authenticated Variables would have been better built as signed UEFI Capsules versus UEFI Variables since authentication-at-reset in the PI phase (BIOS TCB) is much easier to build than an authentication agent in the firmware that is isolated from the OS or hypervisor run time, as needed by the UEFI Authenticated Variables.

Sigh. Hindsight is 20/20.

Saturdays are interesting, especially working for a multinational company with colleagues across the globe. I may have shared this sentiment before, but I still recall the tale that resonated with me from a currency arbitrage trader https://www.investopedia.com/terms/c/currency-arbitrage.asp. The person mentioned that he was working whenever a market was open. Luckily Saturday is the one day without any market open so he would use that day to do laundry, go grocery shopping, and follow-up on other chores. Feels like the work life of many in Friedman's flat world :). Thus stealing a few moments on the Saturday nadir of activity for a quick blog.....

I'll commence this blog with observations about books, starting with my most recent https://www.apress.com/us/book/9781484261057

Ir is not quite small, weighing in at 930 pp.

It's the 7th physical book / printing I have in hand. It culminates a stack of dead trees spanning 3 editions of Beyond BIOS, two of the Shell, security, and embedded. Publishers of this stack range from Intel Press (shuttered 5 years ago) through De Gruyter https://en.wikipedia.org/wiki/De_Gruyter and into Apress. And I also had 8 different co-authors spanning employers past or present including Intel, Phoenix, Insyde, Google, ARM, retirement, Sage, and Amazon. I've been at Intel the whole course of the book runs, though. The mountain of paper is shown below.

[from top down]

https://www.degruyter.com/view/title/526433

https://www.degruyter.com/view/title/526442

https://www.apress.com/us/book/9781484200711

https://www.amazon.com/Beyond-BIOS-Implem enting-Extensible-Interface/dp/0974364908

https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/

https://www.amazon.com/gp/product/1934053147/

https://www.amazon.com/gp/product/1484261054/

Now for a bit of history of Intel and tech books, at least as far as I'm aware. Prior to Intel Press, Intel technical books were done through McGraw Hill in the 1980's. Below is one example from my nearby shelf.

https://www.amazon.com/Programmers-View-Intel-432-System/dp/0070477191

Then in the 1990's there were McGraw Hill / Intel joint imprints, such as the RMX and 486SL books below.

https://www.amazon.com/Real-Time-Systems-Programming-PCs-McGraw-Hill/dp/0070674663

https://www.amazon.com/Intels-Architecture-Designing-Applications-McGraw-Hill/dp/0079113362

I especially like the the drop-e in the logo of those books which was removed in 2006 by Intel.

And in the 2000's Intel Press published both books https://openlibrary.org/publishers/Intel_Press https://www.intel.cn/content/dam/www/public/us/en/documents/white-papers/developer-reading-list.pdf and the Intel Technology Journal (ITJ). I still recall reading the first IT issue https://www.intel.com/content/dam/www/public/us/en/documents/research/1997-vol01-iss-3-intel-technology-journal.pdf when I joined the company in 1997. I was happy to have the opportunity to lead the creation of the only printing in 2011

https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf. It made me feel like a small part of the technology history of the company.

In that 2011 issue I co-authored 3 of the papers, including networking and security

which was referenced in the Apress firmware security book, as shown below.

And luckily the Intel Technology Journal PDF's were all archived on Intel.com after Noggin.intel.com and Intel Press were closed down.

Another notable reference in the Apress security book was http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

which excerpted some of the principles of cryptography

and had the citation

I regret that only this final Apress book had rich citations. The other books were a bit light on the references. I'm still amazed by the longevity of Shannon's work on information theory and security.

Speaking of Apress, the publisher is actually an imprint of Springer Verlag https://en.wikipedia.org/wiki/Springer_Science%2BBusiness_Media. In 2009 I wrote a chapter for Springer

with original Beyond BIOS co-authors.

Outside of Intel presentations or patents, the 2004 "Update at Intel" article is the first of prose describing firmware. This was part of a series of articles posted on the Intel website about recent technology evolution. I still like the fact that it described the XScale ARM port I did in 2001 and had a Pentium 4 in the block diagram. This same XScale work was elaborated upon the 2006 Beyond BIOS book code fragment, being placed by a mobile internet device (MID) in the 2010 2nd edition of Beyond BIOS, and finally turning into a Intel FSP example in the 2017 3rd printing of the book. Interesting evolution of the platform across the decade and a half.

It's also the only publication with a 'drop-e' that I created, too.

I still fondly recall the CDSA and ACSFL update articles, but unlike the ITJ, these pages have not been archived on intel.com, the wayback machine of archive.org, or other computer history repositories of lore such as bitsavers.org. For work that never made it to open source, I wonder how much interesting technology history is lost every year?

In the spirit of the written word, and despite questions of the demise of print https://www.stamats.com/think-print-dead-think-again/, it's nice to see that Grove, CEO when I joined in 1997, and Gelsinger, upcoming CEO this year, expressed both their technology and business insights via writing.

[from top down]

https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884

https://www.amazon.com/Only-Paranoid-Survive-Exploit-Challenge-ebook/dp/B0036S4B2G

https://www.amazon.com/Juggling-Act-Bringing-Balance-Family/dp/1434768740

https://www.amazon.com/Physics-Technology-Semiconductor-Devices-International/dp/0471329983

https://www.amazon.com/Programming-80386-John-H-Crawford/dp/0895883813

Writing books is one way to scale one's knowledge that transcends the utility of (cough cough) blogs, streaming video and podcasts IMHO.

Regarding the writing process, I am not sure about how easy of a time either my co-authors or luminaies like Grove and Gelsinger had in writing their tech and business books, but I feel like the following when trying to get the pages out.

So much for this Saturday typing. Here's looking forward to market openings and meetings commencing tomorrow.

I was pretty late last year in posting http://vzimmer.blogspot.com/2020/05/recovery-tech-talks-23-or.html in order to maintain this ritual. It's OK to be late but I cannot really make up by being early in 2021 since there is no guarantee that will be employed on the anniversary date, of course.

As such, here's the anniversary year 24 edition. It features rolling into upcoming year, which may culminate in the '25' edition of this posting, the need to take the extended sabbatical (extension based upon COVID), and hitting the 'rule of 75' at the near midpoint of this upcoming 12 months. Either way, I hope to have a "Anniversary^10 and 25 years" post.

I have definitely learned many things in the past past couple of decades, including how to take criticism, whether code & spec review or paper and patent feedback. It's tough sometimes but feedback provides one of the key ways to grow. There is always room to learn, too. Thanks to Hot, via Rob, for recent reference https://www.amazon.com/12-Essential-Skills-Software-Architects/dp/0321717295. I especially like the quote "Architecture is about business. It focuses on representing, communicating, and building on the key points of a technology or even a nontechnology solution that has beneficial impact to the business in some way."

Beyond keeping up with the times via feedback and book learning, I sometimes like to ponder the basics in this fast moving technology world. The basics include maths, science, and for computers. Vintage computer topics include the EDVAC http://web.mit.edu/STS.035/www/PDFs/edvac.pdf. This led me to think about pointer sizes. I started my career programming 8-bit 8051's with its infamous 16-bit 'DPTR' and Harvard Architecture. Then I moved to the 16-bit 186, 16-bit V20 286, 32-bit 386EX & 486 from Intel, 29k from AMD, and Pentium Pro. Then I segued to 64-bit with Itanium here at Intel where I on-boarded to lead some of the boot firmware development, and then EM64T/x64/x86_64 to provide the first EFI boot. But what about 128-bit https://en.wikipedia.org/wiki/128-bit_computing ?

My journey into the past led to some questions about the integer and pointer size of the Unisys 1100 (72 bit ptr, 576 bit integer?) mentioned in https://www2.cs.arizona.edu/~mccann/cstyle.html. GCC has a data type https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html. Maybe a future ILP128/LP128 to scale beyond today's ILP64/LP64 http://archive.opengroup.org/public/tech/aspen/lp64_wp.htm?

The C style document mentions DEC, which reminded me of some of the innovation they, as chronicled at http://simh.trailing-edge.com/dsarchive.html. During my undergraduate days at Cornell Digital was to place to go for systems work, and at Intel in the late 90's many ex-DEC engineers led the workstation work (e.g., Dileep B.).

Intel has been evolving physical addresses, too 5-level paging on Intel x86 https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf.

Most interesting regarding deployed systems is the AS/400 single level store w/ 64 or 128 bit pointers. I ran into this while reading 'inside the as/400'https://www.amazon.com/Inside-AS-400-Frank-Soltis/dp/1882419669 book, Some CPU's have 96-bit physical addresses with the size hidden by the SLIC - system level interface code. IBM also has 80 bit VA and 64-bit PA on IBM https://www.ibm.com/support/knowledgecenter/ssw_aix_71/generalprogramming/address_space.html.

These pointer size ruminations led me to think of the more recent paper on the subject, namely the RISC-V paper and the architecture's support of 128 bit addressing. From https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf:

"At the historic growth rate of the memory capacity of TOP500 champions, about 70% per year, a 64-bit address space would be exhausted in about two decades. To the extent that global addressability of such systems is desired, we contend that flat addressability is the best approach; RV128I provides a promising solution."

Andrew W. mentioned that the 128 bit binding was considering something of a joke when he described it at the 2016 coreboot conference https://www.youtube.com/watch?v=f0ykeMmqglI&feature=youtu.be (12:25).

In the intervening 5 years, though, the 'joke' takes on some more gravity with the comment about needing to work on the base spec for 128 bits (minute 3:58 of https://www.youtube.com/watch?utm_content=152341011&utm_medium=social&utm_source=linkedin&hss_channel=lcp-7579420&v=lg33UqZ_en0&feature=youtu.be)

There are no known soft or hard core IP implementations of RV128 I could find on the web, although the https://bellard.org/tinyemu/ RISC-V system emulator supports the RV128IMAFDQC base ISA (user level ISA version 2.2, privileged architecture version 1.10).

But extra bits do not have to be used for addressing. There are potential security usages https://riscv.org/wp-content/uploads/2017/12/Tue1554-xbgas-JLEIDEL.pdf, or more fringe ideas like mapping ipv6 address to memory locations https://patents.google.com/patent/US8266238.

Again, these are 128 bit pointers, not 128 bit data types. A lot of the SIMD/Vector ISA extensions have broken the 128 bit data type long ago. This is a "sizeof (pointer_in_128_bit_ISA) == 128" thing.

Speaking of RISC-V, I was interested to see the progress in the EDK2 RISC-V port https://fosdem.org/2021/schedule/event/firmware_uor/. Some of this work was inspired after my posting http://vzimmer.blogspot.com/2014/11/porting-to-new-architecture.html which led to position papers https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-001.pdf https://github.com/vincentjzimmer/Documents/blob/master/risc-v-uefi-talk-004.pdf and standards/open source work.

I asked the Fosdem developer if he had considered porting the UEFI Platform Initialization (PI) Management Mode (MM) to the System Binary Interface (SBI) https://github.com/riscv/opensbi machine mode. This is work we did https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf

in order to allow decoupling the SMM from the host firmware environment https://github.com/tianocore/edk2/tree/master/StandaloneMmPkg was originally done for loading SMM from the Firmware Support Package (FSP) with a prototype at https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64_smm. The work was then picked up by the ARM community who need to load the TrustZone-variant of MM during early boot (e.g., SEC or PEI). The architecture neutrality of MM software model could thus be applied to RISC-V, just as the original "SMM Framework" mentioned "xMI's" to cover by the x86 system management interrupt (SMI) on x86 and the platform management interrupt (PMI) on Itanium.

Today, though, SBI is really a set of call interfaces similar to the DEC Alpha PALcode or Itanium SAL/PAL Code. I mention both PAL and SAL from Itanium since some of the SBI are SOC-specific (e.g., ISA emulation) whereas others may map to the platform (e.g., debug console). The runtime of host firmware is always challenging, whether it's traditional SMM on x64 and UEFI runtime and the interpreted ACPI, or the IBM Opal runtime or device tree. As always the execution of runtime should be minimized in order to avoid impacting host OS / hypervisor resource management, with 'minion cores', Embedded Controllers, BMC's, and other SOC microcontrollers providing independent execution regimes.

The following announcement of a fellow Cornell alum Mark Charney on his linkedin page

https://www.linkedin.com/feed/update/urn:li:activity:6815764405725270016/ caught my eye today

where Mark is celebrating the receipt of his 100th US patent.

I especially liked the comment about collaboration. That has always been the most interesting aspect of the inventive and technical development process.

To that end, I roamed over to https://en.wikipedia.org/wiki/List_of_prolific_inventors to see about other Intel inventors, and to my surprise, I saw 30 Intel inventors listed. I believe that I have mentioned this site before in earlier postings, too, http://vzimmer.blogspot.com/2014/08/http://vzimmer.blogspot.com/2021/01/innovation-and-invention-redux.html.

Two immediate collaborators I recognize are Ned Smith and Mike Rothman.

I am a co-inventor on 272 of Mike's (96%) issued US patents and 27 of Ned's (9.7%)

Ned has a pretty interesting publication history, too, with dblp picking up https://dblp.org/pid/56/3580.html. This compares to my dblp list https://dblp.org/pid/34/5641.html. Regrettably no joint publications, although I'm a big fan of Ned's Clark Wilson integrity model study of the TPM. We cited this in https://link.springer.com/book/10.1007/978-1-4842-6106-4, for example, along with his IOT security book. That paper was presented at the Security and Management (SAM) conference in Las Vegas. I published my first four papers in the 2000's at that venue, too. If I recall Selim Aissi https://www.linkedin.com/in/aissi/ encouraged folks to contribute to that venue?

I spent time working with Ned when he was the VPro security architect, too https://www.intel.com/content/dam/www/public/us/en/documents/research/2008-vol12-iss-4-intel-technology-journal.pdf. And it looks like Ned and I were co-inventors my latest issued patent "Static and dynamic device profile reputation using cloud-based machine learning"11,049,039 with our erstwhile McAfee colleagues.

As for Mike Rothman, he has been a long-time collaborator (and physical office neighbor when we aren't in COVID seclusion). Mike overlaps on my dblp above with a couple of books and we also contribute to the firmware standards, including the review of the UEFI ecosystem in https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf

Perusing the list further I see David Durham with whom I collaborated on a few patents

or 4% of his total 216. And finally, one joint patent with another Cornell alum Gil Neiger

out of his 211 patents (0.5%) as of July 6, 2021, along with some of the other Intel virtualization crowd https://ieeexplore.ieee.org/document/1430631.

Although Neiger and Charney are Cornell alums, they are Phd's & I am but a BSEE from Cornell and MS Comp Sci from UW here in Seattle. I was reminded of my lowly spot on the tech education totem pole when shopping at Fred Meyer in Issaquah, WA last night and two customers were loudly speaking with each other in the vegetable section. I caught the fragment of their conversation "...and he only has an MS and not even a Phd." I didn't recognize the two but at that point I seriously doubted my credentials to buy that bundle of organic carrots I had in my hand....

Although we are not co-inventors on any patents, my more immediate neighbors on the https://en.wikipedia.org/wiki/List_of_prolific_inventors list include the number one Intel inventor Robert Chau https://newsroom.intel.com/news/creating-new-technologies-keep-moores-law-alive-well/ and number three inventor Jack Kavalieros https://www.intel.com/content/www/us/en/newsroom/news/2021-inventor-year.html#gs.55miv2

who bound me from above with Chau's 486 patents, my 453, and Jack's 440 below, respectively.

Robert and I each passed the 300 mark in 2015, although Chau has pulled ahead of me quite a bit in subsequent years. And in light of the pipeline of pending patents Jack has, I suspect he'll leave me watching his transistor research taillights, too, in short order.

The other good thing about Jack passing my count will be maintaining grade monotonicity. Instead of Fellow->Sr. PE->Sr. Fellow as we have today with Jack->Vincent->Robert, we'll have Sr. PE->Fellow->Sr. Fellow, where grade level will increase on the Y-axis as patent count increases on the X-axis.

Finally, given that Intel was founded on many of the transistor and integrated circuit accomplishments of folks like Robert Noyce https://en.wikipedia.org/wiki/Robert_Noyce, having Robert and Jack as the lead inventors for the company is a wonderful thing.

So much for random thoughts and numbers around issued US patents on a summer day.....

Let's start out with 'books.'

When supporting the activity https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/How-Secure-Boot-helps-protect-against-bootkits-used-in-malware/post/1337354 and the linked video https://www.youtube.com/watch?v=FqC332VCgYI I was reminded of my many office-mates during the work-from-home, namely

'books.' I thought that the confinement of working from home would give me more of a chance to catch up with my reading backlog, but invariably the work-load seems to have increased with the time saved from having done my commute.

Also, the shelves and my person are much more cluttered and in shambles that a similar view from a couple of years back

I am a bit comforted by this disparity of 'owned' to 'read' books, though, after reading sentiments like Umberto Eco and his anti-library https://www.brainpickings.org/2015/03/24/umberto-eco-antilibrary/

"The library should contain as much of what you do not know".

On that theme of variety, to me it's important to sample the humanities, such as good literature and philosophy, to remind myself what it means to be human, as it is to dive deeply into both my technical domain and the adjacencies. The latter is especially important as innovation often happens at the seams between two domains, and texts that go deep into my domain are often rearview mirror & retrospective, not forward looking. Forward looking includes fusion and leverage of alternate domains into my field. Think some technique of mathematical logic that can be applied to system software, for example.

Another book that has pleased me during this confinement is "Software Engineering at Google"https://abseil.io/resources/swe-book. Although a read the dead tree version, a colleague let me know this week that there is a free PDF download, too. In addition to leveraging many aspects of the wisdom therein for my day job, such as code review practices, I really enjoyed the 3 'always'. Always deciding, always scaling, and always leaving. The first helps but not falling into analysis paralysis and admiring problems too long but instead just 'doing something.' The 2nd I use to ensure that my activities can have the largest leverage & impact. And the final one, 'always leaving,' seemed a bit confusing at first blush. Given the 'great resignation' https://en.wikipedia.org/wiki/Great_Resignation and other perennial wars for talent, this struck me as something corporations wouldn't endorse. In closer reading, though, 'always leaving' really means doing your job in a way that you can 'leave' for a broader role, typically within the same organization. In absence of mentoring folks, building a bench, documenting you work, etc., you are stuck in the same role and cannot leave as you may become a Single Point Of Failure (SPOF). The latter is not good for the business, especially given the 'hit by a bus' risk and other reasons someone might leave. Sometime I see folks 'Always digging in' versus 'leaving' where they relish the guru/goto person status and their singular ability to fulfill a role. That's a corporate anti-pattern IMHO. To me I try to embrace this sentiment of always-leaving through well-commented code, documentation (e.g., specifications, design documents, white papers, papers, books, prezo's,....) and most importantly, interaction with colleagues.

Books are also something of a lifestyle, too. Living in the Seattle area and with the advent of so many online purchasing opportunities, the brick-and-mortar bookstores are becoming rarer. Growing up in Houston I often found refuge in the dusty, disorganized shelf of the local Half-Price Books which was within bicycling distance. Once I could drive, my choices became even broader. After moving to the Pacific Northwest in 1997, my favorite haunt was the Half-Price Books on Roosevelt in the University District in the shadows of UW Seattle. I would often visit that store, both as part of sojourning from the south sound to Seattle for my masters work in the late 90's and as an excuse to go north. The store had the advantage of receiving stock from the local tech worker diaspora and both students and teachers from UW. I miss that haunt https://www.dailyuw.com/opinion/article_33647c22-1a7b-11e7-8490-679e314f85e7.html. Now that my daughter is living on campus at UW, I have a new favorite reason to visit the area, of course.

So with time things change stores close, and other occurs mark signs of 'old age' increasing.

Another aspect of my biography in the first link above also mentions retro computing. I have regrettably accumulated an original IBM portable https://en.wikipedia.org/wiki/IBM_Portable_Personal_Computer, a 21264 Alpha server, an HP dual-socket Itanium, .... and too many more to mention. These computing devices also remind me of the arc of technology. I still recall how I was in awe of companies like DEC in 1988 or so when I was a electrical engineering student at Cornell and many DEC engineers were allowed to take a year off to study for a 'master of engineering' degree at Cornell. I also read about the accomplishments in IEEE journals and even acquired my first IEEE 'student' membership while an undergrad. Below is a status from my present IEE profile history:

Start Date: 01-Nov-1990 | End Date: 31-Dec-1992

Fast forward to the 21st century and paper https://ieeexplore.ieee.org/document/9218694

Date of Conference: 20-24 July 2020

Almost 30 years from 'student member' to having a publication hosted by an IEEE venue. Quite the span of time. Given that span of time, you'd think I would generate the energy to apply for 'senior member' or somesuch, but like my career, advancement in that domain seems sluggish these days.

Speaking of spans of time, I also just qualified for Intel's 'rule of 75'

https://www.intel.com/content/dam/www/program/employee/documents/irmp-serma-spd.pdf

Or one of the benefits for 'retiring.'

So now I'm setting on 30 years of retro computing and a tech career with things like 'retirement' options sitting in my inbox. Quite the passage of time indeed.

Speaking of time, better quit blogging here and get back to work.

I thought about pre-OS networking recently after giving a talk to other engineers about the value of EQ + IQ recently. For the latter, what I called "Technical IQ" in http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html, I use the T-shaped model https://careeredge.bentley.edu/blog/2015/04/21/how-gaining-t-shaped-skills-will-give-you-an-edge/. For this model networking was in the depth or vertical bar of my T since evolving the EFI network stack from a simple legacy PXE & UNDI thunk wrapper in 1999 to the native mode implementation in the early 2000's, certifying a clean-room IPV6 stack, and further into scalable use cases with wireless and HTTP boot a half decade ago. In the late days of 2021 perhaps it's not as prominent in the vertical bar but it's an important capability nevertheless.

As part of this survey, this blog is an elaboration upon some arbitrary points on the timeline of UEFI firmware network boot history, in the spirit of older postings like http://vzimmer.blogspot.com/2013/02/anniversary-daynext-arch-ps-and-some.html. This latter posting mentioned the 1.2 work https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf, including

client authentication w/ EAP https://www.semanticscholar.org/paper/Cloud-Net-Booting-Beyond-BIOS-Using-the-Unified-Zimmer/8f158dd172ca406095d051cc9bb5a7f5cc09435b and the folly of trying to create bespoke authentication methods.

This same work was described in the 2009 https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf paper https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer09.html?view=bibtex in 2009, the same year as Berkeley Cloud paper that it cited https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf. At the time is was becoming increasingly obvious that a HTTP-based boot was necessary. We in fact left provision for the same in https://tools.ietf.org/rfc/rfc5970.txt.

Page 97 of https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf notes the full move to standard network authentication protocols.

Another place I captured some history of pre-OS UEFI networking was in https://github.com/vincentjzimmer/Documents/raw/master/A-Quick-History-of-UEFI-Networking.pdf. This was just a quick background that I ultimately integrated into https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf in 2016. This folds in advances such as UEFI wireless support and HTTP boot that I led through the UEFI Network (UNST) & Security (USST) subteams https://uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf, respectively, in the early portion of that decade. Commercial usage of HTTP boot was described by HP enterprise, too

https://www.uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdf.

Although https://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf updates after wireless UEFI boot, the suggested next paradigm of pre-OS network bootstrap of 'NVME over Fabric UEFI boot' has been evolved in the NVME standards group versus my UNST in UEFI https://linuxplumbersconf.org/event/7/contributions/737/attachments/531/944/LPC_2020_-_NVMe-oF_Boot_from_Ethernet_-_Final.pdf. I discovered that working the standard closer to the subject matter experts is best, just as I created the EFI TCG Protocols http://people.eecs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf in the Trusted Computing Group versus the UEFI Forum.

At other times it is satisfying to see evolution of requirements that support important use cases. There has been a spate of activity in enabling https://csrc.nist.gov/publications/detail/sp/800-193/final over the last several years, including the low level infrastructure code like https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDKII.pdf. The idea therein entails having the platform having some degree of fault tolerance on the system board firmware and device firmware.

Beyond 193, though, there are scenarios where the operating system can become corrupted, such as infamous https://www.tomshardware.com/news/malware-shamoon-virus-security-disttrack,16988.html. There are some early thoughts about options here https://www.it-scc.org/uploads/4/7/2/3/47232717/requirements_for_recoverable_systems.pdf that happen to nicely match some of the OS recovery infrastructure defined in https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf, especially figure 7 of the latter mapped to figure 2 of the former.

which not surprisingly bear resemblance to

During that effort above on OS recovery it was noted that although we defined UEFI network support in the UEFI standard and some infrastructure for the same in https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Supplicant.h, great support for multi device and protocol was available in https://ipxe.org. In fact, ipxe has historically been a favorite of datacenter operators using firmware based networking, including the ipxe scripting https://ipxe.org/scripting. I fact after talking with some hyperscalers in the mid 2000's, I tried to create a 'safe shell' subset to use .nsh in lieu of ipxe scripting for deployment w/ UEFI network stack to provide coequal, and in the limit script-compatible behavior between ipxe and UEFI. This didn't work out for various technical and community reasons.

This usage of ipxe in the pre-OS speaks to the challenge of OS-absent networking. There has always been a complain that UEFI didn't solve one of the fundamental systems problems, namely needing to write drivers twice: once for the boot environment, and once for the OS. Vertically integrated folks like Intel UEFI Apple Macs can have a OS kernel engineer and firmware engineer who is a domain expert do both, but in the horizontal industry where the OS providers and platform provider are different business entities, this is more difficult. And historically the OS folks eschewed using firmware at runtime, even for safe mode, which led to deprecating UNDI at runtime.

In the past some of the DEC Alpha platform manufacturers wrapped Windows NT NDIS drivers in the Arc firmware, but this was only the port level, datagram interface. The higher level networking primitives had to be curated for each domain (pre-OS, OS runtime). Other challenges in pre-OS networking include security - the support of packets on the wire (or air with wireless) are a huge attack surface since the incoming packets are ostensibly attacker-controlled data. The use of hardware VPN's can ameliorate some of this concern for deployments in the traditional enterprise, but the world of borderless/zero trust architectures moots that argument.

One potential approach to more robustness may include using language-based security, such as Rust and implementations such as smol https://github.com/smoltcp-rs/smoltcp? In the early 2000's I explored with Linux kernel EFI maintainer Matt Fleming on some options about encapsulating Linux in the pre-OS for the network stack and then returning to the UEFI environment to boot the downloaded image. There were a lot of intricacies about state of the platform in absence of exit boot services and other blockers that put that exploration on the shelf. At the time there were already a lot of usages of embedding Linux in the flash as the boot environment, but it was a one-way gate from UEFI. UEFI->Linux. Never a UEFI->Linux->UEFI->Final OS.

It is nice to see that latter use-case having been re-invigorated in the last few years with https://www.linuxboot.org/ in the datacenter. Instead of UEFI netboot->Linux or the chain loading of UEFI netboot->ipxe->Linux, you have the platform firmware, UEFI or coreboot or slimboot or....based, directly launch Linux and its integrated networking support from the system board flash.

In addition to the interesting works Trammel Hudson has done in firmware security, I am happy to see his work in this space of using Linux for pre-OS networking https://trmm.net/LinuxBoot_34c3/. This includes a recent path to run interleave UEFI and Linux execution, or the design point Fleming and I explored years ago, viz.,

The other historical irony I have to mention about LinuxBoot and firmware relates to a conversation I had on the showcase floor at the Ubuntu Developer Summit in Oakland, CA 2012. My colleague brought Mark Shuttleworth over to have a conversation, ostensibly about UEFI secure boot and some of the other recent features I had been working on in this space. Shuttleworth nodded his head in response to the overview and then left me with the single question: "Why don't you just use Linux as the firmware to boot the operating system?" Of course supply chain, horizontal industry COTs, .... and the myriad of other social, technical and business reasons from my confirmation bias vantage of working on UEFI and EDKII didn't really empower me to have a quick answer :)

So we mention LinuxBoot above which obviates the need for the UEFI network stack in some use-cases, especially Cloud. That doesn't mean that UEFI networking isn't important. In fact enterprise and client devices still deploy the capability today, and it definitely has challenges, including performance and robustness. On the former, we noted some of the glass jaws on the polled UEFI driver model and its impact on perf in https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf and the associated implementation using LWIP and multiprocessing https://github.com/tianocore/edk2-staging/tree/MpNetworkStack. For security we can go beyond just the forklift upgrade of a Rust port and near-term isolate the network stack drivers in ring 3 or user mode https://github.com/jyao1/SecurityEx/tree/master/UserModePkg or put into a VM https://www.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching-vmm-in-efi-developer-kit-ii-0-819978.pdf. In fact after the 2007 paper laying the ground work for UEFI secure boot in SAM07 https://www.semanticscholar.org/paper/Platform-Trust-Beyond-BIOS-Using-the-Unified-Zimmer/0bd3bdeb6dcadf088137e13c00adc7e4390fa0de was 2008 https://www.semanticscholar.org/paper/System-Isolation-Beyond-BIOS-using-the-Unified-Zimmer/cf0261fe8d8dc078fb389dc04a56188695581949 including VMM and rings for firmware.

Firmware device interrupts http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html, ring isolation, multiprocessing, etc all seem to argue for just diving into a full operating system, but a deft hand can still apply some of these design precepts into pre-OS firmware. Driving change is hard, though. I recall a quote from a colleague about another engineer 'he spent a lot of time working on a problem that engineers (at the company) didn't want solved.' In other words, a good business problem isn't enough. For various historical and / or cultural reasons the existing engineering community may not want to pursue a solution. A mental model I sometimes use for this engineering reluctance is WWI/WWII. Leaders who came up in some technology era understand the guardrails and technologies for success there - mapping to WWI they are great trench builders and trench warfare combatants. And the ultimate example of trench warfare skills was the Maginot line https://en.wikipedia.org/wiki/Maginot_Line.

Technology changes. Say going from mainframe to mini, mini to PC, PC to Cloud/post-PC, anything to mobile, ...... A phase and its successor may represent a different corpus of technology or business constraints. Let's call one of these transitions going from a WWI to WWII based technology environment. When WWII commenced, airplanes just flew over the Maginot line. Just like your real competition is yourself professionally, not others, the way to leverage this insight is to avoid trying to leverage your trench-digging skills when the world war precepts have changed, and more importantly continually evolve skills and practices. As for the sentiment in the quotation above, a technologists should take a constructive approach that includes providing data on the environment change and technical options that can inform the organization of potentially evolve the bench from WWI to WWII class readiness.

OK. Enough on this topic of the past. If there are any more postings in '22 they will catch up to more recent events and commentary in the firmware space.

In the spirit of work anniversary posts, here's the successor to http://vzimmer.blogspot.com/2021/02/24-or-anniversarynext9-and-128-bits.html. This post signals the 25th year of working at Intel and 30 years in the industry.

Since I am so sporadic in blogging, I'll begin with some touches on recent work in the project Universal Scalable Firmware (USF) https://github.com/universalscalablefirmware. I described some of this work at https://talks.osfc.io/osfc2021/talk/HYZL3U/ and it was earlier picked up at https://www.phoronix.com/scan.php?page=news_item&px=Intel-USF-Firmware, too. The effort builds upon earlier work in FSP https://link.springer.com/book/10.1007/978-1-4842-0070-4 https://www.youtube.com/watch?v=uzfiTiP9dEM https://www.phoronix.com/scan.php?page=news_item&px=Intel-Better-FSP-License, including adding more traceability https://uefi.org/sites/default/files/resources/Traceable%20Firmware%20Bill%20of%20Materials%20-%2020211207%20-%20007.pdf. It also builds upon earlier OSFC-described work in https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf and https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf.

As always, the hallway track of the last OSFC was the most interesting. Regrettably with COVID this hallway track was a group chat session. I recall some interesting feedback, including 'binaries foster proprietary software development,''big companies realize they need to be open but the strategy often fails in middle management,' and 'big companies eventually do open source but some of the original drivers within the company get tired and leave.' As always, it's valuable to process all input and realize the lens through which it is delivered.

Beyond the business side, I appreciated the reference to Roscoe's recent OSDI talk https://people.inf.ethz.ch/troscoe/pubs/2021-07-16-OSDIKeyNote-Handout.pdf cited by one of the OSFC attendees in that 'hallway track' chat session. This talk really resonates with me and others working in this space at many levels. It includes how platform orthodoxy to 'just run a Linux OS' dictates platform architecture and the rich set of programmable compute elements and firmware in a modern platform. The latter has not been so visible historically to the broader research community but it has been the vocation of many of us for decades. I welcome the increased focus of academics in this domain since the ratio of security research attack talks to defense and academic research is deafening.

The above talks and research show that a career in the firmware space never ends. It's a journey with many fascinating stops and definitely the need to always learn and evolve. I still recall my first BIOS job in the 90's prior to Intel where one of the senior engineers said 'if you know MS DOS and how to debug a PC/AT BIOS you'll always have a job.' Hmmm.

Fast forward to February 24, 1997 with the bushy-haired, suit-wearing engineer who showed up in DuPont, WA http://vzimmer.blogspot.com/2017/02/this-one-is-for-20-or-anniversarynext5.html.

As I look at the things I've worked on, I am reminded of the quote regarding an ethos of 'missionary versus mercenary' when applied to your career. I know that it is something of a luxury to entertain that dialectic since extreme poverty would most likely preclude making that choice. In fact, I recall my father, who grew up as an orphan, reminding me 'money may not buy happiness, but lack of money can surely buy unhappiness.' As such, I believe there is a balance, and once the basic survival needs are requited, deciding which side of the fence you live on is key. Today's frothy job market and extreme compensation packages brings this dynamic up in stark contrast. But in general an interesting thought about career motivations. I fall on the side of missionary.

I do have to say that this is one of the most exciting times to be in the technology industry. From my early career visiting FTP sites on dialup modems with a 286 to today having multi-core, multi-gigabyte machines and the world-wide-web with its online videos, books, papers, and source repos like Github.

I became excited about Intel in the mid-90's reading about the company in magazines like EETimes and working on Intel technology, like bringing up a BIOS on a 430HX platform. When I was recruited to Intel to lead the 64-bit Merced/Itanium BIOS work, I was part of a 31% growth wave 1996 - 1997 https://www.chiphistory.org/chc_upload/content/pdf/19/1506018723/1506018723.pdf.

Along the way many colleagues have left for other companies, retired or passed away. In addition, my role afforded me the opportunity to work with many parties outside of Intel, whether it be a direct customer, community and government agency. From each I have learned various lessons. These include the perils of arrogance, especially when people confuse correlation versus causation (i.e., something that happened versus their making it happen).

I do recall one director who always seemed interested in the technology. I asked him why he took the management track. He recounted a tale of working as a compiler engineer at Burroughs early in his career and devoting himself to the project. One day an executive came in and cancelled the overall project. At this point the then-junior-software-engineer thought "I want to be the guy on that side of the table." He the then hung up his coding spurs and pursued an MBA. I admired this manage a lot and recall driving to Oregon for his retirement event. After decades at Intel and many projects he had set up a table with a placard in front of his various projects with a quote about his most memory impact. For UEFI I thought the card would say 'changed the ecosystem' but instead it said 'told the team to stop selling.' Less learned - check.

Another memory from that director included transitioning one of our internal product efforts from legacy BIOS to EDK. There was a heated debate in a forum, including a VP telling my boss 'our customers are not asking for this," with my boss replying loudly 'how can you lead on a strategy if you wait for the customer." This is a variant of https://www.businessinsider.com/steve-jobs-quote-misunderstood-katie-dill-2019-4

Some people say give the customers what they want, but that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, 'If I'd ask customers what they wanted, they would've told me a faster horse.' People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.

that I've seen quoted with various degrees of verity.

I've been on this project long enough now, namely joining the EFI team in 1999 and having it re-org'd around me multiply, that I encounter people explaining to me why something I created was done. That's a good thing in my opinion since it shows people are thinking deeply and passionate about the subject.

Speaking of done, I have enjoyed the opportunity to work various endeavors after I was recruited out of Compaq in 1996 and ended up joining the company in February 1997. The path included creating the first 64-bit Itanium BIOS and powering on first workstation. The delay in Merced, and not yet having children, afforded me the opportunity to drive to the University of Washington in Seattle and take courses for my Masters of Science in Computer Science. Toward the end both the birth of my daughter and power-on's made this a tough road to follow. The experience with Itanium afforded my first glimpse into moving 'beyond BIOS', whether it was 64-bit SAL and the PC/AT BIOS atop it for late POST, moving to the workstation effort with the clean-room Kittyhawk code base written in C.

After that I moved to the EFI effort in 1999, helping deliver content from the EFI 1.02, EFI 1.10, EFI 1.20 (never shipped but a subset donated to UEFI 2.0), UEFI 2.0 through UEFI 2.9. EFI was always the higher level pre-OS OS or boot load environment, but other that the plat driver directory, it was decoupled from the underlying platform initialization. To that end, the Kittyhawk effort may have donated some interesting concepts, but the "Tiano" program with with the "Intel Platform Innovation Framework for the Extensible Firmware Interface" (aka. 'the Framework') provided a set of building blocks, including PEI, HOB's, DXE, Data HOB, CSM, SMBUS, HII, SMM, etc.

The Framework specifications informed the creation of the Tiano codebase, which consumed the original EFI sample to become the EFI Developer Kit (EDK). EDK led the charge for the early to late 2000's and was then replaced by the EFI Developer Kit II (EDKII). The latter introduced more modularity via Packaging, PCD's, base libraries, etc.

The EDK and EDKII code bases were posted to sourceforge originally and the latter is now actively maintained on Github. Most of the 10+ Framework specifications (sans data hub and CSM) were donated to the UEFI Forum, along with Framework-related patents, to become the UEFI Platform Initialization (PI) specification. The PI packaging specification was borne of the EDKII work and also donated, as was the UEFI Shell. Ironically the EFI Shell was conjured up in a few days to support the Itanium power-on, but it took on a life of its own thereafter.

Speaking of patents, Intel has afforded me the opportunity to work at various layers of the stack and get exposed to a plurality of problem statements. And it is the problem statements that are key to ideation in my opinion. One good problem can yield a wealth of patents. And the patents of course have to meet at least the criteria of novelty and value to my employer. The latter reminds me of the quote that 'if you are working on something that the business doesn't care it it's called a 'hobby.'' No time or budget for hobby-patents.

So for projects, patents, papers, books, standards .... the most memory aspect has always been the collaborators. Technology comes and goes, but people and relationships are the most important. From working on the original Itanium BIOS and simulation and then hardware, to Tiano first booting on the 815 (writing the C-based PEI core and platform PEIM's), to porting EFI to Intel's XScale in 2001, to porting EDK to x64 via both the 2-headed BIOS and 64-bit DXE, to ...

And on standards, from the Framework specifications (PEI, SMM - and getting an IAA for Tiano in 2004), PI 1.0-1.7, .... Collaborating on NIST 800-147 (and getting an IAA for scaling signed updates in 2012), NIST 800-193 (and today's drive for platform resiliency), Open Compute Project https://cdrdv2.intel.com/v1/dl/getContent/671185, network booting (clean-room network stack, IPV6 certified stack, RFC 5970 https://www.rfc-editor.org/rfc/rfc5970.txt, HTTP & WiFi boot), UEFI secure boot & signed updates, EFI TCG measured boot https://cdrdv2.intel.com/v1/dl/getContent/671466...... I have tried to journal some of these things at https://sites.google.com/site/vincentzimmer/cv over time versus citing the same sources here.

I apologize in advance if the reader has gotten this far. This is the 14th year of posting to this blog site and I suspect this entry may win the prize for being the most incoherent. I guess the 24x7 Work From Home (WFH), or is it 'Living At Work' (LAW), lifestyle is bearing down on me, as is the backlog of time off I've yet to use. At Intel we accrue an 8-week sabbatical every 7 years, or a 4 week one every 4 years. I took my first sabbatical in 2004 with my wife and small daughters, including an Alaska cruise, etc. Fast forward to 2011 and I fell off a ladder 2 days into that sabbatical, leading to 2 surgeries and rehab during those 2 months (although I recall 1-hand typing out my articles for https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf during those final weeks of that sabbatical).. So not so much fun in '11. Fast forward to 2018 eligibility - I continued to delay during the 3 year window, which was then extended to 4 year window, which is now extended to August '22 for expiry. Given the latter extension I am now eligible for both my 8 week and a 4 week. Add that to 4 weeks of potential vacation in '22, and I'm sitting on a potential of 4 mos. time-away. And in tech when is there an amicable time window to jump off this bullet train for a breather.....

Going forward, I see huge opportunities in the firmware space. These include some of the technology aspects of USF that allow for evolving the different layers of the stack at different rates. This includes safer languages and more rigor in testing/validation. https://twitter.com/veorq/status/1496177874264641536?s=20&t=SQKLjCN9DIykwSgU0pK6_Q reminds me of the ever present need. I am intrigued by the work described in https://www.amazon.science/blog/a-gentle-introduction-to-automated-reasoning. As an ironic twist of fate, the mention at the bottom of the page

A fun deep track:
Some algorithms found in the automated theorem provers we use today date as far back as 1959, when Hao Wang used automated reasoning to prove the theorems from Principia Mathematica.

seems invisible on the internet, at least the PDF. Luckily my pack-rat nature for books afforded me an ex-Lib edition of IBM Tech Journal from 1960

I regret that my fellow-travelers in the journey for more formal BIOS evaluation https://www.usenix.org/system/files/conference/woot15/woot15-paper-bazhaniuk.pdf are now retired, off to Eclypsium, or in the case of one of my heroes Mark Tuttle, off to the above listed Amazon Reasoning Group (ARG). I feel like we only scratched the surface in this space. Or maybe just a Quixotic question for a computing science Archimedes "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world."

fin

I was happy to see the public SIMICS announcement https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/The-Public-Release-of-Intel-Simics-and-More/post/1372402, including mention of the UEFI boot based upon the QSP work I got started https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/SimicsOpenBoardPkg. Also a good time to revisit what it will take to get https://ieeexplore.ieee.org/document/9218694 into SIMICS.

The posting also provided details on the SIMICS Device Modeling Language (DML) https://github.com/intel/device-modeling-language. Now that DML is open perhaps I can explore releasing the DML-to-TSL models from Termite2 https://github.com/termite2/Termite described in the https://www.intel.com/content/dam/www/public/us/en/documents/research/2013-vol17-iss-2-intel-technology-journal.pdf article. At the time of the Intel Technical Journal article we were prohibited from releasing the DML, thus hampering having a public demonstration of the full DML + UEFI device specification to working EDKII source code.

I have to admit that opacity of the information wasn't the biggest problem, though. The real issue was in the readability of the machine-generated code.

Similar to issues with 'certified code' like Certikos https://github.com/npe9/certikos. Coq proof to hard-to-read C code. And even if you can read the code, the idea is to do maintenance on the proof and not the auto-generated C code. seL4 tries to do proof on C code which is more aligned with today's development process. And given works like below were published in 1979, it's apparent that these issues are not trivial to solve

Perhaps the same semantic gaps exists with hardware design language innovation. The Scala based Chisel looks promising, but the SiFive folks mentioned in a Seattle training that their cores are optimized Verilog. This is an instance of the broader question of High Level Synthesis (HLS) to get more efficiency. At some point maybe economics will win. Good enough will prevail in the same fashion that we see the prevalence of Python even though it is wildly inefficient relative to C/C++/Rust compiled languages.

Synthesis from specification is definitely at the other extreme of today's copy-paste-modify approach to software development. I recall pushing the min-core, a stripped set of EDKII packages. The subset of sources helped with cognitive complexity but unless delivered alongside some additional business value, such as unit-test coverage, but the effort was deemed worse than existing code since latter had years of evidence-of-use.

I should add copy-paste-modify development (CPMD) acronym to my other sarcastic takes on Test Driven Development (TDD), such as Promotion Driven Development (PDD), Fear Driven Development (FDD), or....

Regarding such development anti-patterns, I still recall a comment about writing firmware in Rust will be 'too hard.' Seems to be a trade-off of difficulty in initial creation of critical code written in an 'easy' language like C and then mitigate the lack of rigor at compile time with field patching & updates. I look forward to when Rust practices like https://highassurance.rs/ can reach the same level of assurance and provability as ADA Spark.

It was with some regret that I learned a colleague I admire is retiring. After our last meeting he shared the following picture from osfc 2018 that he took while we were in Germany.

https://2018.osfc.io/speakers/vincent-zimmer.html with the prezo https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf

Speaking of osfc, my most recent osfc prezo https://talks.osfc.io/osfc2021/talk/HYZL3U/

mentions some upcoming books https://www.amazon.com/Firmware-Development-Specialized-Systemic-Knowledge/dp/1484279735/ and https://www.amazon.com/System-Firmware-Essential-Embedded-Solutions/dp/1484279387

Speaking of books and the arc of history, my co-author on the UEFI Shell and Beyond Bios books Mike Rothman shared w/ me his recent fan-driven wikipedia page https://en.wikipedia.org/wiki/M._A._Rothman. On that page I noticed the assertion "He holds over 1000 patents worldwide." This made me curious about how the page author ascertained that number.

As folks can see from the link, Mike has elected to spend his after-hours on writing sci-fi and fantasy books, whereas my spare hours continue on tech books, patents, etc. Given our split in paths, I was curious how close I was to 1000 given his claim above.

To begin my search, I found the old-ish https://goodip.io/iq/assignee/intel-corp where I note that neither Mike or I are listed. Most of the folks there are microarchitecture and process technology. And given it's an old page, I suspect their #'s are much larger and wouldn't imply Mike or I entering that top 10 international.

For the next examination, from my earlier analysis http://vzimmer.blogspot.com/2021/07/patents-and-co-inventors.html I note that Rothman was in the high 200's on US patent grants (https://en.wikipedia.org/wiki/List_of_prolific_inventors at 284 now).

Given that data, so how does the 1000 number come about?

Perhaps there is some confusion about espacenet, namely the link cited in the above wikipedia page https://worldwide.espacenet.com/searchResults?DB=EPODOC&IN=%22Michael+Rothman%22+or+%22Rothman+Michael%22 which lists 737 results for Mike. Regrettably 737 includes US applications and issued, so it's not so easy to glean international issued/granted from that #.

For example, my variant of above link is https://worldwide.espacenet.com/searchResults?DB=EPODOC&IN=vincent%20zimmer&ST=advanced&compact=false&locale=en_EP and lists 1265 items. I don't believe that's correct for me, either, for global granted patents.

So what is the truth?

I finally did some digging on my list and came up with the following #'s from my granted patents over the past 25+ years -

All patents (US + world) - 1037 as of 4/11/2022.

This means 459 US patents granted and 578 non-US patents granted.

The details of US and non-US grant numbers include:

11,074,085

11,249,748

10,761,951

11,061,692

10,929,146

10,852,988

10,649,918

10,382,489

10,251,060

10,564,986

6,633,964

10,262,140

10,031,993

7,392,371

ZL02825773.1

1485797

1068972

1485797

6,848,046

ZL02809670.3

10296798

1075718

10-0729793

7,260,848

7,103,529

ZL02819232.X

10297273

10-0692346

10,601,955

10,540,193

10,180,800

10,768,863

3382593

602018012850.6

3382593

10,546,156

10,474,473

10,503,523

10,394,295

10,552,613

6,978,018

7,243,353

6,775,728

ZL02822826.X

60217394.9

1449077

7,200,758

ZL200380105401.3

10393456

2410819

244483

4855679

5551130

I277904

7,127,579

7,254,676

ZL200380103263.5

2409747

4220469

I242746

7,143,277

7,543,048

7,974,416

9,026,773

10,275,598

ZL200380104038.3

2411989

2421612

I238357

7,320,052

8,130,960

8,842,837

6,996,641

6,993,608

7,082,523

7,263,605

8,108,665

ZL200380105211.1

10393859

2411498

I237790

7,080,246

7,421,431

7,653,808

7,583,591

7,231,512

7,681,027

7,222,258

7,284,136

7,107,440

7,549,055

8,010,799

8,364,974

9,710,647

7,134,125

7,395,420

8,281,116

7,082,509

7,136,994

7,107,441

7,174,451

7,051,215

ZL200480016970.5

602004041688.6

1634170

I247489

7,934,209

7,318,171

ZL200480005327.2

2414318

1077117

222852

I261748

7,444,667

7,222,339

7,328,340

ZL200480018100.1

7,475,233

ZL03156077.6

7,188,238

7,200,772

7,587,750

7,134,007

ZL200480018034.8

602004042829.9

1636696

4242420

1636696

7,730,205

7,478,141

7,082,527

7,483,974

7,146,512

7,107,388

7,159,105

7,243,167

7,478,176

7,380,136

7,434,231

7,562,230

8,127,150

ZL200480037167.X

121324

I280022

7,299,354

7,370,324

7,162,626

7,275,152

7,165,170

7,181,610

7,539,854

7,194,612

7,174,447

7,751,584

7,127,600

7,206,931

7,185,188

8,001,348

8,161,258

8,583,888

7,930,378

7,222,062

7,143,280

7,174,471

I265405

7,353,339

ZL200480038646.3

I292095

7,207,039

7,448,030

7,162,629

7,496,961

7,334,120

7,120,778

7,321,990

7,185,190

7,302,593

7,281,243

7,263,579

7,984,237

7,350,072

7,203,808

7,398,401

7,318,150

7,552,419

7,234,054

7,363,482

7,853,742

ZL200580013217.5

602005041610.2

1749266

4601665

1749266

7,421,533

7,739,527

7,269,768

7,048,877

7,290,178

7,340,616

7,788,460

7,370,188

7,543,166

8,943,346

7,310,725

7,364,087

7,243,222

7,246,224

7,281,124

7,653,727

ZL200580006193.0

602005047030.1

1727625

4664966

10-0855803

ZL200580006194.5

1728376

4579969

10-0831437

7,117,083

7,426,542

7,406,591

7,310,742

7,290,166

7,698,487

8,082,470

7,594,124

8,225,101

8,751,813

7,558,966

7,430,683

7,757,231

5042848

10-0984203

7,472,208

7,840,736

7,506,149

8,245,019

ZL200580017448.3

602005028329.3

1761837

4774049

7,711,965

9,135,470

9,654,464

9,942,219

ZL200580033440.6

602005047110.3

1805572

I314684

7,826,835

ZL200510132102.X

602005048479.5

1825703

4575958

10-1018213

7,181,293

7,305,544

8,745,364

7,366,891

7,383,450

7,373,551

7,694,298

ZL200580042442.1

4579298

10-0914077

7,281,127

7,752,428

7,660,913

7,409,575

8,862,785

9,891,929

8,286,169

7,451,301

7,581,037

7,293,184

7,278,006

ZL200580044889.2

602005040792.8

1839140

4802197

5167387

10-0907722

1839140

7,434,102

7,673,128

7,412,619

7,543,179

ZL200780009846.X

112007000688

I333144

7,617,400

7,398,382

602006049588.9

1856886

ZL200680005313.X

7,542,467

8,024,477

7,716,464

7,352,621

8,806,224

7,493,460

ZL200680032817.0

602006006846.8

1922617

7,373,537

7,441,112

8,046,576

8,862,862

9,465,623

7,543,287

ZL200680018961.9

4796625

10-0937062

7,734,934

7,580,701

8,032,117

7,870,373

7,774,846

7,516,336

8,195,968

8,595,526

9,158,362

7,478,196

8,327,192

7,647,474

ZL200680035585.4

602006024610.2

1934746

502011902004677

1934746

8,656,487

ZL200680035170.7

7,640,553

7,523,323

8,407,489

8,631,259

ZL200680033757.4

ZL201110308278.1

602006003912.3

1924909

1166389

7,480,791

ZL200680033756.X

7,793,127

7,584,374

7,634,629

ZL200680042498.1

I336039

7,631,206

7,461,299

7,725,747

7,555,641

7,660,977

ZL200710126426.1

10-1048914

7,930,728

7,370,175

7,716,421

I341464

ZL200780020629.0

7,889,685

7,840,398

8,368,711

8,786,622

9,448,828

7,818,558

8,082,431

ZL200710192949.6

5001773

7,886,190

7,685,376

7,721,080

7,406,560

8,266,238

7,765,440

8,510,859

ZL200710153796.4

9,235,707

602007038961.5

1906333

4775744

10-0989977

8,302,082

7,900,058

7,668,945

8,312,509

ZL200710170164.9

602007033774.7

1918815

4793733

5512610

10-0938305

1918815

2906661

2442348

10-0966398

1034453

7,594,077

7,987,458

7,941,624

9,384,039

7,673,126

7,788,475

7,945,841

7,779,244

7,822,960

7,596,714

7,689,817

7,627,718

ZL200710300216.X

8,688,965

ZL200810087275.8

7,987,348

ZL200810100361.8

ZL200810144638.7

8,984,265

ZL201410090626.6

602008052166.4

1975836

9,158,920

ZL200810127383.3

2017765

602008057777.5

2017765

7,747,846

7,761,701

8,452,950

7,890,811

7,882,341

7,818,560

8,645,965

10,585,702

ZL200810190343.3

7,900,033

7,987,349

9,047,491

7,827,371

8,458,726

7,793,090

7,873,846

8,402,262

8,185,886

8,391,913

8,649,818

7,831,858

7,900,084

8,583,908

7,962,738

ZL200810183979.5

5376928

8,839,356

ZL200810182279.4

2065800

602008054660.8

2065800

4896946

5410500

7,917,689

8,522,236

7,802,042

8,001,308

8,214,573

8,327,415

8,539,200

7,779,305

8,516,092

8,635,664

8,103,908

8,549,356

8,499,202

9,047,468

8,161,299

8,527,787

ZL200810188957.8

ZL201210028149.1

5636559

7,984,286

8,127,312

8,321,931

8,078,862

8,356,168

8,255,721

7,865,775

8,561,138

2207122

5350528

10-1208257

8,201,239

8,909,940

8,631,186

8,990,486

602009034009.3

2141625

ZL200810188988.3

2479666

10-1134816

8,910,169

ZL200910246861.7

2169514

602009056487.0

2169514

5532271

10-1114648

8,694,761

8,296,553

ZL200911000115.6

2189901

602009058867.2

2189901

5368947

8,296,528

8,086,839

7,953,916

8,463,972

8,832,454

ZL200910217300.4

2204755

2461264

2204755

2461264

2204755

5198422

10-1410078

10-1556818

8,151,027

602010032793.0

2239662

5497923

8,219,851

8,806,231

ZL201010621015.1

9,489,029

602010004816.0

2367091

5026579

10-1245442

2367091

9,015,268

ZL201110120401.7

5370897

10-1264521

ZL201180047970.1

8,539,245

2011285762

ZL201180048112.9

2601588

5705983

10-1518207

I467383

9,063,836

2011286271

ZL201180036850.1

2598997

5512892

10-1473119

I537967

8,522,066

9,098,300

ZL201110188572.3

5307196

10-1306395

8,312,258

ZL201180045466.8

602011036292.5

2596423

5540155

10-1407835

2596423

I482084

8,429,387

9,015,455

ZL201280037871.X

2729896

602012060184.1

2729896

5767751

10-1626397

9,367,327

I542992

8,370,667

ZL201180062019.3

5705996

10-1524961

I497289

8,499,141

ZL201180047390.2

602011021494.2

2601587

5607250

10-1370176

I521441

8,566,613

ZL201110153786.7

2395449

5301609

10-1312832

2510952

176870

8,479,017

2011271088

ZL201110165535.0

2397959

5394441

10-1276409

8,181,176

ZL201110179065.3

602011024271.7

2397943

5345652

10-1331311

8,739,177

ZL201110165550.5

602011002306.3

2398199

5275407

10-1444984

2398199

8,428,929

8,965,749

ZL201180046973.3

602011021514.0

2622533

5715256

5860504

10-1453266

I530872

8,977,871

ZL201080070815.7

ZL201610451692.0

5701399

10-1510028

8,607,040

2011329330

ZL201180055215.8

2641168

5606633

10-1512252

I524205

8,688,812

2011305211

ZL201180002816.2

5497190

10-1366913

I454924

8,386,618

ZL201180045848.0

2619679

602011059899.6

2619679

5657799

10-1465923

I482091

8,590,040

I499977

I564801

ZL201180075088.8

2761468

I468938

ZL201180075454.X

9,958,926

ZL201180074963.0

I512492

9,298,607

ZL201180075333.5

I566966

9,900,448

ZL201180076030.5

10-1646425

ZL201180076131.2

2798562

I476630

I515602

I599908

9,210,148

9,686,281

ZL201180049417.1

2798559

10-1359841

8,892,858

ZL201180075848.5

2795989

5890037

I477169

9,686,364

ZL201280071805.4

2831792

602012073987.8

2831792

10-1643072

9,251,347

ZL201280072136.2

2831788

5951879

10-1701014

9,507,937

9,262,178

2013215466

ZL201380007287.4

5893173

10-1609385

9,292,463

10,002,002

ZL201280075426.2

8,832,494

9,075,751

ZL201380004524.1

10-1618535

ZL201280075397.X

9,141,802

9,589,138

6096301

10-1775800

9,824,226

10,762,216

9,098,282

9,460,483

6105077

I502541

5,940,587

69838343.5

1038227

73695

ZL201380072535.3

6017706

10-1733903

9,311,177

602013022122.7

2959417

9,323,541

10,205,750

ZL201480008747.X

2973147

602014043689.7

2973147

ZL201380081151.8

10-1891420

9,832,172

ZL201380073058.2

2973139

6050528

10-1759411

9,223,983

9,563,775

2974123

602013061098.3

2974123

9,378,371

9,600,671

ZL201380079814.2

9,495,177

9,880,859

ZL201510093595.4

9,384,352

9,524,219

ZL201380079912.6

9,411,601

9,912,474

ZL201380080001.5

3063620

6272991

10-1861724

9,996,142

ZL201380077715.0

9,286,097

10-1915695

10,310,865

11,068,276

9,626,196

10,228,954

ZL201580009451.4

6316978

10-1891423

ZL201480076013.5

3120238

6466476

10-1920980

10,289,425

10,684,865

9,413,765

9,781,117

ZL201580010585.8

3123337

10-1823888

I556130

10,146,657

ZL201580010934.6

6297715

10-1931007

10,049,216

ZL201580003846.3

10,025,934

10-1802800

I601070

9,645,864

11,182,172

ZL201580003799.2

6152493

10-1826769

10-2219122

9,773,110

10,140,449

9,594,927

10,366,237

ZL201580042636.5

I546699

9,785,801

10,831,934

ZL201580028293.7

10-2244645

I570589

9,703,346

3158452

ZL201480079261.5

3161710

6481900

10-1881788

9,870,475

ZL201480079192.8

3161657

6396502

10-1896373

10,169,047

9,740,492

10,331,453

ZL201680011606.2

3274895

602016058368.2

3274895

9,589,155

ZL201580044960.0

I582637

ZL201580061649.7

3231129

10,389,788

9,817,673

10,592,254

10,185,547

ZL201680030406.1

9,525,675

ZL201580076833.9

10,372,491

9,626,227

10,067,805

ZL201680012778.1

3274827

6689873

10,430,589

ZL201680011476.2

10,496,974

ZL201680009786.0

10,747,884

9,836,307

ZL201680030403.8

3314416

9,612,887

10,445,154

6768710

ZL201580080108.9

10,664,573

10,223,187

9,858,412

ZL201680030338.9

3314444

ZL201580082636.8

9,691,278

9,998,284

10,218,508

9,769,169

10,069,826

10,432,627

9,798,641

ZL201611053849.0

6363153

10,061,424

9,977,682

10,776,524

10,496,388

10,158,671

10,776,283

10,635,607

10,581,815

10,592,670

Issuing bodies/countries beyond US above include Europe, WIPO, Japan, South Korea, China, Malaysia, Germany, India, Taiwan, Netherlands, Ireland, Poland, United Kingdom, Mexico, France, Singapore, Spain, Sweden, Finland, Italy, Australia, Brazil, ...

And another rub in my accounting is that some patents are done w/ McAfee, although the # is small.

Since my global patent isssued # is now greater than 1000, maybe I'll avoid doing this analysis again since I doubt I'll ever bump into another big milestone like 1500 or 2000.

And for Mike's 1000 issued, given I am > 150 ahead of him on US grants and he only has a handful of non-joint filings, I suspect he's not at 1000 global issue yet, especially since I have barely tipped that #. But I don't think I have the energy to dig into Mike's actual #. Maybe Mike's wikipedia fanbois can do that recon. Given this twisted path of analysis, thus the blog title https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics.

fin (97)

This is a quick note on 're-use'. Recall how UEFI was derived from EFI, which in turn started as IBI, as mentioned in in http://vzimmer.blogspot.com/2018/10/ghosts-of.html and various histories of EFI in books http://vzimmer.blogspot.com/2021/01/books-and-computers.html and papers https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.

As a background, the original Intel Boot Initiative had its own filesystem called "IBIFS". It was a simple log-structured filesystem that made for easy parsing. But the challenge with this filesystem was how to provision boot media from other operating systems, such as Windows. In the 1990's MS-FAT was the prevailing filesystem although it was much more complex than IBIFS. The IBI/EFI team was encourage to adopt MS-FAT https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc, along with PE/COFF https://docs.microsoft.com/en-us/windows/win32/debug/pe-format executables, as the filesystem and executable format, respectively. This was supported by having a license to use these specifications for production of EFI firmware.

The other advantage of using MS filesystem included MS providing tools to format, check and provision disks https://www.intel.com/content/www/us/en/download/714351/uefi-shell-disk-utilities.html whose sources were derived from MS Installable Filesystem (IFS) C++ kit provided to OEM's. This was my first dive into C++-on-a-C-framework (i.e., no global constructors, etc).

And PE/COFF allowed for using Visual Studio and commercial linkers. At the time we had less luck in getting PDB format and KD wire protocol made public. We wouldn't open source the EFI Debug support protocol and nub based upon reversing that infrastructure, of course.

Of course using ANSI C with PE/COFF was more advantageous than using non-standard art like the coreboot romcc that proved brittle to maintain long-term, although it was a clever solution prior to the advent of cache-as-ram (CAR) https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf. Prior to CAR we had to perform unnatural acts using MMX registers and other on-processor resources (with the peak weirdness of PEI CIS 0.3 and its register 'call levels') in order to implement pre-permanent memory flows like DRAM initialization in the host firmware.

I was reminded of this logic of re-use based upon a few recent topics, including USF https://github.com/universalscalablefirmware and EDK2 GSoC conversation. On the USF topic, there is a discussion of using a self-describing format like CBOR https://www.rfc-editor.org/rfc/rfc8949.html in lieu of the UEFI HOB's https://universalscalablefirmware.groups.io/g/discussion/files/New%20data%20format%20for%20Universal%20Payload%20Interface.pdf. Even though I helped create HOB's, I am one of the first to support moving to a more standard format, especially given the existence of work like https://github.com/intel/tinycbor. To me this is the same spirit of using known filesystem formats, etc.

When asked about this I often cite the economics of host firmware development. Imagine a 5,000 person host firmware producing community across open source participants, OEM's, ODM's, firmware vendors, first party device creators, etc. Recall the supply chain picture from erstwhile 2015 CanSecWest prezo

As such, compare this to the application and OS producing community that is easily orders of magnitude larger. Given the developer community size disparity it is difficult to justify the R&D and validation expense for bespoke host firmware-only solutions. Given NIH sometimes in engineering communities I also quote "Good artists invent, great artists steal" Picasso https://medium.com/ben-shoemate/what-does-it-mean-good-artists-copy-great-artists-steal-ee8fd85317a0.

And given challenges of HOB's I understand the critique of Terse Executable (TE) during gsoc thread "[edk2-discuss] GSoC Proposala replacement for the TE format (it’s buggy and most platforms mostly abandoned it over various issues)," I'm not sure where he received his telemetry on 'abandoned' for working systems. Scraping FD images from the internet? Similar to some of the weird history on those GSoC threads like "PEI and DXE in 1998" when the latter were created in early 2000's as derivatives of EFI into the earlier boot flow. This TE assertion is close to home given the TE image format signature has 'vz' as opposed to PE/COFF 'mz', as originally described in https://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908

So has the TE image been relevant in the industry? Let's do some rough back-of-the-envelope calculations. To begin, the TE image format is easily over 20 years old. In the spirit of the last blog on statistics I'd sat we started to scale Framework EDKII in 2005

Imagine in the ensuing years it's tough to calculate the number of PC's, servers, and clients that shipped using UEFI PI-based firmware, including #'s like https://www.statista.com/statistics/576151/unit-shipments-pcs-united-states/. For Windows8 UEFI was required so you can argue 100% at that point.

To take a swag lets assume 250 million units / year over the last 17 years, yielding 4.25 billion units. Let's also assume the fabrication of the PEI phase pre-memory uses TE's and that each fv/ibb/fvrecovery has ~ 50 peim's compiled with TE. So that would yield the market has shipped 50 * 4.25 = 212.5 billion TE images into the market. And if platform updated 5 times during life, 1 trillion TE's may have been produced. So even if we go 'Beyond TE', 1T has been a good run. And I look forward to the next wave of firmware technologists' proposals - the critique is a pre-condition to invention/innovation - but the next wave needs to close the loop by proposing, documenting, coding, delivering, validating, and scaling their alternative.

I still recall meeting one of the original developers of MS-FAT in Windows at a driver dev-con in the early 2000's in Redmond. He mentioned that 'writing the code was only 10% of the effort.' The latter class of activities were the remaining 90% for a professional software engineer. Or the old trope 'the last 10% of a project takes 90% of the time.'

Finally, these cardinality of the produced TE image set calculations remind me of a colleague at Cornell during my undergrad. He worked part-time in the astrophysics department, whereas I spent time modeling and mocking up particle beams for a professor who did microwave and plasma research as part of SDI https://en.wikipedia.org/wiki/Strategic_Defense_Initiative. My friend noted that the astrophysics researchers there would reckon calculations plus or minus a couple orders of magnitude. I won't argue host firmware is of the same scale but it does note the challenges in precision in various domains.

Sometimes folks believe in bespoke and not studying the past arc of history in tech. I recommend spending some time on bitsavers.org, for example, to folks. But it reminds me of the advice given to me by a retired manager - "Sometimes you see someone put their hand in the chipper. You can say 'there's a chipper, there's a chipper', but they ignore you. Once they are beyond their elbow you need to jump in, at least." Or the dual of child rearing, which was "Sometimes the young child needs to bump her knees on the coffee table while learning to walk." For those not in the PNW a chipper is https://www.familyhandyman.com/list/best-wood-chippers/.

BTW
I just sampled some of the OCP Security https://www.opencompute.org/wiki/Security tech talks. Work to avoid e-waste such as ownership transfer https://docs.google.com/document/d/1oANhjvv_R7E5n8w1RroN8l8-0jdYlfdQDp_3RqGV66k/edit# for servers presented by Google datacenter engineer nicely complements their work on Chromebooks with their developer mode https://www.chromium.org/chromium-os/chromiumos-design-docs/developer-mode/ and other art to allow for unsupported devices to be over-flashed by community firmware for continued life & usage. Nice to see work to avoid aged hardware from only have a fate of visiting the refuse bin/salvage yard.

It might be a stretch to analogize re-use of ideas in this blog post and re-use of hardware in the circular economy from this OCP talk. The former stands on the shoulders of giants and leverages information ecosystems (knowledge, tools, remediated flaws) whereas the latter leverages extant hardware for appropriate use-cases. But interesting stuff nevertheless.

fin (98)

One of the more satisfying areas in tech I’ve done involved creating a component based firmware model for early, space-constrained firmware execution, namely the Pre-EFI Initialization (PEI) architecture. I created both the specification, design and initial implementation.

The journey to creation of PEI began in the late 1990’s. At that time the Extensible Firmware Interfaced (EFI) specification was defined, but the EFI ‘sample’ code was layered on top of a PC/AT BIOS or other precursor firmware. In 2000 there was a request to have a component-based firmware model for interoperable industry enabling.

To that end, the PEI infrastructure includes a small core that is responsible for memory management, service registration, service discovery, and executable module dispatch. PEI Modules, or “PEIM’s”, can be PE/COFF executables or a subset of the PE/COFF referred to as a “Terse Executable”, or TE Image. The input of the PEI phase entails the machine reset and the output of the phase is a set of usable system memory that can be persist into the operating system runtime, along with the cause of the restart, or ‘boot mode.’

The problem being addressed was to allow for composing executable modules from different business entities, such as the CPU vendor for host CPU initialization, board vendor for platform specific logic, reusable generic infrastructure, and 3rd party silicon providers. These executables could range from a simple platform-specific PEIM that samples a general purpose I/O and publishes a flash map up into a module responsible for link and memory initialization built from 10’s of thousands of lines of ANSI C code. Given that the system on a chip vendor exposing the memory and fabric initialization can be different than the platform vendor, the ability to segregate the logic into separate executable modules was a requirement. Correspondingly, some of the PEIM’s may only be delivered in binary, thus requiring a strong contract between the various units of execution. The latter contract entailed the use of PEIM-to-PEIM interfaces, or sets of interfaces named by a Globally Unique Identifier (GUID). The PEI modules are stored in a container known as a Firmware Volume (FV). Typically a system will have a least two FV’s: one for the PEI Modules and another for the larger UEFI and DXE modules.

Compounding the need for module interoperability, the PEI phase had to eXecute-In-Place (XIP) from a memory-mapped store immediately after the machine reset. During this early phase the main DRAM complex has not been initialized, and the execution path to the SPI NOR-attached storage is typically slow, so the PEI core and modules had to be optimized to minimize both code size and memory usage. Specifically, the memory for this early phase entailed the use of the process Cache As RAM (CAR).

The usage of CAR, both for single and later parallel PEI instances, was another innovation I drove from the PEI definition. This usage of PEI allowed for writing C code for even the earliest flows, especially the notoriously complex DDR initialization sequences. Prior to CAR the original design of PEI entailed an assembly-language, register-based software model with ‘call levels’ mapped to various sets of the CPU register set. We discovered that writing code with these ‘level’s’ instead of common idioms like a call stack was untenable, as was factoring large algorithmic routines in assembly. The latter made writing portable, re-usable code difficult. Also, as IP blocks were shared between different CPU cores, not having re-usable C code compounded the software development costs.

The PEI infrastructure started with the register-based model that was ultimately abandoned and then moved to the CAR-based software model in an Intel-defined capability in 2001, and finally culminated in the UEFI Platform Initialization (PI) specification http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf, volume 1, on http://www.UEFI.org. There is a corresponding open source implementation of the EFI Developer Kit II (EDKII)-based PEI core at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Pei with some sample platform and silicon PEIM’s at https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei. The UEFI Platform Initialization (PI) specific provides guidelines on how the PEI core operates, its core services, the TE definition, and the output state of the PEI phase, or the Hand-off-blocks (HOBs). The latter decouples the PEI core from the later state of platform initialization.

PEI has bindings to several architectures, including Itanium, IA32, x64, 32-bit ARM and Aarch64. Today the ARM licensees and ARM Ltd. for 32-bit and Aarch64 servers and client, AMD client and servers, and all of Intel products provide PEI-based silicon enabling. Given the BSD licensing of the EDKII, commercial BIOS vendors and many OEM’s have their own instance of the PEI core. Silicon providers deliver PEI modules as binaries and/or source as either licensed closed source or open source. Regrettably, most of the critical silicon specific flows for memory initialization are either in a proprietary boot ROM or binary blob, not open source. In order to accommodate the various open source host firmware communities, Intel provides a variant of a PEI Firmware Volume with a set of additional API’s called the Intel Firmware Support Package (FSP) https://www.intel.com/fsp. The latter specification has a set of simple services that allow for coreboot https://www.apress.com/us/book/9781484200711 or EDKII https://www.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-using-the-intel-firmware-support-package-with-the-efi-developer-kit-ii-fsp2-0-820293.pdf to ingest the PEI modules.

Given that Intel uses UEFI PI EDKII based PEI modules to validate and enable its SOC’s, having the same critical code usable by various open or closed source host firmware frameworks, from U-boot to coreboot to UEFI to custom RTOS loading argues for the business value of container strategies like Intel FSP to deliver the PEIM’s.

PEI and the PI specification are really a business-to-business technology, namely silicon to OEM. This is distinct from the UEFI specification which has both business-to-business, Original Equipment Manufacturer (OEM) to independent hardware vendor (IHV) and operating system vendor (OSV), and business-to-consumer, such as OEM to enthusiast or writing UEFI applications.

PEI isn’t universal, though. A native U-Boot SPL or coreboot romstage may not resemble PEI, or the alternate firmware boot flow such as OpenPower and its PEI-equivalent called HostBoot, or the RISC-V Freedom Unleashed’s FSBL. Also, the business-to-business interoperability or richness of PEI are not required for certain classes of platform designs. Given the above caveats, though, I would say PEI has been a success given the mainstream CPU vendor usage, although it isn’t the only way to perform this initialization.

And I remember working on this tech in the early 2000's. A patent attorney helping to draft some of the material said 'no one is patenting this type of material.' Some work like expired https://patents.google.com/patent/US7103529B2/en filed in 2001 cited by https://scholar.google.com/scholar?oi=bibs&hl=en&cites=8788045269349566754&as_sdt=5&as_ylo=2022&as_yhi=2022 for their work on firmware sand boxing in products 20 years later. Perhaps this, and PEI during 2001, can fall under the theme of 'value of working on unpopular things.' Once they become popular, the jfk quote kicks in about 'success has many patents but failure is an orphan.'

I hear other strange history, namely some parties outside of Intel working on EFI in 1997 and 1996 when IBI, the EFI predecessor, didn't commence until 1998. FSP started in 2012, but some folks mention it as being 14 years old.

Helping finish and scale is valuable. No need to claim inventorship/creation. Sometimes tech companies encourage that pernicious behavior as part of the promotion process. This leads to the 'pump and dump' phenomena I mentioned earlier http://vzimmer.blogspot.com/2019/02/tiano-147-and-22-or-anniversarynext7.html. And I'm still amazed by the tech market. From the feast-to-famine on hiring to the interesting organization psychology. For example, reading https://www.warp.dev/blog/problems-with-promotion-oriented-cultures reminds me of my PDD reference in March posting http://vzimmer.blogspot.com/2022/03/ that shared similar sentiment with this May article

The dark side of 'finishing' is the loose ends. mention the capsule/variable tweet w nikolaj and tianocore infosec. https://www.goodreads.com/quotes/276615-another-flaw-in-the-human-character-is-that-everybody-wants, which remind me of https://twitter.com/pietrushnic/status/1514741511203794945 and discussion with https://twitter.com/vincentzimmer/status/1501826510738522113.

Another reminder of finishing was helping stand up the EDKII infosec group https://tianocore.org/security. The journey went from chasing items like https://invisiblethingslab.com/resources/misc09/Quest%20To%20The%20Core%20(public).pdf and its ilk, curating bespoke list at https://edk2-docs.gitbook.io/security-advisory/, including epic fixes like https://edk2-docs.gitbook.io/security-advisory/boot_failure_related_to_uefi_variable_usage#description. Then leveraging the notification mechanism of https://uefi.org/security mantis tickets to until https://tianocore.org/security was ready. Some of the process

was inspired by other open source projects like Xen https://xenproject.org/developers/security-policy/. The latest was ensuring that EDKII could issue its own CVE's as a CNA https://www.ami.com/ami-and-industry-partners-drive-acceptance-of-tianocore-as-cve-numbering-authority-cna-by-the-common-vulnerabilities-and-exposures-cve-program/#:~:text=The%20acceptance%20of%20TianoCore%20as%20a%20CNA%20by%20the%20CVE,%2Frequest_id.html%23cna_participants, including learning how to curate the json for issues and being tested by Mitre prior to achieving this milestone. There are still rough edges to work out, such as commitment from community, tragedy of commons, permissive license where folks can fix and not give back, such as marc jones mentions in http://vzimmer.blogspot.com/2020/12/musings-about-firmware-cultures.html

fin (99)

Resources for starting with host firmware

musings about firmware cultures

Open Source Firmware Conference 2020

operating system vendors and firmware

innovation and invention redux

memories from uw and cornell

Intel and Books

Accessing UEFI UpdateCapsule from the operating system runtime

books and computers

24 or Anniversary.Next^9 and 128 bits

Patents and co-inventors

books & old age

wither network boot?

25 or Anniversary.Next^10 and early '22 rumblings

A fun deep track:

Synthesize it?

1000. Lies, #$(@ lies, and statistics

Re-use - ideas, et al.

And then there were 99

100 posts

PQC

New milestones