Deprecation and introduction of interfaces

Specifications may appear to be static codifications set in stone, but they are often evolutionary species. One of the challenges in evolving a specification includes when, if ever, to deprecate content in lieu of new additions. Sometimes technology may fall out of use or be deemed by the market not to be the most viable. Often, though, this class of information is not elided from specifications unless they are hard scientific reasons, like elision of MD5 or SHA1 from specifications 

because of pre-image attacks https://en.wikipedia.org/wiki/Preimage_attack. I recall one person telling me that about 40% of the Wifi specification was relevant; the key was knowing 'which' 40% merited attention.

This blog will talk about a few specifications, such as the UEFI, PI and Intel SDM, that weigh in at several thousands of pages. To be with the UEFI and PI specification, one area that has potential for deprecation is Itanium support. The EDKII upstream has already removed Itanium related code from the various packages. There are vestiges of Itanium in chapter 2 of the UEFI Specification https://uefi.org/specs/UEFI/2.10/02_Overview.html#intelitanium-based-platforms for the calling conventions, though. Similarly, support for the Itanium reset paths https://uefi.org/specs/PI/1.8/V4_MCA_INIT_PMI_Protocol.html# and extended SAL https://uefi.org/specs/PI/1.8/V4_Sal.html services can be found in the PI specification. The latter of which was the EDKII adaptation of calling the Itanium System Abstraction Layer (SAL) (SAL) https://redirect.cs.umbc.edu/portal/help/architecture/24535901.pdf interfaces from a UEFI environment. 

As a quick background, Itanium had a platform scoped SAL and processor scoped Processor Abstraction Layer (PAL) set of firmware layers designed to provide both boot and runtime services. The RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv-non-isa/riscv-sbi-doc is sort of an amalgam of SAL and PAL since it provides both core, SOC and (potential) platform capabilities. SAL is interesting in that unlike UEFI, that goes into a virtual-only calling mode after SetVirtualAddressMap(), the SAL calls could be called in either physical or virtual mode throughout the life of the platform. This posed some challenges for writing UEFI code since position independent code (PIC) options for C compilers haven't been universally supported across all of the EDK toolchains, especially in the early days with Visual Studio, or for IA32 with its inability to read the instruction pointer address as possible in other architectures. For assembly-language Itanium code it was pretty simple to write PIC code. So the Extended SAL (ESAL) of the PI spec and EDKII provided a way to have non-fixed up and fixed up C code that would use a common data area. 

In addition to the SAL support, another fascinating aspect of Itanium was the support for floating point exceptions in the Floating-Point Software Assist (FPSWA) https://redirect.cs.umbc.edu/portal/help/architecture/24541501.pdf driver, as described in https://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143 

This driver was loaded from the EFI System Partition during boot and would provide runtime support for floating point exceptions. Regrettably soft-loading critical flows from disk like the FPSWA have not been pervasive, even in the face of relatively expensive $/byte of semiconductor NOR SPI flash. This stems from the supply chain challenge where the motherboard and fixed disk media may be provisioned, secured, and recovered by alternate parts of the ecosystem, namely OEM/ODM for the board versus OEM/ODM/integrator/VAR/IT for the disk and its bootloader and OS images, respectively.  

Another area that is an interesting artifact from the past is the BIOS interface in the Intel Software Developer Manual https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf. This interface is an Int15h API to manage microcode patches.

Starting in the early 1980s, the PC/AT BIOS exposed services through 16-bit 'int' calls or software traps, which the most famous being Int13h for disk access, Int 10h for video, etc. These API's all have correlatives in UEFI, with Int13h having the equivalent in EFI_BLOCK_IO_PROTOCOL, for example. The Intel Framework Compatibility Support Model (CSM) specification https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-compatibility-support-module-specification-v098.pdf provided a bridge from EFI into BIOS calls in the early days where there were few EFI native drivers, for example. But the CSM support was not introduced into the UEFI PI specification since the idea with PI commencing in 2006 would have UEFI-spec-defined APIs. In fact, Intel declared the PC/AT BIOS interfaces to be end-of-life in 2020 https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020 

