Saturday, February 24, 2024

27 or Anniversary.Next^12, AI, Runtime

Anniversary

True to form, today is my work anniversary. I started Intel on February 24, 1997 This post also builds on my last posting in this vein http://vzimmer.blogspot.com/2023/02/26-or-anniversarynext11-and-wisdom-of.html. At this point I have spent more than half of my life on this planet at this single company.  

Since the last posting I've been back to the office daily, sometimes visiting the Crossroads for lunch, where I had my first sighting of a Cyber Truck.



I'd often work through lunch and eat from the local self-serve facilities but the pickings have been slim. So slim that even a 2-month-expired tuna sandwich was eaten by someone.




 I last took a sabbatical in 2011 where I smashed up my arm on the 2nd day and ended up w/ 2 surgeries. I still recall the one-handed typing away at the ITJ articles https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf that appeared later that year.  Typically sabbaticals expire but with the strangeness of COVID there were extensions that turned into a revised evergreen policy where sabbaticals no longer expire.  Regrettably, though, one stops accruing time after reaching 16 years. Looks like I need to pull the trigger on at least one month in the upcoming year, viz.,

 

Beyond cyber trucks, old sandwiches, and sabbaticals, the last year has seen a lot of energy around AI. Even the University of Washington lecture series has been dominated by this topic. An interesting talk from Meta was included in https://www.ece.uw.edu/news-events/lytle-lecture-series/ with slides https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf and a recording https://www.youtube.com/watch?v=d_bdU3LsLzE. You can catch me at 6:36 on LHS of the screen


It's always interesting to be there in person. One comment that intrigued me was a comment from Yann LeCun about the Metaverse build out and GPU procurement. I cannot recall if it was on-tape or off-the-record so I've avoid going further than that.



This talk was at the Lyceum HUB but all of the other talks were across the street.



Another interesting talk https://www.cs.washington.edu/events/colloquia/details?id=3310 was from Fei-Fei Li of Stanford and ImageNet https://ieeexplore.ieee.org/document/5206848 fame.
This was near the comp sci building

LeCun's and Li's talks were like Taylor-Swift-concert-crowds but for techies. Nice to see these thought leaders share their insights and experience in person. 

Google Waymo was also in the mix with a talk https://tcat.cs.washington.edu/events/taskar-center-memorial-distinguished-lecture/ on the challenges of autonomous driving and AI https://www.youtube.com/watch?v=pK5ChzMsfE0


So let's pivot from AI lectures to a topic closer to home, namely firmware runtime. I chose this topic since one of the most popular posts is on this blog series was UEFI variable runtime http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html. I suspect this stems from the fact that most folks have interactions during life of platform at runtime. In our quest for 0-second boot this makes even more sense. 

Regarding how firmware is exposed to the operating system, and thus ultimately the user, at runtime, there are various modalities. 

These include:

  • Static info tables
    • Advanced Configuration and Power Interface (ACPI)
    • Flattened Device Tree (FDT)
  • Interpreter bytecode
    • ACPI AML interpreter
    • UEFI EBC sandbox
    • x86 VDM for video int10h calls
  • Native code runtime
    • UEFI runtime
    • Power9 OPAL
    • Platform Runtime Mechanism (PRM)
  • Opaque host modes - synchronous and asynchronous activations

    • SMI(SMM)- x64
    • SMC(TrustZone)- ARM
    • Trap(Machine Mode) - RISC-V

These are all for the host firmware, or firmware running on the main application processor/core.

There is also device firmware running in the SOC.

In addition, at the platform level, the host can signal 'non-host' such as an Embedded Controller (EC) on client and Baseboard Management Controller (BMC) on server.

Below shows some of the latter 

 






 from https://link.springer.com/book/10.1007/978-1-4842-7939-7.


A lot of the flows are blended. For example, some of the descriptions of ACPI and SMI for errors described in https://cdrdv2.intel.com/v1/dl/getContent/671067 but the paper is light on ACPI.

