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.

 

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. 

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.

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.