and http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf.

That's where the Int15h API mentioned above is interesting. It can either go away as its the only BIOS API in the SDM, or it could be complemented by/replaced with a UEFI equivalent. To that end, the https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf design reads on this capability 

The mapping of the UEFI interfaces to the Int15h included

with the specific capsule itself having the following layout

The generic capsule overview flow is described in the UEFI specification https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#update-capsule 

and other write-ups https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://archive.fosdem.org/2020/schedule/event/firmware_culisfu/attachments/slides/3709/export/events/attachments/firmware_culisfu/slides/3709/FOSDEM_2020_Intel_Capsule_Update.pdf. As the code-base has been re-arranged in the open, the most recent location to find the FMP DXE Microcode Capsule support is https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/IntelSiliconPkg/Feature/Capsule and of course https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. 

This builds upon the generic FMP 

and capsule update flow 

widely deployed today. Maybe avoiding putting something 'post-Int15h' in the SDM is a wise move, though, considering the plurality of interfaces for firmware updates, from https://slimbootloader.github.io/security/firmware-update.html to https://uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf to https://uefi.org/sites/default/files/resources/PRM_Platform_Runtime_Mechanism_1_1_release_candidate.pdf to https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf to.... It's a veritable embarrassment of riches.

modern, red, rust, retire

I have been on the road for a few weeks, but I'm happily back in town for the memorial day weekend. Some of the notable stops on my trek have included a nearby visit to the UEFI Plugfest to talk about how to accelerate pre-OS networking https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf https://www.youtube.com/watch?v=zW89YChcDK4. This included a reference to an open source implementation of the work https://github.com/tianocore/edk2-staging/tree/MpNetworkStack.

In the spirit of open source, my next was still relatively local to Bellingham, WA to deliver a talk at LinuxFest Northwest https://www.linuxfestnorthwest.org/conferences/2019/program/proposals/286

https://youtu.be/b_XGTaMNuPY

https://github.com/vincentjzimmer/Documents/blob/master/linuxfest-nw-talk-april-27-2019.pdf

Great community and interaction from people truly engaged on open source. Also, some interesting sightings on the way out https://twitter.com/vincentzimmer/status/1122303554285215744

After the Saturday Bellingham event I hopped plan Sunday morning to commence a two week trek across various stops in North America

and Taiwan

Upon return from Tw I wandered to southern WA to an open source conference https://www.phoronix.com/scan.php?page=news_item&px=Intel-modernFW-Rust-VMM

where the topic of ModernFW was introduced https://github.com/intel/ModernFW

As part of those discussions on modernizing firmware the coreboot community mentioned
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/DAK4GNYYLVQJVACNBNUWOPVUDLLPAYLJ/ Redleaf https://dl.acm.org/citation.cfm?id=3321449 and an approach to elide C from coreboot with oreboot https://github.com/oreboot/oreboot. The latter mentions a first target of RISC-V. Pretty exciting to see discussions on many fronts, along with code artifacts, to advance the state of the art in host firmware.

On my last leg of the journey in the last week, I visited the Intel Oregon location. This sojourn included my colleague Lee Rosenbaum's retirement lunch.

I enjoyed many interactions with Lee in his 13 years at Intel, including some public artifacts like
 "A Tour Beyond BIOS into UEFI Secure Boot"
https://sourceforge.net/projects/edk2/files/General%20Documentation/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf/download and later work on testing 
https://www.usenix.org/system/files/conference/woot15/woot15-paper-bazhaniuk.pdf

Ironically, of the 5 authors of the WOOT paper, Alex and John are  now at https://eclypsium.com/company/  where they are doing interesting work like https://eclypsium.com/2019/01/26/the-missing-security-primer-for-bare-metal-cloud-services/, Mark https://www.markrtuttle.com/ headed over to Amazon https://www.amazon.com/ where he has done some interesting work like http://www.markrtuttle.com/data/papers/cook-khazem-kroening-tasiran-tautschnig-tuttle-cav2018.pdf),  and of course Lee leaving.  Or as I like to say about retirement, Lee had a sharp enough spoon to tunnel out of the Shawshank https://en.wikipedia.org/wiki/The_Shawshank_Redemption of corporate America. Looks like I'm the last man still with an active Intel address of the original 5 authors.

