This week I hosted another retirement lunch for an Intel colleague Harry (middle on left-hand-size of the picture below) from the Ridgepointe office, namely the cubicle next to the 2017 denizen described in the http://vzimmer.blogspot.com/2017/10/the-march-of-time.html posting. I caught a picture of a few of the attendees at the nearby buffet,
luckily for all omitting myself from the photo. A couple of years ago there was talk of manic recruiting, folks reveling in their 'fun-employment' between jobs, quiet quitting, etc. Now the word 'layoff' permeates the air, with added 'quiet firing,' and folks taking the opportunity to retire. For retirement and the retiree Harry, he was on my interview team back in October 1996 and I still recall his vivid description of underwater hockey and his forays therein. Since then our paths have crossed often through BIOS, Itanium, EFI, UEFI, EDKII.....
I still remember my first job in the early 90's. I was off-site working with a contractor when at the main campus the layoff message was delivered. When I returned to the office the next day folks had ravaged my cubicle, taking my office supplies, chair, etc. assuming I was part of the RIF. Ah, the cycle of tech.
At the lunch, the fortune cookie I selected seemed appropriate, too, for the eastside tech scene.
Grinding at tech is definitely the mood of the last few decades. Disruptions often make one more thoughtful, though. I am reminded of the quote from Elon Musk that the biggest mistake engineers make is working on the wrong problem, or the image of "Lancelot in Retirement" from Lex Fridman #345.
Speaking of Leahy and the recent progress in RISC-V I was again reminded of the 2016 coreboot conference https://www.youtube.com/playlist?list=PLiWdJ1SEk1_AfMNC6nD_BvUVCIsHq6f0u I mentioned in http://vzimmer.blogspot.com/2016/11/conferences-forums-and-writings.html. Lots of the folks who presented have switched companies, landing at places such as Rivos, Meta, Apple, and Google. But I still giggle when I recall Ron M. mentioning that he had Andrew Waterman https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html speak to the Google executives just to see the latter's expressions when Andrew would drop the F-bomb. Classic tech.
Speaking of Google in PNW and the future of tech, https://www.cs.washington.edu/events/colloquia/details?id=3264 provided some inspiration on the set of open problems to solve
and also offered an oppty to drop in on the new UW CSE building
In the firmware domain there are still interesting problems to solve, including how to better share source code across execution phases. Host firmware is strange, such as PI-based code w/ sec, pei pre mem, pei post mem, dxe pre BdsEntry, dxe post bds (the uefi phase), uefi runtime, smm. And then there are the other platform components like embedded controller (ec), bmc, soc uc's, not to mention other host firmware like slim bootloader, coreboot, u-boot, ....
And to evolve something you need to ship. It was far-sighted on part of Google to use Fuchsia on a class of Nest devices. I recall a lunch w/ MS engineer years about about the Singularity/Midori OS fail. He claimed the focus was wrong, namely not having a memory safe driver model but instead the lack of focus on the application model. Maybe if it shipped (or provided user-land usages or deployed on MS 1st party devices?
And around Seattle I enjoyed reading Welsh's article https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming/fulltext. This work reminded me of item I studied during my late 90's UW masters on Simonyi's intentional programming https://en.wikipedia.org/wiki/Intentional_programming.
I have tried to move some of my public-facing posting from https://twitter.com/vincentzimmer to https://mas.to/@vincentzimmer but I continue to find myself replying on the blue bird. From re-tweeting https://twitter.com/acmeducation/status/1636806692519256064
to answering questions on UEFI firmware, such as making a distinction between interfaces and implementation
https://twitter.com/vincentzimmer/status/1633880381610164224
with a shout-out to the corresponding embedded computing article https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure.
I also dropped into the Dasharo user group and had a chance to talk with Andrew Cooper. He brought up his concern about running UEFI runtime with hardware control-flow enforcement from December 2021 https://osfw.slack.com/archives/CV510QZ0D/p1639105740058800
I let him know that we had implemented this in the UEFI 2.10 specification as part of the UEFI Memory Attributes Table https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table.
The problem statement is described in https://bugzilla.tianocore.org/show_bug.cgi?id=3726
This is another example of using the community to help drive a security feature. The other notable example includes the exchange with Kees Cook on Twitter https://twitter.com/kees_cook/status/1290095780984786952 that led to https://bugzilla.tianocore.org/show_bug.cgi?id=3519 which is now required in https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memory-mitigation-requirements-for-signing/ba-p/3608714, namely the EFI_MEMORY_ATTRIBUTE_PROTOCOL.
Speaking of the UEFI spec, it has been interesting working across different standards bodies, including IETF https://www.rfc-editor.org/rfc/rfc5970.txt to the various UEFI https://uefi.org/specs/UEFI/2.10/ and UEFI Platform Initialization https://uefi.org/specs/PI/1.8/index.html specifications. Each has a different way to share IPR, from IETF's public https://datatracker.ietf.org/ipr/ to the UEFI forum's internal sharing. I still recall working w/ the Intel team to draft
for the PI SMM items. This cites the same SMM patent mentioned in https://www.intel.com/content/dam/develop/public/us/en/documents/a-tour-beyond-bios-launching-standalone-smm-drivers-in-pei-using-the-efi-developer-kit-ii.pdf, viz.,
This work was prior to the standards efforts. And the above document also demonstrated the type of behavior taken post-standards, namely a more public, code-first approach to new work. That document describes what has become the 'stand-alone MM' https://uefi.org/specs/PI/1.8/V4_Overview.html#initializing-mm-standalone-mode-in-sec-phase work in PI 1.8, for example.
Finally, I was hoping to reproduce the stacking image from http://vzimmer.blogspot.com/2021/01/books-and-computers.html for the last couple of Apress books, but I didn't have the energy to hunt all of the books down that have been published since 2006. Instead I opted for the 'COVID Triad', namely the 3 books that appeared between October 2020 and October 2022, viz.
https://link.springer.com/book/10.1007/978-1-4842-7939-7 https://link.springer.com/book/10.1007/978-1-4842-7974-8 https://link.springer.com/book/10.1007/978-1-4842-6106-4
That's about 2000pp that appeared on the market in the span of 2 years. Yikes.
A final curious note that also relates to this blog series is
Someone had posted a link to my BlueHat stream of consciousness blog http://vzimmer.blogspot.com/2023/02/blue-hat-2023-and-uefi-secure-boot.html. I'm glad no one picked up on this since the HN https://news.ycombinator.com/ discussions can get pretty rough.
OK. Enough for Sunday blogging and back to Sunday work.
PS
I was saddened to hear the news of Gordon Moore's passing https://www.moore.org/article-detail?newsUrlName=in-memoriam-gordon-moore-1929-2023. Beyond Moore's Law https://hasler.ece.gatech.edu/Published_papers/Technology_overview/gordon_moore_1965_article.pdf, he provided guidance and wisdom to the industry throughout the years https://www.youtube.com/watch?v=gtcLzokagAw. My favorite image of him has to be the portrait composed of keycaps
along with the painting
from Intel HQ alongside Robert Noyce.
