Sunday, October 14, 2018

Ghosts of....

Ghosts of GUID's past. This post, like, many of my recent ones, walks backward in time. Recent events usually stir these memories. If you're not such a fan old these mutterings, I'd pass on this mid-month posting.

To begin, I couldn't help but remember

https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf during the F-Secure talk at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference recently.


That MEMORY_ONLY_RESET_CONTROL_GUID was GuidGen.exe'd https://blogs.msdn.microsoft.com/syedab/2010/05/09/generate-guid-using-guidgen-exe/ from my erstwhile cubicle in DuPont, WA http://vzimmer.blogspot.com/2018/07/the-march-of-time.html. I guess that I can now say 'buried' (thanks Fish for the latest pic) former campus.
This, along with other buried piles of GUIDs in the EDK code, the UEFI specification, and the PI specification http://uefi.org/specifications emanated from that dank DuPont corner cubicle. I've seen prezo's like this Bluehat one commencing in 2007 with Heasman's UEFI Black Hat talk through a decade of folks searching for GUID's in binaries and mentioning them in prezos and papers.

At the beginning of the hardware track a researcher came up to me and asked "Are you Vincent Zimmer? You're famous, man." I replied, "Er, 'famous', or 'infamous', given the queued up talks." He replied, "Nah, famous." That was nice.

Speaking of ghosts of technology past and true rock stars, people have been remarking this year that UEFI is a '20 year old technology.' I was curious about the precision of those statements, so I looked into an early Intel Boot Initiative (IBI) https://www.afterdawn.com/glossary/term.cfm/intel_boot_initiative tree. IBI was the original name of EFI. I found the following. 

/*++

Copyright (c) 1998  Intel Corporation

Module Name:

    ibiapi.h

Abstract:

    Global IBI runtime & boot service interfaces


Author:

    Ken Reneris     Oct-14-1998

Revision History

--*/

//
// IBI Memory
//

typedef
IBI_STATUS
(IBIAPI *IBI_ALLOCATE_PAGES) (
    IN IBI_ALLOCATE_TYPE            Type,
    IN IBI_MEMORY_TYPE              MemoryType,
    IN UINTN                        NoPages,
    OUT IBI_PHYSICAL_ADDRESS        *Memory
    );

typedef
IBI_STATUS
(IBIAPI *IBI_FREE_PAGES) (
    IN IBI_PHYSICAL_ADDRESS         Memory,
    IN UINTN                        NoPages
    );

typedef
IBI_STATUS
(IBIAPI *IBI_GET_MEMORY_MAP) (
    IN OUT UINTN                    *MemoryMapSize,
    IN OUT IBI_MEMORY_DESCRIPTOR    *MemoryMap,
    OUT UINTN                       *MapKey
    );

typedef
IBI_STATUS
(IBIAPI *IBI_ALLOCATE_POOL) (
    IN IBI_MEMORY_TYPE              PoolType,
    IN UINTN                        Size,
    OUT VOID                        **Buffer
    );

typedef
IBI_STATUS
(IBIAPI *IBI_FREE_POOL) (
    IN VOID                         *Buffer
    );

//
// IBI Events
//

typedef enum {
    EVT_NORMAL,
    EVT_TIMER,
    EVT_MAX_TYPE
} IBI_EVENT_TYPE;

typedef
VOID
(IBIAPI *IBI_EVENT_NOTIFY) (
    IN IBI_EVENT                Event,
    IN VOID                     *Context
    );

typedef
IBI_STATUS
(IBIAPI *IBI_CREATE_EVENT) (
    IN IBI_EVENT_TYPE           Type,
    IN IBI_TPL                  Tpl,
    IN IBI_EVENT_NOTIFY         NotifyFunction,
    IN VOID                     *NotifyContext,
    OUT IBI_EVENT               *Event
    );

typedef enum {
    TimerCancel,
    TimerPeriodic,
    TimerRelative
} IBI_TIMER_DELAY;

typedef
IBI_STATUS
(IBIAPI *IBI_SET_TIMER) (
    IN IBI_EVENT                Event,
    IN IBI_TIMER_DELAY          Type,
    IN UINT64                   TriggerTime
    );

typedef
IBI_STATUS
(IBIAPI *IBI_SIGNAL_EVENT) (
    IN IBI_EVENT                Event
    );

