Saturday, March 30, 2024

A legend passes

Sad to see the news about Ross Anderson passing 

Like many I was inspired and informed by his various editions of the "Security Engineering" book I also explored the domain via papers like that I referenced in I also cull wisdom from papers like since having worked on the boundary of software and hardware for so long, sometimes errant hardware or firmware is truly an embodiment of 'Satan's Computer.'

My small interaction with Prof Anderson was during the writing of


 My co-author and I reached out to see if Anderson would write a forward, with the below response

Luckily we did get a very insightful write-up

from Leendert Van Doorn

This was an ironic pairing in retrospect seeing Anderson's critiques of Trusted Computing and Leendert's contemporary contributions to that domain, respectively. Having these titans both critique and build a domain, like TCPA (now TCG Trusted Platforms Modules, represent a healthy aspect of technology evolution in my view. Differing views make any technology stronger, versus groupthink & homogeneity of thought.

 Sad times for the security community, though, with the loss of a legend.

Sunday, March 24, 2024

Sneers, CNAs, licenses, and fuzzing

Let's start off with something I occasionally see in industry, namely 'the grand sneer' mentioned in I sometimes see the 'sneering' if often a sign of youth or narrow experience or not exploring outside of your domain or 

The more you know often leads to greater humility borne of realizing how much knowledge there is in the world that you don't know.

Another interesting posting of late was the fact that the Linux kernel is now a CNA I noted that there are similar challenges in other open source infrastructure like in

Another posting in that thread clicked into the SBOM topic with an advocacy for the VEX format. Some work in this space can be found in, too.

So a lot of these thoughts are borne of experience. Amazon has a famous quote that goes something like "there is no compression algorithm for experience," but I'd have to say things are getting pretty good with LLM's. In fact I am glad that my longer form works were published prior to chatGPT.  Maybe the world of text will be bifurcated into BG and PG - "Before GPT" and "After GPT."

I don't subscribe to the dystopian 'paperclip' style apocalypse of AI but I do admire the foundations upon which these large foundation models are built, namely the sum of human knowledge, or the internet. From the hockey-puck style growth of the net in '97 from the Metacrawler era to today's corpus of information on the web, it's truly staggering.

Some examples of oopsies around folks leveraging chatGPT a little too much include and

Speaking of experience, Subrata made a nice posting

namely the "FSP Customization - Remove non-mandatory components in the Intel FSP" for the Open Source Firmware Foundation (OSFC) Byte talks - volume 1, March 8, 2024 The video is now posted at This builds on work trying to help the various communities In the past, we responded to the concerns about FSP licensing described in 

It's hard to 'sneer' when the community is seeing problem statements not necessarily experience in your own environment or workflow. 

Sometimes folks don't sneer but ignore. For example the use of SIMICs for fuzzing firmware mentioned in regrettably didn't cite in their blog I ordinarily wouldn't call folks out if it weren't for the fact that in an internal presentation of their work I mentioned the preceding development on UEFI SIMICS fuzzing and the ensuing paper to the TSFFS folks, with a response from the TSFFS lead that "Oh yes, we leveraged that work.  We were disappointed that you published first so that we couldn't." So at least not a sneer :)  

On a more positive note, the team did some great evolution, including extending 'beyond BIOS' use-case, getting it open source, and finally, against many odds within large companies enamored of Python et al these days, evolving the feature to use the Rust language. 

And additional props go out to my former software division that delivered TSFF to the open source for their work in evolving HBFA with their project. They did a nice job on ack'ing the earlier work, too

Although a lot of the constituent elements like are in the open, I wasn't able to get the symbolic execution work described in across the open source finish line. The lure of retirement, Amazon, and Eclypsium ended up disbanding that team over time and no new team emerged from the ashes to carry it forward. 

Saturday, February 24, 2024

27 or Anniversary.Next^12, AI, Runtime


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 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 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 with slides and a recording 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 was from Fei-Fei Li of Stanford and ImageNet 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 on the challenges of autonomous driving and AI

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



A lot of the flows are blended. For example, some of the descriptions of ACPI and SMI for errors described in but the paper is light on ACPI.

Regrettably the collection at is pretty spare on ACPI, too, although covers construction and design in the case studies.

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

Public documents on ACPI


Intro to ACPI from ACPI spec


ACPI tutorial 



ACPI overview




ACPI attacks 




IA64 book, including UEFI and ACPI chapter



ACPI Book 


ACPI implementation guide 

1996 for first spec - full history in 

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 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, 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 and in, 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 Two implementations can be found at and, 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

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


Monday, January 8, 2024

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

 A decade has passed since the posting describing the journey of Tiano, 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 -

    Portuguese -

    Japanese -

    Russian -

    Spanish -

    Chinese - 

Today the EDK has become and the Framework corpus is UEFI PI The OS-visible interface has gone from EFI 1.10 to UEFI, 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 for the Hackers 2 Hackers Conference


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 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 A taste of other researcher talks can be found in the h2h mention at, including the follow-up blog post

My topic 


visited some familiar themes but also included a snapshot of the latest work in mitigations

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 and inquired about other learning resources. I realized I have been remiss in refreshing pages like

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 that they were using at the university


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 Another interesting thing that landed while at CPQ was 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), 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 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 that it's not worth closing and generating the associated ill will?

Unlike blogging at Intel where 1st party sites like '' (mentioned 9 times in, sigh) that went away w/o redirecting the content to somewhere like, I realize how ephemeral these sites can be.

Speaking of substack, 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 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

The SDPM talked about post-quantum cryptography (PQC). This is a space getting attention, and pages 23+ of talk about work for host firmware, including a proposal for accommodating PQC in UEFI  

Describes the proposed mapping.

Provides the deadlines. With some of the challenges in evolving the UEFI CA and Secure boot ecosystem 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 about the currency trader.

Occasionally I sneak out to Seattle in the PM to catch events. Recently  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 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 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 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' 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  

                                                        "Ken Reneris     Oct-14-1998"  

there was a question of the coding standards for UEFI 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 for the original IBI/EFI/UEFI work. This includes the EFI_ERROR macros, inf's, CR macro, TPLs as simplified IRQLs, 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

These UEFI technology elements serve a counterpoint with coreboot, which was LinuxBIOS in 99. The latter have technology elements, KConfig, etc. 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'

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

on the shelf.

On that same shelf I saw 


Though not the immediate book neighbor, the nearby 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 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

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) and final

day (rightmost image) The first day of the event included a description of 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 where the U-Boot community discussing using which is a similar approach taken in mentioned in From the days of discussing HTTP booting in 2009 and having the URL boot option mentioned in 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.,

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 

and then again in 2016 on firmware updates

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 

and similar for IA-32 Palsamy and I also collaborated on UEFI and ACPI for RAS and error support

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, TCG, and others. The proposal for augmenting UEFI is mentioned in and some prezos on the topic can be found at and The specific study on SPDM was posted as a pre-print to and then a journal submission in

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

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 even when it was called TCPA, as evidenced by work-product like and delivering the Itanium and EFI API and platform specification, respectively.

When reading from the mention of Jacob in, 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.