Regrettably the collection at https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A is pretty spare on ACPI, too, although https://link.springer.com/book/10.1007/978-1-4842-7974-8 covers construction and design in the case studies.

A curation of ACPI material can be found in the following:


Public documents on ACPI

2022

Intro to ACPI from ACPI spec

https://uefi.org/specs/ACPI/6.5/01_Introduction.html


2019 

ACPI tutorial

https://acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf 


2013

ACPI and UEFI

https://cdrdv2.intel.com/v1/dl/getContent/671067 


ACPI overview https://www.intel.com/content/dam/www/public/us/en/documents/research/2009-vol13-iss-1-intel-technology-journal.pdf


2009

ACPI and SMM

https://link.springer.com/article/10.1007/s11416-009-0138-0 


2006

ACPI attacks

https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf 


2004

ACPI HOWTO

https://tldp.org/HOWTO/pdf/ACPI-HOWTO.pdf


2003

IA64 book, including UEFI and ACPI chapter

https://www.amazon.com/Itanium-Architecture-Programmers-Understanding-Processors/dp/0131013726

 

2001

ACPI Book

https://dl.acm.org/doi/book/10.5555/940719 


1997 

ACPI implementation guide

https://www.baldwin.cx/~phoenix/reference/docs/acpi_impguide.pdf 


1996 for first spec - full history in 
https://en.wikipedia.org/wiki/ACPI 

 
A colleague suggested that I should have spent more time in the books writing about ACPI since he spends his time debugging issues on Windows and can quote many instances of poor or misunderstood ACPI constructions. I also chronicled in the past my exchange https://vzimmer.blogspot.com/2018/ with the Linux kernel leadership on the topic. 

A lot of people grouse about UEFI and ACPI when in fact it isn't the standard they are critiquing but instead the implementation.  Namely, it's often a confusion between interface and implementation. 

For example, on topics like the firmware support package (FSP), I hear complaints. I often offer the following dichotomy there:

    Consumer (caller)

    Interface (specification)

    Producer (implementation)


You can find examples of using FSP (consumer/caller) with EDKII 

Sometimes people grouse about FSP when in fact it's the implementation, not the API. And it has been a long run on FSP. The Intel IOTG folks kicked it off in 2010 and then Jiming and I conspired to have a working group that I've lead/co-lead since 2014 on the same with various other co-leads and collaborators along the way. Some of the outputs of that collaboration that record Maurice, Ravi and Jiming details can be found in the '15 book https://link.springer.com/book/10.1007/978-1-4842-0070-4, too. Maurice is now doing great things in fw at MS and Jiming at AMZN, resp., AFAIK. One of my key contributions in those 2013/2014 days was teasing out the FSP spec which was originally an amalgam of silicon details and API's into a couplet of docs, namely the main interface spec, the FSP EAS, and the respective SOC integration guides, such as can be found today in https://www.intel.com/fsp and in https://www.github.com/intel/FSP, respectively. This allowed for creating class drivers for FSP in the various platform code (e.g., coreboot and EDKII at the time) and abstracting SOC specifics. And I should forget how the decade+ of cross-group collaboration allowed for scaling FSP's from embedded to both mainstream client and servers, as demonstrated by the rich postings on Github. It's not a perfect split between EAS and integration guide, though, but as we've struggled with the 2001 Intel Framework API's and 2006+ UEFI PI spec interfaces, building that 'firmware socket' set of abstractions is tough given the variability of silicon and products over time.

Same with UEFI.  The interface is at https://uefi.org/specifications. Two implementations can be found at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Dxe and https://github.com/u-boot/u-boot/tree/master/lib/efi, respectively. Most folks complain about the EDKII implementation when they invoke 'UEFI is broken', I feel. This reminds me of the sentiment that some person with the handle of 'the_panopticon' mentioned in https://news.ycombinator.com/item?id=39481434