typedef
IBI_STATUS
(IBIAPI *IBI_CLOSE_EVENT) (
    IN IBI_EVENT                Event
    );


//
// Task priority level
//

#define TPL_NORMAL         4
#define TPL_CALLBACK       8
#define TPL_NOTIFY        16 
#define TPL_HIGH_LEVEL    31 

typedef
IBI_TPL
(IBIAPI *IBI_RAISE_TPL) (
    IN IBI_TPL      NewTpl
    );

typedef
VOID
(IBIAPI *IBI_RESTORE_TPL) (
    IN IBI_TPL      NewTpl
    );


//
// IBI platform varibles
//

#define IBI_GLOBAL_VARIABLE     \
    { 0x8BE4DF61, 0x93CA, 0x11d2, 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C }

// Variable attributes
#define IBI_VARIABLE_NON_VOLATILE           0x00000001
#define IBI_VARIABLE_BOOTSERVICE_ACCESS     0x00000002
#define IBI_VARIABLE_RUNTIME_ACCESS         0x00000004


typedef
IBI_STATUS
(IBIAPI *IBI_GET_VARIABLE) (
    IN CHAR16                       *VariableName,
    IN IBI_GUID                     *VendorGuid,
    OUT UINT32                      *Attributes OPTIONAL,
    IN OUT UINTN                    *DataSize,
    OUT VOID                        *Data
    );

typedef
IBI_STATUS
(IBIAPI *IBI_GET_NEXT_VARIABLE_NAME) (
    IN OUT UINTN                    *VariableNameSize,
    IN OUT CHAR16                   *VariableName,
    IN OUT IBI_GUID                 *VendorGuid
    );


typedef
IBI_STATUS
(IBIAPI *IBI_SET_VARIABLE) (
    IN CHAR16                       *VariableName,
    IN IBI_GUID                     *VendorGuid,
    IN UINT32                       Attributes,
    IN UINTN                        DataSize,
    IN VOID                         *Data
    );

...

It looks like today is makes one milestone of 20 years if you use source artifacts as a sign post. You'll notice the code below matches chapter 7 of http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf pretty closely, too (i.e., replace 'IBI' with 'EFI'). The code author is the same Ken Reneris mentioned in the Beyond BIOS https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 acknowledgement, too.

Although there's no explicit mention of IBI in the UEFI specification, it still lingers in

#define EFI_SYSTEM_TABLE_SIGNATURE 0x5453595320494249

or

'IBI SYST'.



Moving on from Bluehat and IBI, I am surprised by the feedback around Linus T's behavior https://www.zdnet.com/article/linus-torvalds-and-linux-code-of-conduct-myths/.

