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
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


Little profundity found in the erstwhile company sign or the visitor parking sign compared to, 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
for UW alumni 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

From the Xerox device
I possibly found a use for

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 Many exciting presentations from across the industry. I was invited to speak about openness and server firmware with the following presentation

Following on the spirit of openness, I was honored to be invited to keynote the upcoming open source firmware summit The landing page for my talk will be 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 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

© 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 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 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 and

For the latter, the system stack roughly follows the figure shared with the OCP Open System Firmware (OSF) effort  

The server provides a minimal viable product design based upon the Min-Platform that we introduced with client in The specific server platform is Mt. Olympus described in

Some of the design rationale for the minimum platform design approach can be found in 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 which describes work in the Open System Firmware (OSF) workstream

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 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, I couldn't help but think of the progression of IPV6 support in UEFI.
We compared the adoption arc of the two efforts in

Interesting milestones on both the technology front and in the specification / codebase curation are shown below

In 2010 my colleague Bob Hale and I noted the following about Tiano  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

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

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

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 It's interesting to see this talk having been referenced in a few places, such as,,, and, too.

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

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" 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, 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 with a detailed code explication in On the operating system side, there is infrastructure to support invoking the interface for both Linux and Microsoft Windows

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 to facilitate pushing out updates in a similar fashion to Windows 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 "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.

Tuesday, August 1, 2017

Black Hat USA 2017 - Firmware is the new black?

Happy to be back from Black Hat in Las Vegas. I usually capture photos of my journey, but I must have lost my head on this trek

since I only captured a couple notable shots, including


Regarding the event itself, our presentation for can be found at I can  nowsafely hang my badge

among my dog pile of other badges.

In that archaeological pile I can find residue of preceding security conf presentations - ToorCamp 2012, BSides 2013, ToorCamp (again)  2014, and CanSecWest 2015.   

I was honored to be among the list of other speakers.

Surprisingly, I wasn't the last name on the list.

My Intel colleagues included Rodrigo from the offense side, I treated defense, and Bruce talked about response.
The talk began with an overview of the ecosystem, including the supply chain that often begins with the open source upstream. Within that upstream many of the core protection, detection and recovery UEFI-based EDKII features were reviewed. This section of the talk culminated in many of the open source EDKII platforms upon which these protect/detect/recover features can be integrated. 

These platforms allows for marrying the rich set of core components with representative platforms The most evolved includes the first Intel(R) Core-based open source platform using EDKII platform code, described in The chipsec project was also reviewed as one means by which to assess if the platform was configured correctly.

After the ecosystem and defense intro, the talk moved into the data set of issues and a proposed methodology. This portion of the talk generated the most interest, at least as evidenced by the number of people taking screen shots of the content.  This taxonomy included:

and a histogram of issue appearances

This class of information can help inform test strategies and investigation into new defenses.

After the data review, a cursory discussion of threat modeling was presented. This class of erudition also informs what type of defenses and testing needs to occur. Like the former topics, this portion of the talk wasn't intended to be complete so much as argue for the need to have this type of review with the broader research and platform building community.

And for any large effort, the collaborators for the deck and our colleagues are the most important part of the adventure.

The talk was picked up by the press ahead of time We were approached by other publications to give an interview but interleaving day-job and conference ate up the available hours, I fear. Thanks to a Charlie Miller tweet at least there's some evidence that we made it to the stage

To close today's blog, this should not be the end of this material for 2017. I promised to reprise this talk for at the lodge in my backyard here in WA

    The TENTATIVE schedule for DC206 Meetings:
    Sep: Josh, Coffee Roasting
    Oct: Taylor, intro to Bash
    Nov: Vincent Zimmer of Intel, UEFI security
    Dec+: CfP open

Hopefully I can recruit my co-presenters to trek up I-5 to help out, too.

Tuesday, May 30, 2017

UEFI and Security postings

I was pleased to see a few days ago and the associated Github repo The authors include

I'm glad to see this material, including a couple of my co-authors from

Hopefully I will get a chance to talk with some of these ex-Intel, now-McAfee engineers at Blackhat. I see they are giving the talk Myself and a couple of colleagues are giving a separate talk at the event

Interesting timing since it was in 2007 that I sat on the front row watching John Heasman talk about "Hacking the Extensible Firmware Interface." This was my first Blackhat trek a decade ago. I had coffee why John a few weeks afterward in Tacoma and he exhorted me to push the signing of UEFI drivers and applications. He also mentioned the venerable TCG specs on page 37.

Good times. Fast forward to today, UEFI seems to be in the news and conference scene quite a bit of late.

Beyond the training material and upcoming conference talks, though, I am especially happy to see the NIST Special Publications (SP) 800-193 on "Platform Firmware Resiliency Guidelines" get posted for purposes of public comment review. This work should complements the UEFI standards in provides a robust platform implementation. As always, the people involved in the process are as important as the output of the process itself.

So much for May blogging, and here's looking forward to a WA summer. Speaking of summer, it is interesting that the picture of Stevenson, WA from last week
looks quite similar to a picture from 2005, too.
The passage of time......