Continued march of time

This week I hosted another retirement lunch for an Intel colleague Harry (middle on left-hand-size of the picture below) from the Ridgepointe office, namely the cubicle next to the 2017 denizen described in the http://vzimmer.blogspot.com/2017/10/the-march-of-time.html posting. I caught a picture of a few of the attendees at the nearby buffet, 

luckily for all omitting myself from the photo. A couple of years ago there was talk of manic recruiting, folks reveling in their 'fun-employment' between jobs, quiet quitting, etc.  Now the word 'layoff' permeates the air, with added 'quiet firing,' and folks taking the opportunity to retire. For retirement and the retiree Harry, he was on my interview team back in October 1996 and I still recall his vivid description of underwater hockey and his forays therein. Since then our paths have crossed often through BIOS, Itanium, EFI, UEFI, EDKII..... 

I still remember my first job in the early 90's. I was off-site working with a contractor when at the main campus the layoff message was delivered. When I returned to the office the next day folks had ravaged my cubicle, taking my office supplies, chair, etc. assuming I was part of the RIF. Ah, the cycle of tech.

At the lunch, the fortune cookie I selected seemed appropriate, too, for the eastside tech scene.

Grinding at tech is definitely the mood of the last few decades. Disruptions often make one more thoughtful, though. I am reminded of the quote from Elon Musk that the biggest mistake engineers make is working on the wrong problem, or the image of "Lancelot in Retirement" from Lex Fridman #345. 

Speaking of Leahy and the recent progress in RISC-V I was again reminded of the 2016 coreboot conference https://www.youtube.com/playlist?list=PLiWdJ1SEk1_AfMNC6nD_BvUVCIsHq6f0u I mentioned in http://vzimmer.blogspot.com/2016/11/conferences-forums-and-writings.html. Lots of the folks who presented have switched companies, landing at places such as Rivos, Meta, Apple, and Google. But I still giggle when I recall Ron M. mentioning that he had Andrew Waterman https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1.html speak to the Google executives just to see the latter's expressions when Andrew would drop the F-bomb. Classic tech.

Speaking of Google in PNW and the future of tech, https://www.cs.washington.edu/events/colloquia/details?id=3264 provided some inspiration on the set of open problems to solve

and also offered an oppty to drop in on the new UW CSE building

In the firmware domain there are still interesting problems to solve, including how to better share source code across execution phases. Host firmware is strange, such as PI-based code w/ sec, pei pre mem, pei post mem, dxe pre BdsEntry, dxe post bds (the uefi phase), uefi runtime, smm. And then there are the other platform components like embedded controller (ec), bmc, soc uc's, not to mention other host firmware like slim bootloader, coreboot, u-boot, ....

And to evolve something you need to ship. It was far-sighted on part of Google to use Fuchsia on a class of Nest devices. I recall a lunch w/ MS engineer years about about the Singularity/Midori  OS fail. He claimed the focus was wrong, namely not having a memory safe driver model but instead the lack of focus on the application model. Maybe if it shipped (or provided user-land usages or deployed on MS 1st party devices?

And around Seattle I enjoyed reading Welsh's article https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming/fulltext. This work reminded me of item I studied during my late 90's UW masters on Simonyi's intentional programming https://en.wikipedia.org/wiki/Intentional_programming.

I have tried to move some of my public-facing posting from https://twitter.com/vincentzimmer to https://mas.to/@vincentzimmer but I continue to find myself replying on the blue bird. From re-tweeting https://twitter.com/acmeducation/status/1636806692519256064 

to answering questions on UEFI firmware, such as making a distinction between interfaces and implementation https://twitter.com/vincentzimmer/status/1633880381610164224

along with not being an apologist for either, with critique of the former https://twitter.com/vincentzimmer/status/1633890390041587712

And finally I reinforced Matthew Garret on his defense of some of the UEFI security features https://twitter.com/mjg59/status/1637661444270587906

with a shout-out to the corresponding embedded computing article https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure.

I also dropped into the Dasharo user group and had a chance to talk with Andrew Cooper. He brought up his concern about running UEFI runtime with hardware control-flow enforcement from December 2021 https://osfw.slack.com/archives/CV510QZ0D/p1639105740058800

I let him know that we had implemented this in the UEFI 2.10 specification as part of the UEFI Memory Attributes Table https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table. 

The problem statement is described in https://bugzilla.tianocore.org/show_bug.cgi?id=3726

This is another example of using the community to help drive a security feature. The other notable example includes the exchange with Kees Cook on Twitter https://twitter.com/kees_cook/status/1290095780984786952 that led to https://bugzilla.tianocore.org/show_bug.cgi?id=3519 which is now required in https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memory-mitigation-requirements-for-signing/ba-p/3608714, namely the EFI_MEMORY_ATTRIBUTE_PROTOCOL.

Speaking of the UEFI spec, it has been interesting working across different standards bodies, including IETF https://www.rfc-editor.org/rfc/rfc5970.txt to the various UEFI https://uefi.org/specs/UEFI/2.10/ and UEFI Platform Initialization https://uefi.org/specs/PI/1.8/index.html specifications. Each has a different way to share IPR, from IETF's public https://datatracker.ietf.org/ipr/ to the UEFI forum's internal sharing. I still recall working w/ the Intel team to draft 

                                

for the PI SMM items. This cites the same SMM patent mentioned in https://www.intel.com/content/dam/develop/public/us/en/documents/a-tour-beyond-bios-launching-standalone-smm-drivers-in-pei-using-the-efi-developer-kit-ii.pdf, viz.,

This work was prior to the standards efforts. And the above document also demonstrated the type of behavior taken post-standards, namely a more public, code-first approach to new work. That document describes what has become the 'stand-alone MM' https://uefi.org/specs/PI/1.8/V4_Overview.html#initializing-mm-standalone-mode-in-sec-phase work in PI 1.8, for example.

Finally, I was hoping to reproduce the stacking image from http://vzimmer.blogspot.com/2021/01/books-and-computers.html for the last couple of Apress books, but I didn't have the energy to hunt all of the books down that have been published since 2006. Instead I opted for the 'COVID Triad', namely the 3 books that appeared between October 2020 and October 2022, viz.

https://link.springer.com/book/10.1007/978-1-4842-7939-7 https://link.springer.com/book/10.1007/978-1-4842-7974-8 https://link.springer.com/book/10.1007/978-1-4842-6106-4

That's about 2000pp that appeared on the market in the span of 2 years. Yikes.

A final curious note that also relates to this blog series is 

Someone had posted a link to my BlueHat stream of consciousness blog http://vzimmer.blogspot.com/2023/02/blue-hat-2023-and-uefi-secure-boot.html. I'm glad no one picked up on this since the HN https://news.ycombinator.com/ discussions can get pretty rough.

OK. Enough for Sunday blogging and back to Sunday work.

PS
I was saddened to hear the news of Gordon Moore's passing https://www.moore.org/article-detail?newsUrlName=in-memoriam-gordon-moore-1929-2023. Beyond Moore's Law https://hasler.ece.gatech.edu/Published_papers/Technology_overview/gordon_moore_1965_article.pdf, he provided guidance and wisdom to the industry throughout the years https://www.youtube.com/watch?v=gtcLzokagAw. My favorite image of him has to be the portrait composed of keycaps 

along with the painting

from Intel HQ alongside Robert Noyce.

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.