Beyond the WOOT paper bench clearing out, I was not too surprised that Lee didn't want to retire with the three books https://www.apress.com/gp/book/9781484200711 https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ https://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143

The third one is definitely nostalgic since it has one of the first overviews of EFI in print beyond the de jure specification. It also treats the PAL and SAL firmware architectures, where the latter with its SAL_PROC mapping of the legacy BIOS API's (e.g., SAL_PROC (0x13) to read the disk) pre-dated EFI (e.g., EFI_BLOCK_IO_PROTOCOL). I onboarded with Intel in early 1997 to lead the firmware for the first Itanium platform Merced.

Good stuff.

I mentioned RISC-V in the context of oreboot above. This architecture proposes a lowest software layer called the system binary interface (SBI), essentially the equivalent of the Itanium PAL (which in turn resembled the DEC Alpha PAL code layer a bit). It's fascinating the watch the deliberations around this code, especially as they drive an open source variant https://github.com/riscv/opensbi. The wheel of history continues to turn, and sometimes repeat.

I guess that this type of posting will continue over time, with the maudlin aspects resembling http://vzimmer.blogspot.com/2017/10/ a bit,too. Safe retirement travels to another Lee and enough blogging for the holiday weekend.....

This one is for 20, or Anniversary.Next^5

As I reach my 20 year anniversary with Intel today, I reflect upon advice that resonates with me. I especially like the posting http://perspectives.mvdirona.com/2016/11/advice-to-someone-just-entering-our-industry/, including the admonition to "Play the Long Game."

20 years. And all doing firmware. Several different firmware architectures and many instances of EFI-style firmware (e.g., Release 1-Release 8.1/2/3/4/5/6, Release 9 "aka EDKII").....

Hopefully this won't encourage me to abuse logical fallacies like argument from authority, saying 'In my 20 years at Intel we.....' Instead you're only as good as the last game you've played, not your record of games.

Or having a Whiggish view of tech history. Instead it's more Kolmogorov probability that monotonically increasing (or decreasing) progress and determinism.

Speaking of history, my original badge from February 24, 1997 can be found below, with the drop-e logo and, gasp, a suit and tie.

And now

Ah, the thick head of hair that I had in the 90's. And my Harry Potter glasses. I recall visiting Shanghai and Suzhou in '01. In the latter city the locals pointed at me in those crazy glasses and a scratch on my forehead from my two year old daughter (that resembled the lightning bolt), reinforcing the Potter doppelganger experience. Pre-SARs in Shanghai, so it was still possible to eat snake, drunken shrimp, and dining colleague from the south China province whose restaurant jaunt truly lived up to the saying "... the Chinese eat anything with four legs except a table, and anything that flies that isn't an airplane..." http://simonlesser.blogspot.com/2009/06/food.html.

So my journey at Intel started in 1996 after contact from an Intel recruiter while I lived in Houston,TX. He exhorted me to join Intel, especially given the 'imminent' Merced CPU development. I interviewed in Hillsboro, OR in October 1996 and was told that I could go to Oregon for IA32 Xeon, or DuPont, WA for IA-64 Merced. Having grown up in Houston, Texas and not realizing that the Pacific Northwest even existed prior to this conversation, I naturally chose DuPont in order to be part of the 64-bit revolution.

Fast forward to February 1997. My wife and I moved to Olympia, WA. Given some of the, er, delay in Merced, I had the opportunity to pick up a Masters at the University of Washington

and at the same time work on developing getting our Itanium firmware ready. This included working on the System Abstraction Layer (SAL) http://www.intel.com/content/www/us/en/processors/itanium/itanium-system-abstraction-layer-specification.html with my BIOS hero/guru Sham D. in Hillsboro, along with Mani and Suresh in Santa Clara. The original boot flow entailed SAL-A for memory initialization, SAL-B for platform initialization and the "SAL_PROC" for the OS-visible API's to enable boot-loaders. The loader API into the firmware was a direct mapping of the PC/AT BIOS calls, with examples including instances like SAL_PROC 0x13 having a similar command set to int13h https://en.wikipedia.org/wiki/BIOS_interrupt_call.

