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

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.  

to

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

wither network boot?

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. In 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 patch 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. 

books & old age

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 

(versus today)

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.

Patents and co-inventors

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 on my latest issued patent "Static and dynamic device profile reputation using cloud-based machine learning" 11,049,039 along 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 2014, 

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

24 or Anniversary.Next^9 and 128 bits

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

books and computers

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-Implementing-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.

in its many translations:  English, Chinese, Portuguese, Japanese, Spanish, and Russian.

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