So back to ACPI. The evolution of ACPI in the did-90's predates late 90's EFI. EFI started as a sample and then the Tiano project with EDK and then EDKII subsumed Framework/PI and EFI/UEFI but not the ACPI specification. As such, no modularization of ACPI from the beginning because of Conway's Law (i.e., the folks who owned the UEFI spec and its reference implementation didn't own the ACPI spec for the first nearly 2 decades). In fact a lot of the ACPI table construction on the Intel platforms was derived was the DaVinci/Kittyhawk clean-room C BIOS that pre-dated Tiano in that hotbed of late 90's BIOS innovation called DuPont, WA Intel site. This model of static tables differs from the ARM ecosystem which does dynamic table generation since they started much later on the journey and had a single-team/Linaro view of entering standards-based firmware.

An advantage of dynamic table generation is flexibility but a downside is that it is harder to do attestation since the table fields are not known at build time. Even build time calculations, though, are aggravated by patching. So in practice it is not really done, just like a lot of configuration and PCR[1] content not really be reconstructed for some attestation / verifier flows.

Thinking about these taxonomies of firmware, from SAL+BIOS to Kittyhawk to ACSFL to EDK to EDKII to slim bootloader to coreboot to.... I realize that I might have the dubious honor of having worked on the broadest variety of host firmware at my employer.

Time marches on. In mentioning DaVinci/Kittyhawk workstation BIOS, I realize that my colleagues on that late 90's adventure have largely left the company, from retirement to downsizing to becoming execs at other tech shops (e.g., MS). Similar to the thinning of the crowd of others, such as even my 2015 colleagues from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk who have all left for startups (e.g., Eclypsium) or retirement or other big tech (e.g., Amazon). Well, given those statistics and chaos in tech, this might by be my last Next^* blog. Even if it is, though, I have enjoyed the run and people I've met along the way. Hopefully I have re-payed my employer's and colleagues trust with sufficient contributions these last 27 years.  

Cheers







Monday, January 8, 2024

"Advances in Platform Firmware 'Beyond BIOS'" - 20 years later.....

 A decade has passed since the posting https://vzimmer.blogspot.com/2014/01/advances-in-platform-firmware-beyond.html describing the journey of Tiano https://github.com/vincentjzimmer/Documents/blob/master/it01043.pdf, which at the time was Intel Framework based specifications and the EDK implementation. As such, this month makes 20 years since the article landed on the internet.

The write-up was curiously available in several languages:

    English - https://github.com/vincentjzimmer/Documents/blob/master/it01043_eng.pdf

    Portuguese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_pg.pdf

    Japanese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_j.pdf

    Russian - https://github.com/vincentjzimmer/Documents/blob/master/it01043_ru.pdf

    Spanish - https://github.com/vincentjzimmer/Documents/blob/master/it01043_sp.pdf

    Chinese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_cn.pdf 

Today the EDK https://sourceforge.net/projects/edkit/ has become https://github.com/tianocore/edk2 and the Framework https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html corpus is UEFI PI https://uefi.org/specs/PI/1.8/index.html. The OS-visible interface has gone from EFI 1.10 https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf to UEFI https://uefi.org/specs/UEFI/2.10/, too. 

Given the amount of change over this interval, I always have a tough time refreshing the graphic 


Many interesting twists and turns on this journey that started in the late 90's and still continues as we step into the year 2024.

Saturday, December 16, 2023

Hacking in the southern hemisphere

Last week I had the opportunity to visit https://en.wikipedia.org/wiki/S%C3%A3o_Paulo for the Hackers 2 Hackers Conference https://www.h2hc.com.br/en/


 

I was invited to give a keynote on UEFI security


This is only the 2nd public keynote I have given in my career. The first was back in 2018 https://www.osfc.io/2018/talks/keynote/. The latter treated open source, whereas this one predominately covered security but with a taste of open source weaved in.