As an arbitrary pedantic sidebar, you definitely see a pattern in firmware for 'phases' that typically include 'turn on memory,' 'turn on platform', and 'provide the boot loader environment.' Itanium had SAL-A, SAL-B, EFI. UEFI PI has SEC, PEI, DXE, BDS/TSL/UEFI API's. coreboot has bootblock, rom stage, ram stage, payload (including Seabios or UEFI or Depthcharge or ...). Power8 has hostboot, skiboot, and Petitboot (or EDKII UEFI). The workstation BIOS for IA-32 below had VM0, VM1, VM2, Furball. PC/AT BIOS has bootblock, POST, BIOS runtime. You see a pattern here?

Writing SAL_PROC code was pretty exciting. It could be invoked in virtual or physical mode. With hand-crafted Itanium assembly it was pretty reasonable to write position independent code (PIC) and use the GP register to discern where to find global data. But in moving to C, writing portable C code to abstract the SAL services was quite a feat. This is distinct from the UEFI runtime where were are callable in 1:1 mapping and then non-1:1 after the invocation of the SetVirtualAddress call by the OS kernel.

Regarding gaps with SAL_PROC as a boot firmware interface, as chronicled in page 8 of http://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf, Intel created the Intel Boot Initiative (IBI) as a C-callable alternative. The original IBI specification looked a lot like ARC http://www.netbsd.org/docs/Hardware/Machines/ARC/riscspec.pdf. Ken R., a recent join to Intel from an MS (where he had a lot of DNA for ACPI), helped turn IBI into what we know as EFI 1.02, namely evolving IBI to have discoverable interfaces like protocols (think COM IUnknown::QueryInterface) and Task Priority Levels (think NT IRQLs), and of course the Camelcase coding style and use of CONTAINING_RECORD macro for information hiding of private data in our public protocol interface C structures. Many thanks to Ken.

Building out EFI was definitely evolutionary. It started from the 'top down' with EFI acting as that final phase/payload in the first instances with alternative platform initialization instances underneath. This view even informed the thema of 'booting from the top down' that informed how we sequenced the chapters in the 2006 Beyond BIOS book, for example. The initial usage of EFI was the 'sample implementation' built on top of the reference SAL code and a PC/AT BIOS invoked by the EFI 'thunk' drivers.

As we moved into the 2000's, the Intel Framework Specifications were defined in order to replace the SAL for Itanium and PC/AT BIOS for Itanium and IA-32, respectively. We internally referred to things like SAL + BIOS + EFI Sample as a "Franken-BIOS." The associated code base moved from the EFI Sample to the EFI Developer Kit, or EDKI, to distinguish it from the EDKII done in the later 2000's. This internal code-base was called 'Tiano', thus the name of community sites like http://www.tianocore.org.  Someone said the name came from the sailor with Columbus who first noticed America, but the only citation I could find publicly is the "Taino" tribe with whom Columbus engaged.

As a funny sidebar, I do recall the meeting where someone found "Tiano Island" http://pf.geoview.info/tiano,4033365 on the web. At the time it cost some number of millions of dollars. The original director of our team, numbering just a few engineers in the room, said 'let's each pool a couple percent of our stock options and buy the island.' I guess Stu had a much more significant equity position than I did, as a lowly grade 7 engineer.

In late 90's at DuPont, SAL and EFI sample were not the only code base activities. While in DuPont the erstwhile workstation group also created a clean-room replacement for the early boot flow. This started on IA32 and the OS interface was the PC/AT BIOS. For this effort we didn't have an image loader and instead just used non-1:1 GDT settings in order to run the protected mode code. For booting the protected mode code provisioned the 16-bit BIOS blob with information like the disk parameters, etc, so that the 16-bit code was just the 'runtime interface.' The 16-bit BIOS blob was called the 'furball' since we hoped to 'cough it up' once the industry had transitioned into a modern bootload erenvironment, such as EFI.

