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.,
.png)
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.
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
APEI and UEFI
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.
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
.jpg)
.jpg)
.png)
No comments:
Post a Comment