I was humbled to be in the presence of so many impactful speakers https://www.h2hc.com.br/en/articles/speaker.html. A taste of other researcher talks can be found in the h2h mention at https://twitter.com/rcvalle/status/1735790682646712505, including the follow-up blog post

 https://rcvalle.com/blog/2023/12/09/llvm-cfi-and-cross-language-llvm-cfi-support-for-rust/.

My topic 


 

visited some familiar themes but also included a snapshot of the latest work in mitigations https://github.com/vincentjzimmer/Documents/blob/master/H2H%20-%20Vincent%20Zimmer%20-%20The%20Story%20of%20UEFI%20(and%20its%20security%20mitigations).pdf.

I was impressed also with the BIOS hacking room where folks like

 


were writing BIOS, debuggers, and other low-level bits from scratch. One of the students brought out  

https://www.degruyter.com/document/doi/10.1515/9781501505690/html?lang=en and inquired about other learning resources. I realized I have been remiss in refreshing pages like http://vzimmer.blogspot.com/2020/12/resources-for-starting-with-host.html.

As always, the 'hallway track' is the most engaging aspect of the conference. Therein I happened to meet some local firmware security engineers


 and signed a copy of the firmware security book https://link.springer.com/book/10.1007/978-1-4842-6106-4 that they were using at the university


too.

The city was an interesting study in contradictions. Immediately in front of the hotel I was treated to the scene

 


 And nearby in one direction



Whereas a short walk in the other direction yielded a modern mall with high-end stores


And of course long lay-overs and flights provide an opportunity to think of some of my favorite philosophers, such as Alan Watts.



Interesting stuff.

 


Thursday, November 30, 2023

i/o, globalization, pqc, ai, oh yes

I talked a bit about the RAID work at Compaq, or the SMART2-SL 'Dazzler' board in my last post http://vzimmer.blogspot.com/2023/10/october-firmware-events.html. Another interesting thing that landed while at CPQ was I2O https://en.wikipedia.org/wiki/I2O, or 'Intelligent Input / Output.' The idea was to bring intelligent offload engines to open platforms. The Wikipedia post has some views of its history. My view was that version 1.0 was challenging in that it asked the host to do the data movement, not the I/O card. If you are offloading the last thing you want to do is encumber the host with 'more work.' We built an adapter card on top of our CPQ RAID controller to provide the I2O hardware interface and then we mapped the commands into our internal command set. Version 2.0 described having the data mover in the I/O device, which made more sense. 

This reminds me of the cycle of technology. Patterns like offloading I/O from the host CPU, from IBM channel processors of old, I2O gestures, Myrinet smart NICs (woohoo - safe code, Modula3, too) https://dl.acm.org/doi/pdf/10.1145/319195.319197, Nitro, DPUs, IPUs,....traversing the 1950's to today.

The post also mentions UDI.  Interesting stuff. Reminds me of the complaint about UEFI that it didn't solve the 2 problems of the BIOS ecosystem - suppliers and having to write a driver 2x - once for pre-OS and again for the OS. UEFI attempted to solve a class of this issue w/ UNDI, both the 'hardware UNDI' and the software UNDI. The former would be architectural hardware like VGA to allow for runtime access. In practice the latter was solved with GOP and the framebuffer at runtime. For I/O this was a mile too far.

Speaking of blogs, I haven't quite figured out the substack phenomena. Is this the new 'blogger'? I created account https://panopticon404.substack.com/ but haven't posted.  Google 'the panopticon' and guess my motivation for that name. 



I really like blogger.  going on 14 years using the service.  I had fear initially that when google bought it they'd kill it, but I suspect it's a low-impact enough service like other freebies, including my homepage https://sites.google.com/site/vincentzimmer/ that it's not worth closing and generating the associated ill will?

