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.

books & old age

Let's start out with 'books.'  

When supporting the activity https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/How-Secure-Boot-helps-protect-against-bootkits-used-in-malware/post/1337354 and the linked video https://www.youtube.com/watch?v=FqC332VCgYI I was reminded of my many office-mates during the work-from-home, namely

 

'books.'  I thought that the confinement of working from home would give me more of a chance to catch up with my reading backlog, but invariably the work-load seems to have increased with the time saved from having done my commute.  

Also, the shelves and my person are much more cluttered and in shambles that a similar view from a couple of years back 

(versus today)

I am a bit comforted by this disparity of 'owned' to 'read' books, though, after reading sentiments like Umberto Eco and his anti-library https://www.brainpickings.org/2015/03/24/umberto-eco-antilibrary/

"The library should contain as much of what you do not know".  

On that theme of variety, to me it's important to sample the humanities, such as good literature and philosophy, to remind myself what it means to be human, as it is to dive deeply into both my technical domain and the adjacencies. The latter is especially important as innovation often happens at the seams between two domains, and texts that go deep into my domain are often rearview mirror & retrospective, not forward looking. Forward looking includes fusion and leverage of alternate domains into my field.  Think some technique of mathematical logic that can be applied to system software, for example.

Another book that has pleased me during this confinement is "Software Engineering at Google" https://abseil.io/resources/swe-book. Although a read the dead tree version, a colleague let me know this week that there is a free PDF download, too. In addition to leveraging many aspects of the wisdom therein for my day job, such as code review practices, I really enjoyed the 3 'always'.  Always deciding, always scaling, and always leaving. The first helps but not falling into analysis paralysis and admiring problems too long but instead just 'doing something.' The 2nd I use to ensure that my activities can have the largest leverage & impact. And the final one, 'always leaving,' seemed a bit confusing at first blush. Given the 'great resignation' https://en.wikipedia.org/wiki/Great_Resignation and other perennial wars for talent, this struck me as something corporations wouldn't endorse. In closer reading, though, 'always leaving' really means doing your job in a way that you can 'leave' for a broader role, typically within the same organization. In absence of mentoring folks, building a bench, documenting you work, etc., you are stuck in the same role and cannot leave as you may become a Single Point Of Failure (SPOF). The latter is not good for the business, especially given the 'hit by a bus' risk and other reasons someone might leave. Sometime I see folks 'Always digging in' versus 'leaving' where they relish the guru/goto person status and their singular ability to fulfill a role. That's a corporate anti-pattern IMHO. To me I try to embrace this sentiment of always-leaving through well-commented code, documentation (e.g., specifications, design documents, white papers, papers, books, prezo's,....) and most importantly, interaction with colleagues. 

Books are also something of a lifestyle, too. Living in the Seattle area and with the advent of so many online purchasing opportunities, the brick-and-mortar bookstores are becoming rarer. Growing up in Houston I often found refuge in the dusty, disorganized shelf of the local Half-Price Books which was within bicycling distance. Once I could drive, my choices became even broader. After moving to the Pacific Northwest in 1997, my favorite haunt was the Half-Price Books on Roosevelt in the University District in the shadows of UW Seattle. I would often visit that store, both as part of sojourning from the south sound to Seattle for my masters work in the late 90's and as an excuse to go north. The store had the advantage of receiving stock from the local tech worker diaspora and both students and teachers from UW. I miss that haunt https://www.dailyuw.com/opinion/article_33647c22-1a7b-11e7-8490-679e314f85e7.html. Now that my daughter is living on campus at UW, I have a new favorite reason to visit the area, of course. 

So with time things change stores close, and other occurs mark signs of 'old age' increasing.

Another aspect of my biography in the first link above also mentions retro computing. I have regrettably accumulated an original IBM portable https://en.wikipedia.org/wiki/IBM_Portable_Personal_Computer, a 21264 Alpha server, an HP dual-socket Itanium, .... and too many more to mention. These computing devices also remind me of the arc of technology. I still recall how I was in awe of companies like DEC in 1988 or so when I was a electrical engineering student at Cornell and many DEC engineers were allowed to take a year off to study for a 'master of engineering' degree at Cornell. I also read about the accomplishments in IEEE journals and even acquired my first IEEE 'student' membership while an undergrad.  Below is a status from my present IEE profile history:

Start Date: 01-Nov-1990 | End Date: 31-Dec-1992 Fast forward to the 21st century and paper https://ieeexplore.ieee.org/document/9218694    Date of Conference: 20-24 July 2020 Almost 30 years from 'student member' to having a publication hosted by an IEEE venue.  Quite the span of time. Given that span of time, you'd think I would generate the energy to apply for 'senior member' or somesuch, but like my career, advancement in that domain seems sluggish these days. Speaking of spans of time, I also just qualified for Intel's 'rule of 75' https://www.intel.com/content/dam/www/program/employee/documents/irmp-serma-spd.pdf  Or one of the benefits for 'retiring.'   So now I'm setting on 30 years of retro computing and a tech career with things like 'retirement' options sitting in my inbox.  Quite the passage of time indeed. Speaking of time, better quit blogging here and get back to work.