I still recall colleagues in the traditional business units yelling 'you'll never pass WHQL' with the above solution, but it did work. In fact, the work informed the subsequent interfaces and development with the Intel Framework Compatibility Support Module http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-compatibility-support-module-specification-v096.html.

We then ported the workstation code to boot the first Itanium workstation. I left that effort and joined the full EFI effort afterward. I recall the specific event which precipitated the decision. I was chatting with Sham and the workstation BIOS lead in the latter's cube. The lead said 'Now that we have our BIOS in modular code code "Plug-In Modules" (PIM's) we can tackle the option ROM problem. I thought to myself that just refactoring code into separate entities isn't the challenge in moving from PC/AT 16-bit option ROM's into a native format, it's all about the 'interfaces, namely how would a 'new' option ROM snap into a modern firmware infrastructure. IBI (now called EFI) was on that path to a solution, whereas a chunk of 'yet another codebase with PIM's' wasn't. Thus I was off to chatting with my friend Andrew, then lunch with Mark D, and onto the EFI quest in 1999. Quite the firmware long-game.

Next we're of finishing the first EFI, going from IBI to EFI .98 to EFI 1.02.

Next we're off on a cross-divisional team to create the '20 year BIOS replacement' called Tiano and the Intel Framework Specifications are born.

Next we solve the option ROM and driver problem with EFI 1.10.  Along the way between 1.10 and UEFI 2.0 we incubate a lot of future technology with the never release 'EFI 1.20' work.

Next Andrew Fish and I ported EDK to Intel 64. And I had fun with a port to XScale back in 2001. I have always enjoyed firmware bring-up on new CPU's.

Fast forward to 2005. The EFI specification became the UEFI 2.0 specification, and many of the Intel Framework Specifications became the UEFI Platform Initialization specification. Wrote the first EFI interface and platform spec for TPM measured boot https://github.com/vincentjzimmer/Documents/blob/master/EFIS004Fall06.pdf.

Fast forward to the 2010's.  More open source. More device types. More CPU ports. Continue to evolve network booting, such as IPV6 https://tools.ietf.org/rfc/rfc5970.txt and HTTP https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf. Good stuff. Helped deliver UEFI Secure Boot https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Networking-and-Pre-OS-Security.pdf.

In parallel, I often had side firmware engagements, including a fun tour of duty helping our the solid state disk (SSD) team on firmware.

I still believe in better living through tools, too, whether they have landed in the community http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf, almost made it https://github.com/vincentjzimmer/Documents/blob/master/Vij_KRHZRWL_13.pdf https://github.com/termite2/Termite, or are in incubation https://www.usenix.org/system/files/conference/woot15/woot15-paper-bazhaniuk.pdf.

Fast forward to 2017. Year 20. It's still a lot of fun solving crossword puzzles with hardware and firmware.

During my time at Intel I've also appreciated the wisdom of others, whether through the mentoring of direct interaction or the written word. For the latter I heartily recommend keeping the following close at hand.

So am I done this morning? Let's do a final rewind to February 1992 when I jumped into industry in Houston. First I wrote firmware for embedded systems attached to natural gas pipelines http://www.emerson.com/resource/blob/133882/bb9c3232256dfab98cc6a20a27d43c1f/document-3-9000-309-data.pdf - sensors, serial protocols with radio interfaces to SCADA host, control algorithms, I2c pluggable expansion cards, loaders in microcontroller mask ROM's, porting a lot of evil assembly to C code...  fun stuff. The flow computer/Remote Telemetry Unit (RTU) work was an instance of the Internet of Things before the IOT was invented. Then on to industrial PC BIOS and management controller firmware. Then on to hardware RAID controllers and server BIOS. And then Intel in February 1997. 5 years of excitement in Houston prior to my Intel journey.

So I guess that sums out to 25. Now I feel tired. Time to stop blogging and playing the rewinding history game. Here's looking to the next 25.

Cheers.