Unlike blogging at Intel where 1st party sites like 'uefidk.com' (mentioned 9 times in https://link.springer.com/book/10.1007/978-1-4842-0070-4, sigh) that went away w/o redirecting the content to somewhere like firmware.intel.com, I realize how ephemeral these sites can be.

Speaking of substack, https://www.noahpinion.blog/p/the-next-phase-of-globalization-is had an interesting post around globalization. I still recall how Richard Wirt set up PRC firmware team in '01.  Similar teams in Russia.  He was 'globalization before globalization was cool' IMHO.

I enjoy collaborating w/ colleagues across the globe. The 2020 book w Jiewen Yao in Shanghai, PRC. The SPDM paper https://www.mdpi.com/2410-387X/6/4/48 w/ Jiewen and Krystian in Gdansk, Poland. Two 2022 books w/ Subrata in Bangalore, India. I think I touched on this point of book author geo's in http://vzimmer.blogspot.com/2022/10/a-tale-of-two-books.html

The SDPM talked about post-quantum cryptography (PQC). This is a space getting attention, and pages 23+ of https://uefi.org/sites/default/files/resources/USF_Security_Webinar_Final.pdf talk about work for host firmware, including a proposal for accommodating PQC in UEFI https://bugzilla.tianocore.org/show_bug.cgi?id=4087.  

Describes the proposed mapping.

Provides the deadlines. With some of the challenges in evolving the UEFI CA and Secure boot ecosystem https://uefi.org/sites/default/files/resources/Evolving%20the%20Secure%20Boot%20Ecosystem_Flick%20and%20Sutherland.pdf this will be an interesting journey.

The wave keeps flowing

I argue that the workday is like barbells.  There are a spate of meetings from 6am to 10am PST for Europe, Israel and India.  Then the PRC workday starts at 5pm PST and pick up India workday at 8pm, netting out to a typical day of 6am to 11pm.  

Luckily Saturday no one has a workday afaik.  I recall this theme as a broken record with me given my anecdote on http://vzimmer.blogspot.com/2021/01/books-and-computers.html about the currency trader.

Occasionally I sneak out to Seattle in the PM to catch events. Recently https://tech.cornell.edu/people/greg-morrisett/  was in town to meet with alumni. It was nice to meet the creator of Cyclone & typed assembly. I had to share my tales of woe trying to use Cyclone https://cyclone.thelanguage.org/ in the early days and was happy to see a mainstream memory-safe systems language like Rust appearing on the scene. This tech inspired some interesting designs on my side, including the below that will expire in 2 weeks, viz.,




Greg mentioned the challenges of industry to hire folks for high assurance software work. 

Maybe that problem of moving folks to Rust will be ameliorated by the 'assistant gap' mentioned by IOActive? I dropped in the IOActive event tonight in Bell Town and their CTO talked about "the SDLC process and AI." He mentioned how chess assistants after the Deep Blue event with Karsparov in 1995 had a 10 year run until event an assisted human couldn't beat a machine. He then showed the exponential growth in code writing assistants commencing in 2020 and pondered how much shorter the 'era of assistants' will run for code writers until the day the machine does all of the work and the prevailing 'programming language' becomes English.

As a quite side-bar on AI, I worked my way through https://www.amazon.com/gp/product/0137470355/ over the thanksgiving holiday. I liked the mixture of math and programming, along with the historical arc it described. I was amused by the point that the early deep learning efforts felt compelled to have a mathematical foundation for their work to 'justify it' whereas with the latest efforts like generative AI people haven't expected such pedagogy if things 'work well.' The book reinforced my assertion that learning the basics of math will serve you well as the trends of tech churn. For example, having mastered the basics of linear algebra, eigenvalues, etc as an undergrad decades ago are still relevant in this deep learning work today. The same holds for statistical signal processing, information theory, and signal detection from the electrical engineering corpus. But the deep learning domain is so expansive and fuses art like big data, software systems, computer architecture (e.g., array processing redux). I can now better appreciate the point Mark R. made in 38:4 https://www.youtube.com/watch?v=Wx1WBLdUwtg about using his summer sabbatical to get more experience with these deep learning frameworks.

I'm no "Mark R.", of course, but perhaps an option to use my backlog?


BTW - the joke used to be that AI was 'the technology that didn't work.' Meaning once an AI technique proved feasible in the corpus they were ejected and relabeled as some domain of engineering. The script seems flipped today in that being labeled 'AI' is a compelling argument for the tech, irrespective of its efficacy.

So take the barbell day mentioned above and mix in  return to office (RTO). It's nice to see an office again. Sometimes I tell folks that I like the office since it's sort of like Pavlov's dog, but instead of 'ringing a bell' to get a response the stimulus is 'sitting in a cubicle.' An interesting observation, though, about others around me post-COVID. I'm not sure if folks are used to WFH and speaking into their USB speakers, or if we are just getting older and losing our hearing, but folks nearby in the office are pretty loud on the phone.  Since the bulk of the day is still on the phone for a global team, I'm getting complaints from the folks on the call that my neighbor conversations/background noise is too loud.  

From the file of neighbors in the past, Dupont circa late 90's, I sometimes recall Ken Wiletzki. He retired a week before his 40th bday so could say 'retired in my 30's'. In the following year he'd send pictures of himself mountain biking, etc, but after that he went dark. I guess retirement joy consumed any time of 'sharing retirement' with the folks still in office-land. One interesting tale from Ken is that he claimed that he tried to hire Linus Torvalds, then a computer science student in Finland, to work on his validation team at Intel.  Ken created 'kaos' - Ken's Arbitrary OS - for validation of the hardware devices. Ken claimed that Intel couldn't since Linus was overseas and didn't yet have his masters degree. I'm not so sure of this fact since there is no mention in the 'Just for fun' https://www.amazon.com/Just-Fun-Story-Accidental-Revolutionary/dp/0066620732 bio of Linus. Someone who is mentioned in that book is another Intel colleague H. Peter Anvin who in fact merits 2 appearances - once for getting Linus his first PC, and the second for bringing Linus to the US to work for Transmeta.

Other interesting meetings in the local region include the Rust meetup at the connector building on the MS campus. Nice finally meeting Ben Stoltz of Oxide in person after talking w/ him many a time during his Google Cloud security tenure. I liked when Ben asked one presenter 'what does that mean for a pertrified (or did he say 'prehistoric'?) C programmer.' My people. 


Sunday, October 22, 2023

October firmware events

Apropos of the 25 year anniversary of the first IBI/EFI/UEFI boot services at week ago, as commemorated at the 20 year milestone in https://vzimmer.blogspot.com/2018/10/  

                                                        "Ken Reneris     Oct-14-1998"  



there was a question of the coding standards for UEFI https://twitter.com/bexcran/status/1701071379171619236 recently which made me think of Ken. I mentioned how that since Ken had come over to Intel from the Windows NT team at Microsoft it was natural to adopt the NT coding standard https://computernewb.com/~lily/files/Documents/NTDesignWorkbook/coding.pdf for the original IBI/EFI/UEFI work. This includes the EFI_ERROR macros, inf's, CR macro, TPLs as simplified IRQLs https://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html, etc. This made IBI/EFI/UEFI a sort of a cultural 'Windows BIOS' given that lineage. 

And Ken as the MS HAL owner continually interfaced with the platform. In fact, standards like ACPI pre-dated IBI/EFI/UEFI by starting in the mid-90's. Ken was deep into that work, too, as evidenced by his solo inventor ship of the now-expired S4 resume patent https://patents.google.com/patent/US6209088B1/en

These UEFI technology elements serve a counterpoint with coreboot, which was LinuxBIOS in 99. The latter have technology elements https://www2.cs.arizona.edu/~mccann/cstyle.html, KConfig, etc.  
https://link.springer.com/book/10.1007/978-1-4842-0070-4. So just as we have had parallel growth of Windows and Linux, there have been threads of 'Windows BIOS' (e.g., EDKII UEFI based) and 'LinuxBIOS' (e.g., coreboot and maybe less so u-boot?).

But then again, who uses 'BIOS' https://basicinputoutput.com/2014/08/will-i-be-jailed-for-saying-uefi-bios.html

So the blog title is firmware events. Over the last couple of weeks there was a UEFI plugfest in the Portland area and a Open Compute Project (OCP) event in San Jose. As I drove back from the former, I stopped by a bookstore and saw https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784



on the shelf.

On that same shelf I saw 


and


Though not the immediate book neighbor, the nearby https://www.amazon.com/ARM-Architecture-Reference-Manual-2nd/dp/0201737191 reminded me of Dave Jaggar. Back in the mid-1990's we were development hardware RAID controllers at Compaq and using custom ASICs alongside an AMD 29k RISC CPU. I recall Jaggar from ARM coming to visit and explaining the ARM architecture. Part of the discourse included showing a silicon die with a small portion highlighted for the ARM core itself. It was quite a shock for me to so such small mm-squared for a CPU. My firmware lead (lead == sole design & developer) work on the SMART-2SL 


https://www.amazon.com/Compaq-242777-001-WIDE-SCSI-CONTROLLER-242777001/dp/B0002FDXLQ is but a memory to be rekindled occasionally by seeing aftermarket examples of this device. In addition to being the first device to not have a non-volatile post write cache, this work gave me the opportunity to do some interesting firmware performance innovations with a colleague https://patents.google.com/patent/US6341342B1/en


Speaking of CPQ, it has been a strange migration of companies for me. My original internship was with Texaco, which in turn was purchased by Chevron. Then I did my first full-time firmware development at Daniel Industries, later acquired by Emerson Electric. My first foray into PC BIOS was at Texas Microsystems (TMI) working on industrial computers, which then was acquired by Radisys. Finally, my pre-Intel employer Compaq server group was in turn acquired by Hewlett-Packard, and then split into the enterprise side HPe. Luckily Intel is still Intel.

So speaking of the development event, it spanned 3 days. I presented on the first day (lower left image)



https://uefi.org/sites/default/files/resources/Tuesday_02_Kubacki%20and%20Zimmer_Final.pdf and final



day (rightmost image) https://uefi.org/sites/default/files/resources/Firmware%20Configuration%20%E2%80%93%20Past%2C%20Present%2C%20and%20Future_Zimmer.pdf. The first day of the event included a description of SPDM https://www.dmtf.org/standards/spdm and its support introduced into the UEFI 2.10 specification. SPDM is homed at the DMTF but has associated work-product having in groups like UEFI and the Trusted Computing Group (TCG). 

In the Insyde talk Tim Lewis mentioned the growth of attacks on the UEFI network stack after many years of battering SMM. This reminded me of a recent posting I saw https://www.linaro.org/blog/ledge-blogs-uefi-http-and-https-boot-in-u-boot/ where the U-Boot community discussing using https://savannah.nongnu.org/projects/lwip/ which is a similar approach taken in https://github.com/tianocore/edk2-staging/tree/MpNetworkStack mentioned in https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf. From the days of discussing HTTP booting in 2009 https://dblp.org/rec/conf/csreaSAM/Zimmer09.html?view=bibtex and having the URL boot option mentioned in https://www.rfc-editor.org/rfc/rfc5970.txt has come a long way. Just as EDKII consumes cryptography as a submodule from another community, maybe it's time to do so for the basic networking capabilities.

Given that AWS started in 2006, it may have a bit short-sighted of me to have said "...emergent compute models such as cloud computing." in that SAM 09 paper.


Maybe I was keying off the 09 date of what I thought was the definitive paper on the cloud, viz., https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.

So back to the topic of this blog, namely firmware events. On that topic, the next week came the Open Compute Project (OCP) event in San Jose. I first presented at OCP in 2015 with Mallik Bulusu https://cdrdv2.intel.com/v1/dl/getContent/671185 



and then again in 2016 on firmware updates http://files.opencompute.org/oc/public.php?service=files&t=1f7831234dce58bb875b1b5b24f7154d



This session last week was on the universal payload






I have been engaged on server platforms since I was hired into Intel in February 1997 to lead the IA-64 (Merced, Itanium) firmware. Along the way we devised ways to facilitate ease of firmware development, like multi-socket cache-as-RAM https://patents.google.com/patent/US7254676B2/en 



and similar for IA-32 https://patents.google.com/patent/US8078862B2/en. Palsamy and I also collaborated on UEFI and ACPI for RAS and error support https://cdrdv2.intel.com/v1/dl/getContent/671067


And all of these threads come together in these recent talks. The SPDM prezo mentioned at the top of the posting here entail facing the post-quantum cryptographic migrations like all of the other standards, including UEFI https://uefi.org/, TCG https://trustedcomputinggroup.org/, and others. The proposal for augmenting UEFI is mentioned in https://bugzilla.tianocore.org/show_bug.cgi?id=4087 and some prezos on the topic can be found at https://uefi.org/sites/default/files/resources/Post%20Quantum%20Webinar.pdf and https://uefi.org/sites/default/files/resources/USF_Security_Webinar_Final.pdf. The specific study on SPDM was posted as a pre-print to https://eprint.iacr.org/2022/1049 and then a journal submission in https://www.mdpi.com/2410-387X/6/4/48


Since SPDM has fixed message sizes, the concept of 'chunking' or breaking up the larger payloads demanded by these post-quantum algorithms is a common concern other hardware-based messaging interfaces will face, like the Trusted Computing Group's Trusted Platform Module (TPM). Interestingly this topic of post-quantum impacts on firmware standards that motivated the SPDM paper



 listed above was inspired by the study https://eprint.iacr.org/2021/041 from Cisco.


And during Q/A with the CISA presentation during the UEFI developer event I asked about formal methods for this domain. Since this talk followed the SPDM talk one recommendation was to use formal for the SPDM wire protocol. It turns out the above MDPI SPDM paper is referenced by a few formal studies of SPDM, including https://www.usenix.org/conference/usenixsecurity23/presentation/cremers-spdm and https://ieeexplore.ieee.org/abstract/document/10149352/

And speaking of security and standards, this upcoming week is the TCG members meeting at the Google campus in Kirkland, WA. I am Intel's representative on the Technical Committee, assuming that role after Kirk Brannock retired. 


 

But the TCG is not unfamiliar to me. I have been engaged with TCG https://en.wikipedia.org/wiki/Trusted_Computing_Group even when it was called TCPA, as evidenced by work-product like https://patents.google.com/patent/US7200758B2/en and delivering the Itanium and EFI API and platform specification, respectively.

When reading https://research.tue.nl/en/publications/communication-in-a-world-of-pervasive-surveillance-sources-and-me from the mention of Jacob in https://www-theregister-com.cdn.ampproject.org/c/s/www.theregister.com/AMP/2023/09/19/marvell_disputes_claim_that_cavium/, I hearkened back to my first ToorCamp presentation 


Based upon the slide



and discussion around the TPM, Jacob told me that we should design a TPM so that it could quickly be removed from board and chewed up/swallowed if someone tries to take your computer. Quite the privacy-preserving dietary strategy.

It's interesting to see people in person after the years of COVID seclusion and event cancellation or wholly-virtual events. Just like the psychic shock and fatigue of crowds, continual interaction and noise, it is taking a bit of effort to get re-acclimated. Part of the symptomology is falling behind on blogging, I guess, since I had intended to post this entry on the day of the EFI 25-year anniversary, not a week later. Oh well. Only so many free moments on the weekends these days.