I recall one event (maybe the 2015 OSTS mentioned in http://vzimmer.blogspot.com/2015/05/ocp-csw-and-new-specifications.html) when I was introduced to Linus as a 'UEFI guy, so tell him what you don't like.'  Linus said 'That UEFI runtime is really screwed up.' I replied 'I agree, especially services like SetVirtualAddress that are not idempotent, so they break things like kexec where the latter kernel cannot re-invoke the service.' He looked at me and said 'Hmmm, but I like the UEFI Shell for debugging.' I responded 'It's OK, I guess.'  At this point the Linux die-hard who had initiated the interaction was fuming and shouted 'But Linus, what about ACPI?' Linus then looked at us both and said 'But wasn't ACPI screwed up before EFI and UEFI?'  Good times.

My philosophy on getting strident feedback from open source leaders, whether Linus, Minnich, or the spectrum in-between on the net, is to not take it person 'how' the message is delivered, but 'why.' I use the analogy of the bazooka.  Don't cavil about the calibre of weapon, but try to figure out why it's aimed at me. Often it's because the party delivering the message is passionate about a legitimate concern, and my job entails trying to understand and make progress against 'fixing' the concern, if possible.

Final thoughts are on grabbing the free Friday sessions as CppCon in Bellevue. I was impressed with the wisdom behind
As recently as a day ago I had to remind someone that adding new behavior to a 20 year API without changing software visible version indicia, such as version field or GUID of the API, was a doomed path. They replied 'but everyone builds with the latest code.' To which I responded 'that makes sense within one company, but the point of standardized API's is interoperability, and for the latter you cannot dictate the provenance or age of the caller.'

Speaking of Bellevue and the Pacific Northwest, I'll leave with a couple of shots from http://www.issaquahchamber.com/salmondays. Namely a 'before'




and 'after'
of the salmon, culminating in a non-seafood Dick's run that evening
Ah, Seattle.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Wednesday, September 26, 2018

East, and further east

Since I last blogged the Open Compute Project Open System workstream https://www.opencompute.org/files/2018OCP-OSF-OpenEDKII-Workstream.pdf has continued to evolve https://docs.google.com/document/d/1DWFdPrZlifSxznirN4r5QemmBEi6-1Fpfy0lac77arQ/edit. Part of the feedback from that community helped inform the decision to liberalize the Intel FSP license, too https://www.phoronix.com/scan.php?page=news_item&px=Intel-Better-FSP-License. A theme here includes trying to ease system development.

A lot of those efforts were driven out of the Seattle area, but I made my first sojourn east to https://www.platformsecuritysummit.com/ for https://www.platformsecuritysummit.com/2018/speaker/zimmer/. I followed the Trammell Hudson's presentation, which is always tough given his presentation prowess. This reminded me of the time when the Toorcamp organizer put my EFI defense talk immediately after Dan Griffin's EFI attack talk. In the end I got to know Dan and appreciated his offensive work since great offense inspires more strident defense.

The platform security summit was a great opportunity to engage with companies concerned about the transparency of open platforms, system assurance, and firmware. There has been a lot of discussion about moving to RUST https://www.rust-lang.org/en-US/, including the sentiment from Ron Minnich about today's proliferation of ring 0 C code "Too much writing of code, too little thought about not writing code, and it's all too easy nowadays just to barf out a couple KLOCs without thinking things through."  I'm especially interest in the potential ability to do verification actions, such as http://plv.mpi-sws.org/rustbelt/.

I was pondering that while traveling back from DC when I bumped into David Aucsmith
Aucsmith https://www.root9b.com/leadership/david-aucsmith/ while awaiting a return flight to Seattle. Dave provided me the insight the use Ceremonies https://eprint.iacr.org/2007/399.pdf as a model for system provisioning back at CanSecWest in 2015 in addition to the legendary contributions he made at Intel. I asked Dave what he though of language based security, such as RUST, and he simply replied to me, "If this is such as consideration, why haven't you been coding in Ada https://en.wikipedia.org/wiki/Ada_(programming_language)?" coreboot even has a Ada runtime https://github.com/coreboot/coreboot/tree/master/src/lib/gnat and I don't see much community support, so maybe Dave is on to something.....

After returning to Seattle, I steeled myself for the 'further east' journey, namely visiting Erlangen, Germany for https://osfc.io/. I am honored to have been invited to deliver the keynote https://osfc.io/talks/keynote for this multi-firmware community event. What a passage of time since it makes 15 years since my first Intel Developer Forum solo talk https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. Fast forward and I get to make a solo keynote.

Ironically, my keynote preceded Trammell's security keynote and he amazing slip-streamed my image into slide 10 of his deck https://osfc.io/uploads/talk/paper/2/OSFC_Security_Keynote.pdf


I tried not to 'preach' about firmware, especially since the event was held in a Church.


I also had the opportunity to provide security overviews w/ Maggie for the security hack-a-thon at the event.


I was definitely among my firmware brethren, of which I was reminded with pages like 'booting is hard.' Yes, it is.

Here's a shot of the event location from the outside.


I mentioned the Intel Firmware Support Package (FSP) in the event. That evening event a Swiss engineer answer my query about what I was eating with "It's like an FSP. We know what's on the outside,



but often not what's on the inside."

Nice. Firmware humor on top of the technical conversation and information exchange flow. Speaking of flow, I was reminded of the importance to share knowledge when an engineer early in his career asked for a signature of https://www.apress.com/us/book/9781484200711

Since last blogging I'm happy to have also participated in documenting more of the Intel platform behaviors, albeit the small core SOC https://firmware.intel.com/sites/default/files/uefi_firmware_enabling_guide_for_the_intel_atom_processor_e3900_series.pdf, too. To me it's another tactic on how to scale knowledge and empower communities.

Finally, I'm glad to be back in the Pacific Northwest this week. Today and tomorrow I'm at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference which is a short walk from the Intel office. And no presenter-angst.


So no multi-hour flights, security lines, or strange hotel rooms


If you're around Blue Hat and catch this blog, say hello.


© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 


Monday, July 2, 2018

The march of time

Driving home from Intel Hillsboro Friday night I took a small detour through DuPont, WA. Typically night fall precludes seeing the old campus, but given the summertime extended days, I took a chance.

The campus sign is still there



but as noted in the blog post http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html
we were moved from the campus to further north in WA a few years back. Afterward Intel sold the campus to another company.

DuPont Building 2, or "DP-2," the specific building shown in the above posting



has become




recently.

Little profundity found in the erstwhile company sign or the visitor parking sign compared to  https://www.poetryfoundation.org/poems/46565/ozymandias, but seeing my original Intel campus building disappear nevertheless saddened me.

The march of time.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Friday, June 22, 2018

system firmware past / present / future



From the evening event at the living history museum https://livingcomputers.org/
for UW alumni https://www.cs.washington.edu/ I snapped a few photos.

Beginning with a working Xerox Alto



and continuing into a product category that never failed to intrigue me, namely the mainframes and mini's.

Especially after re-reading https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977

From the Xerox device
I possibly found a use for http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf

that was defined so many years ago.

Continuing on the big iron is the CDC 6500

with its space age looking terminal

and culminating with the famous IBM 360 where instruction set compatibility was pioneered.

As part of Paul Allen endowing the computer science department we also received commemorative diplomas.  Pretty cool.


From admiring the history of computing in the SODO district of Seattle, I spent a few days in the humid suburbs of Washington DC as the platform security summit https://www.platformsecuritysummit.com/. Many exciting presentations from across the industry. I was invited to speak about openness and server firmware with the following presentation
https://github.com/vincentjzimmer/Documents/blob/master/Open_Source_Host_Firmware_Directions-001.pdf

Following on the spirit of openness, I was honored to be invited to keynote the upcoming open source firmware summit https://osfc.io/. The landing page for my talk will be https://osfc.io/talks/keynote. This should follow the arc on reducing friction and providing transparency for host firmware development.

And on a final note, it appears as if the USPTO has issued its 10 millionth patent https://10millionpatents.uspto.gov/docs/patent10million.pdf on June 19th. My first issued US patent #5,940,587 based upon my Intel work caught the tail end of the 5 million wave, whereas my last two issued Intel Patents book-ended this milestone, namely last week's #9,998,284 and this week's #10,002,002, respectively. Amazing ramp of issue rate from the patent office https://patentlyo.com/patent/2014/09/patents-issued-fiscal.html....

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 


Thursday, March 22, 2018

Open platforms and 21 or Anniversary.Next^6

This covers my 6th blog aligned with my work anniversary, a successor to http://vzimmer.blogspot.com/2017/02/this-one-is-for-20-or-anniversarynext5.html. I always mean to post this on the anniversary day, but I'm a bit laggard this year. Luckily this is a personal blog with random musings, so I don't have to worry about conformance to an SLA or other criteria... This anniversary year marks crossing the 21 year marker. As a multiple of 7, we have both a lucky number and also a milestone for sabbatical eligibility.

The journey has taken many twists and turns, commencing in 1997 with joining Intel to work on Merced https://en.wikipedia.org/wiki/Itanium boot firmware for server platforms. Merced was Intel's first 64-bit Itanium CPU. I am awed by scope of firmware changes, from that era of bringing up a new CPU, leading to events like this week where an open source EDKII based server firmware is announced at the Open Compute Project (OCP) Conference https://youtu.be/Dh6N7Pj1CLs and https://www.youtube.com/watch?v=4a1QHQ76it8.

For the latter, the system stack roughly follows the figure shared with the OCP Open System Firmware (OSF) effort  http://files.opencompute.org/oc/public.php?service=files&t=1ab7018c4aac16910255681b2eff469f&download.  


The server provides a minimal viable product design based upon the Min-Platform that we introduced with client in https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform. The specific server platform is Mt. Olympus https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus described in http://www.opencompute.org/wiki/Server/ProjectOlympus.

Some of the design rationale for the minimum platform design approach can be found in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf which has been updated to cover the server port.

Here are a couple of salient pages from this week's OCP deep-dive session on this topic https://2018ocpussummit.sched.com/event/DJ8H/firmware-the-final-frontier-achieving-the-promise-of-ocp-by-making-ocp-nodes-truly-open which describes work in the Open System Firmware (OSF) workstream http://opencompute.org/wiki/Open_System_Firmware


This is a forum where cloud service providers (CSP's), hardware, firmware, and software parties can engage on how to further ease development of servers in a more open, community fashion. This includes many types of lower-level boot firmware, OS hand-off interfaces, etc. Very much a pragmatic, 'getting things done' type of group.

Again back to the scale of scale. For the original Itanium we had closed source SAL, PAL, BIOS, and partially open source EFI sample. Now we can build a server image from content off the web. Quite the evolution over these last 2 decades.

Beyond the bits and bytes of the technology, the view of others on platform firmware standards like UEFI and ACPI is sometimes amusing. For example, many people type 'uEFI' (micro-EFI?) versus the full UEFI, or pronounce UEFI as 'YOO-FEE.'  We typically just pronounce each letter, U-E-F-I. Less often I've heard ACPI as ACK-PEE, including Heasman in his '07 talk https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf. This reminds me of my teen-age years, pre-internet, and growing up in Texas, when I'd read a lot of philosophy books, including Berkeley and Hegel. When I later had an opportunity to discuss these writers with others, I'd invariably mispronounce the names (e.g., HEGEL versus HAY-GEL, BERKLEY versus BARK-LEY). I guess we've all had this problem of reading a name for years but not hearing it spoken aloud.

It's time to close this tardy blog. I surely missed addressing some interesting events since my last blog posting given the many month absence from blogging. As such, the choice of topics herein less represent overall importance than proximity in time. So please assess using that lens.

© 2018, Vincent ZimmerThis work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License 

Saturday, October 14, 2017

The march of time

As I read https://community.infoblox.com/t5/IPv6-CoE-Blog/Where-Are-You-On-The-IPv6-Adoption-Curve/ba-p/11116, I couldn't help but think of the progression of IPV6 support in UEFI.
We compared the adoption arc of the two efforts in
http://www.uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf.

Interesting milestones on both the technology front https://tools.ietf.org/rfc/rfc5970.txt and in the specification uefi.org / codebase tianocore.org curation are shown below



In 2010 my colleague Bob Hale and I noted the following about Tiano www.tianocore.org

https://github.com/vincentjzimmer/Documents/blob/master/Neither-Seen-Nor-Heard.pdf.  9th generation in 2009.  Oh my.  Good thing we chose a different designation for the various types we snap EDKII trunk with the validated UDK releases https://github.com/tianocore/tianocore.github.io/wiki/UDK

Lots of changes these last few years. Another journey on this trip was meeting Paul Otellini in 2005. I was definitely saddened by the news https://www.theverge.com/2017/10/3/16411480/paul-otellini-death-intel-ceo


But change is part of the trip. I recently said good bye to my colleague Lee Leahy. He and I collaborated for several years and had the opportunity to co-present https://www.youtube.com/watch?v=I08NHJLu6Us


To remind us that he has retired to Hawaii, he left the following picture in the cubicle behind mine, taken from his new backyard.

A final marker of the change occurred when cleaning out some data books. The right hand side (RHS) is the programmers reference manual (PRM) for the 386SX, whereas the left hand side (LHS) stack includes the reference tomes for an Intel based CPU's from a couple of years ago (prior to all documents going online-only).

An example of the change include the RHS PRM description of an instruction such as SCAS. The description even listed the number of clocks to retire the instruction, which was possible in the days of simpler memory hierarchies, in order execution, etc.

The following shows the same instruction from the LHS.


More modes.  No clocks.  As times change, instructions change.

I look forward to chatting with people on Sunday about UEFI and security https://firmwaresecurity.com/2017/10/10/uefi-security-presentation-at-seattle-dc206-meeting/. It's interesting to see this talk having been referenced in a few places, such as https://www.cylance.com/en_us/blog/black-hat-vegas-where-the-guardians-of-the-bios-are-failing.html, https://medium.com/@matrosov/bypass-intel-boot-guard-cc05edfca3a9,  https://www.darkreading.com/vulnerabilities---threats/7-hardware-and-firmware-hacks-highlighted-at-black-hat-2017/d/d-id/1329442?piddl_msgorder=&image_number=6, and https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html, too.

Speaking of change, time to break away from the PC.

PS
Update from 10/18/2017
Thanks to the Lodge

for great questions and attendance this weekend


Wednesday, August 9, 2017

Accessing UEFI UpdateCapsule from the operating system runtime

"Accessing UEFI from the operating system runtime" http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html represents my most frequently accessed blog posting. In fact I scrawled this quick posting in response to an engineer having recently sent me a mail referencing the above posting and decrying lack of information on access to the UpdateCapsule interface from the various OS's.

To begin, let's start with the API exposed by the UEFI firmware is defined as followed:
The capsule in memory follows:



From my perspective as a 'builder' of firmware I often focus on the underlying constituent elements, but that's a smaller audience than the consumers of the firmware. At the time of the posting, the UEFI Variable interface was the more important interface in order to access both UEFI specification defined variables, namely those {GUID, Unicode String} named pairs codified in the UEFI specification, and vendor-defined variable GUID's and Names.

In the five years that have followed that posting, there's another important extensible run time interface that has been exposed to the operating system run time, namely the UpdateCapsule interface. The Capsule infrastructure began as part of the Intel Framework corpus https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-capsule-specification.html, but was eventually donated into the UEFI Forum in a similar specification arc as HII. Recall that much of the Intel Framework specifications, such as PEI and DXE, became pillars of the UEFI Platform Initialization (PI) specifications, but when an interface needs interoperability between the pre-OS ISV's and OS runtimes, that is purveiw of the UEFI (and ACPI) specifications. Microsoft complemented this Framework-era capsule infrastructure with the ESRT, or a list of updatable elements in the platform defined by a list of GUID's.

Although the UpdateCapsule API can be used to convey any information from the run into the pre-OS, including crash-dump, management information, etc, the 'firmware update' usage is the most important from a business perspective.

And regarding the API, having a definition of the interface and the data enveloping mechanism are necessary but not sufficient. You also need producers of the update interface on system boards and infrastructure software to invoke the interface. To that end, the EDKII community has published a rich set of infrastructure code to provide the interface https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery with a detailed code explication in https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. On the operating system side, there is infrastructure to support invoking the interface for both Linux https://lists.gt.net/linux/kernel/2149809 and Microsoft Windows https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/system-and-device-firmware-updates-via-a-firmware-driver-package.

The Linux kernel exposes the capsule loader interface via sysfs in a similar fashion to how the UEFI variable interfaces are exposed. The Windows implementation, though, doesn't expose the direct interface but instead conjoins issuing capsules on top of the infrastructure for installing drivers. This is where the distinction between capsules as a mechanism to pass a GUID-named data payload with a scatter-gather list in memory back to firmware compares to usage of this interface to pass payloads that are a firmware update. On the latter point of updates, the Linux community has build out the fwupd service http://fwupd.org/ to facilitate pushing out updates in a similar fashion to Windows Update http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_07_Microsoft.pdfhttps://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-update provides an interesting view into steps involved in plumbing a Linux distribution for this end-to-end use case, too.

You can think of the UpdateCapsule invocation as a syscall back to the firmware. This is different than UEFI Variables where the expectation that the 'set' call persists immediately without and intervening platform restart. Instead, by having the UpdateCapsule take effect (typically) across a restart, the update of the underlying firmware can occur in the early boot of the firmware Trusted Computing Base (TCB) prior to running third party code. Or a capsule can just be passed through, such as the case of the OS runtime sending its panic screen to be displayed across a restart to its UEFI OS loader.

Philosophical postlude -
The difference between UpdateCaspule versus the Get/Set Variable interface is that the latter has been available in the EFI (and then UEFI) OS's since 1999. Update Capsule, and the corresponding ESRT, have only appeared more recently. If I had a chance to invoke George Cox's http://vzimmer.blogspot.com/2015/06/guids-revisions-interrupts.html "I could do it better the 2nd time" penchant of engineering, I would have argued that art such as UEFI Authenticated Variables would have been better built as signed UEFI Capsules versus UEFI Variables since authentication-at-reset in the PI phase (BIOS TCB) is much easier to build than an authentication agent in the firmware that is isolated from the OS or hypervisor run time, as needed by the UEFI Authenticated Variables.
Sigh. Hindsight is 20/20.