Tuesday, December 13, 2016

Provisioning, Porting and Types

I'd like to begin this posting with a review of work presented years ago. Specifically, my friend Harry H provided me copies of my first three Intel Developer Forum (IDF) presentations from 2003  https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf and 2004 https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf, respectively.

The first presentation was jointly delivered https://github.com/vincentjzimmer/Documents/blob/master/Non-IA%20Silicon%20Support%20with%20the%20Intel%20Platform%20Inovation%20Framework%20for%20EFI%20-%202003.pdf with Bob H and Michael K. This work informed some of the information in chapter 7 of the UEFI Book. The basics of the architecture haven't changed, with the notable exception of advocating the use of Intel(R) FSP https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf and associated marriage with open source platform code on http://www.tianocore.org.

That same 2003 event featured a solo talk on security features https://github.com/vincentjzimmer/Documents/blob/master/EFI_Specification_Evolution_Final_04%20-%202003.pdf. This talk included an introduction of the modular network stack which we internally ear-marked for a never-released "EFI 1.2" specification. These API's on slide 15 ended up appearing in the UEFI 2.0 specification circa 2006 http://www.uefi.org/sites/default/files/resources/UEFI_Specification_2_and_Errata_Sept16_08.pdf and later in the open source https://github.com/tianocore/edk2/tree/master/NetworkPkg. Beyond these API's, though, other elements like the EAP-Teanie method were never realized in the market. The best documentation of the latter appeared in a paper on using UEFI in the Cloud on pp. 4-5  https://github.com/vincentjzimmer/Documents/blob/master/SAM6560.pdf. Custom EAP methods violate the design precept of UEFI, namely leveraging well-known art, including authentication methods. Thus the recent focus on TLS for HTTP-S and EAP-TLS for our various network use-cases.

From 2004, other items that landed on the cutting run floor included the EFI_SECURITY_SUPPORT_PROTOCOL on page 20 of the presentation. In the ensuing ten years I attempted to standardize an interface like this in the standards body, but we have ended up instead with a library class https://github.com/tianocore/edk2/tree/master/CryptoPkg which can be layered directly on a static library such as OpenSSL or a private protocol. Finally, the pp 23-24 "COB's" of the EFI_CONFIGURATION_OBJECT_PROTOCOL never appeared in the open source or the standards, but the configuration aspects of slide 30 finally appeared in the UEFI standard from the original OEM-scoped HII Framework standard http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf.

So much for IDF in 2003. In 2004 we presented on EFI Security extensions again in https://github.com/vincentjzimmer/Documents/blob/master/EFIS001_100_2004.pdf. In this talk we elaborated on the 2003 talk with more details, including slide 17 for PE/COFF EFI image integrity. Since that talk we have evolved a UEFI image integrity model in https://github.com/vincentjzimmer/Documents/blob/master/SAM4542.pdf (2007),
https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Networking-and-Pre-OS-Security.pdf (2011), and https://github.com/vincentjzimmer/Documents/blob/master/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf (2012).  Same story on the rest of the vision, though. The vision of smart objects like COB's was not realized in the market.

A common theme on the IDF 2003 and 2004 presentation was the topic of provisioning, though. With the UEFI 2.6 specification, x-UEFI, and HTTP boot, the vision has been realized in a different figuration in 2016 https://github.com/vincentjzimmer/Documents/blob/master/UEFI%20Plugfest%202015%20-%20UEFI%20and%20the%20Cloud%20-%20003%20Bulusu%20-%20Zimmer%20.pdf https://github.com/vincentjzimmer/Documents/blob/master/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf. As such, I can claim the ball has been moved down the field in the last decade.

Another topic that perhaps hasn't progressed as much in the last decade entails language-based security (LBS). Back in the early 2000's I investigated how technology like http://www.cs.cornell.edu/talc/ might be applied to the EFI firmware http://google.com/patents/us6978018, including a failed port to https://cyclone.thelanguage.org/. That's why I am excited to see efforts like https://firmwaresecurity.com/2015/09/04/rust-and-uefi/, including the write up http://ceur-ws.org/Vol-1746/paper-15.pdf. These efforts show promise to complement other security efforts in this space. I also enjoyed the reference in the latter paper to the EFI memory map white paper, UEFI book, and Cloud presentation. To me this affirms the value of openness, from publications down to the source code, in evolving an ecosystem.

Another interesting intersection of Rust and system software is http://www.tockos.org/ which a colleague at a nearby company mentioned to me over lunch. I need to dig into this work in the future.

Speaking of ecosystem evolution, I also want to cite our write up on the recently upstreaming capsule design https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf. If this paper work were to have pre-dated the Rust paper perhaps it would have been the capsule reference in lieu of the "BZ15" one? This latter white paper reads on 'platform recovery,' such as described in the UEFI PI specification. As a complementary overview of operating system (OS) recovery there is https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf which explicates some of the technology in the UEFI specification and touched upon by me at the last UEFI plug fest.

Now off from working in an urban area

to a more suburban office

I'm not sure which is spookier.

Well, enough of looking in the rear-view mirror today. Let's instead face the wind screen and continue forward down the road.

Wednesday, November 23, 2016

Conferences, Forums, and Writings

It has been some time since I touched this blog. Thanks to Lee F. for his recent email bump "the blogosphere misses you" for reminding me of gap. I'll try to play a bit of catch up with today's posting.

I also need to refresh my postings to https://firmware.intel.com/blog but I have to admit that I prefer the Blogger interface - it auto-saves the content, it doesn't ask me to update my password every time I log in, it's easy to important graphics,....

And I'm really glad to see Tim Lewis blogging again http://uefi.blogspot.com/. He's one of the most talented guys I know in this industry and I enjoy reading his postings almost as much as I enjoy talking with him in person.

Regarding Tim's blog, he described the recent UEFI Forum publication of the PI 1.5 specification http://uefi.blogspot.com/2016/10/pi-15-released.html. The most notable update is the generalization of the System Management Mode (SMM) software model in volume 4 to the "Management Mode" or "MM" model that can accommodate both ARM TrustZone (R) (TZ) and IA32/x64 SMM. Historically we didn't unify the Itanium PMI software model with SMM since the former didn't offer the curtained execution model of both SMM and TZ. There are many commonalities of the latter two, though, such as the "SMI" activation mechanism, with "System Management Interrupt" for SMM and "Secure Management Interrupt" for TZ, etc. The ability to load earlier was informed by some ARM implementations establishing memory early and provisioning TZ, and also a potential SMM implementation of an early load https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Launching_Standalone_SMM_Drivers_in_PEI_using_the_EFI_Developer_Kit_II.pdf. One potential usage of the PI1.5 would be to cross-compile error logging code https://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf between a x64 Server to an Aarch64 based server, for example.

Beyond the UEFI Forum, there has been more industry discussion of the Intel(R) Firmware Support Package (FSP).  Specifically, this technology figures prominently in Tim's BlinkBoot (R) white paper http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-secure-iot-solutions-insyde-software-blink-boot-fsp-white-paper.pdf mentioned in http://uefi.blogspot.com/2016/10/intel-and-insyde-embedded-white-paper.html. That paper is co-authored by another FSP fellow traveler, Ravi R, who helped create the series of Intel FSP producer/consumer papers, including https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf.  Along with the latter white paper co-author Giri Mudurusu I delivered the talk “Intel Firmware Support Package 2.0 Overview” at the coreboot conference, San Francisco, CA, June 14, 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016. The presentation is posted to

At the same conference, my colleague Lee Leahy and I delivered “EDKII and CorebootPayloadPkg." The presentation is at https://github.com/vincentjzimmer/Documents/blob/master/EDK-II_and_CorebootPayloadPkg.pdf and the video at https://www.youtube.com/watch?v=I08NHJLu6Us.

On the coreboot payload package, in retrospect this code could have been generalized to the 'UEFI Payload Package.' Although the coreboot package has cbmem as its input data structures, which are then converted to HOB's, DXE and a UEFI implementation are easily launched from any environment with a HOB list. In fact, in the early days of Framework development we have a PEI shell command that would launch the DXE from the EFI Shell by just forging a HOB list. So this payload package could subsume today's DuetPkg https://github.com/tianocore/edk2/tree/master/DuetPkg, or EDKII on a PC/AT BIOS. Or the payload could be appended to U-Boot http://www.denx.de/wiki/view/U-Boot as an alternative to U-Boot native EFI implementation http://lists.denx.de/pipermail/u-boot/2016-February/244378.html, perhaps?

The coreboot conference was at a Google office near the waterfront in San Francisco, with the following view from the Google cafe.

Nice view and food. Over breakfast one morning Ron Minnich and I discussed the RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv/riscv-pk/blob/1e62fdfce7b0095a57e4672c6c5fa4d3efb33d2a/machine/sbi.S and how it was a similar model to the DEC Alpha PALcode https://en.wikipedia.org/wiki/PALcode. We each agreed that having a hardware interface is often preferable to yet more run time firmware interfaces like sbi.

And the after-hours activity for the conference included a visit to http://longnow.org/ with a mock-up of the 10,000 year clock

After this conference I revisited San Francisco again to deliver a poster chat at the Intel Developer Forum.  Below is the abstract of the talk:

SOFTC01 — New Firmware Security Requirements for the Modern Data Center
Data center security relies on a core root of trust, which is provided by platform firmware. The latest Trusted Platform Module (TPM) standard, TPM 2.0*, and updated Unified Extensible Firmware Interface (UEFI) requirements for enterprise operating systems are critical for companies deploying modern, secure data centers. In this session, you will learn security practices for UEFI firmware in enterprise and data center environments, based on new OS requirements and capabilities
Topics include:
• Update on latest UEFI standards for networking and security.
• Latest updates for TPM2.0.
• Guidance on building trusted enterprise class platform firmware.

About the Speaker

Vincent Zimmer Senior Principal Engineer, Intel Corporation

Vincent Zimmer is a Senior Principal Engineer in the Intel Software and Services Group. Vincent has been working on the EFI team since 1999 and presently chairs the UEFI Security and Network Subteams in the UEFI Forum www.uefi.org. He has authored several books and articles on firmware.

With the following poster.

The poster chat provided a lot of discussion with members of the industry around data center host firmware and deployment, including interest in HTTP-S style deployments in lieu of today's TFTP-based PXE.

It was great to see Kushagra https://azure.microsoft.com/en-us/blog/author/kvaid/ on stage during the data center keynote, too.

When Kushagra was at Intel as a CPU architect he helped the firmware team pioneer the cache-as-RAM usages http://google.com/patents/us7254676 and later as a data center technologist some interesting platform solutions http://google.com/patents/us8984265 and http://google.com/patents/us7747846.

And during the event I was able to catch up with some colleagues on the show room floor, including Jeff Bobzin and Tim Lewis from Insyde, Dick Wilkins (thanks Bob H. for catching my typo in original posting) and Jonathan from Phoenix, and Stefano and Zach from AMI. Good folks all around.

After these sojourns to California, I gave a talk at the UEFI Plugfest http://uefi.org/2016FallUEFIPlugfest here in the Seattle area. You can find the talk material at http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_VZimmer_Fall_2016.pdf and the video at https://www.youtube.com/watch?v=_N1v_bWN4zk. Many of my slides on the specification's features listed the corresponding Github repository. I omitted a link to the capsule work since at the time of the talk the EDKII feature was under community review. If I were to reprise the presentation today I'd affix https://github.com/mdkinney/edk2/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery to the top of slide 7.

During the Plug Fest Microsoft's Scott Anderson also provided an overview of http://www.pcworld.com/article/3106726/windows/golden-keys-that-unlock-windows-secure-boot-protection-uncovered.html in slides 4 and 5 http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Security_Microsoft_Fall_2016.pdf.

In my UEFI Plugfest talk I also gave an update of the standards and some of the developments on EDKII, including mentioning some DMTF alignment topics I had also discussed at OCP https://www.youtube.com/watch?v=3yGbwUwwjxc. I also enjoined the community to complement the industry standards with more informative information. To that end, beyond the above presentations and new industry standards, I co-authored a few new white papers since my last blog posting, including:

And under the guise of the UEFI Forum, "Establishing the Root of Trust," UEFI White Paper, August 2016, http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf was published.

The intent of such material is to provide rationale and some guidance on how one might successfully refine the standards into a working artifact, including ones based upon EDKII style technology.

Well, so much for a catch-up blog. I wish everyone a happy Thanksgiving tomorrow from the always raining-in-November Seattle area.

Tuesday, July 26, 2016

M, M, and P

These three letters stand for "Mission, Mastery, and Passion."

I was motivated to scribe this quick blog based upon a conversation with an engineer in the Seattle area awhile back. He had lived through stints at Amazon, Microsoft, and other technology companies, including sole proprietorship's.  I asked him why he chose his latest career turn and he uttered that the job satisfied his three criteria - Mission, Mastery, and Passion. I won't break down the specifics of his explication of that 3-tuple, but here's the generic interpretation I derived.

In fact, this MMP triple has a fractal quality.  It can be used to describe a person's role, a group, or an entire company. And in the the process of this exploration I hopefully won't sound like a poor imitation of a Seth Godin blog http://sethgodin.typepad.com/.

To begin with "Mission," the essential question to ask oneself is 'do I believe in the goals or business imperatives of the specific company?' In retrospect it's easy to arm-chair quarterback this one, especially during the go-go days of the dot com businesses http://money.cnn.com/galleries/2010/technology/1003/gallery.dot_com_busts/, but I do believe that technologists have a reasonable acumen in this space. .

And at a personal level regarding mission, I work on software in the hardware industry. If Marc Andreessen has correctly characterized that 'software is eating the world', http://www.wsj.com/articles/SB10001424053111903480904576512250915629460 then I would ask 'upon what hardware and firmware will this software run?'  And I do believe in contemporary mission statements, such as https://newsroom.intel.com/editorials/brian-krzanich-our-strategy-and-the-future-of-intel/.

Assuming you are OK with the mission, the next question to explore is "Mastery." In this case the question is simple, namely 'Is there head-room to learn in this role?' To be effective in the technology world, you have to continue to re-train and learn https://www.exceptionnotfound.net/learn-or-die-warding-off-my-coding-careers-eventual-obsolescence/ http://www.wsj.com/video/a-new-approach-to-business-learn-or-die/4A64AA70-9D61-4DC4-83EE-5426384F0198.html. In fact, the best advice I received during my Masters in Computer Science from UW occurred in Ricahrd Ladner's http://www.cs.washington.edu/people/faculty/ladner algorithms class. He said something to the effect of 'I cannot teach you everything about this topic, but what I can do is teach you how to research and learn on your own.' Given the nature of my employ and its mission statement listed above, I definitely have opportunities to learn each day in my present role.

And finally there is "Passion." This is a topic I treated earlier in http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html, and this aspect of the employ cannot be understated. If you don't 'believe' and have fervor to perform your job, you are unlikely to be successful. You have to believe in what you're doing entails a mission and have a personal stake in the endeavors. It's not 'the company' or 'the job', it is integrally 'you.'

But also head the advice of others, too https://www.cia.gov/library/center-for-the-study-of-intelligence/kent-csi/vol40no5/pdf/v40i5a06p.pdf

With that passion in hand you should also be authentic in your role and truly strive to achieve, or 'do something,' as the author of https://www.amazon.com/Chaos-Monkeys-Obscene-Fortune-Failure/dp/0062458191 notes in his question "To be someone or to do something, which would I choose?" In the act of 'doing something' you will hone your skills, expand your network, and support the progress of the business.

So with that I encourage you to explore your own MMP list. I recently met a junior engineer who seemed despondent about his job. I interviewed him using the MMP rubric and discovered that he had the two M's covered but not the P.  I told him to work on the P, else evolving from a junior to a senior role could be a tough journey.

Monday, June 6, 2016

Shields and Networks

In this blog I opine about shields, API's, and networks.

To begin with shields, the clip 'UEFI on Agents of S.H.I.E.L.D.'  https://www.youtube.com/watch?v=9lc95nXKWMM and associated transcript dialog http://transcripts.foreverdreaming.org/viewtopic.php?f=140&t=27259 included "This is called a Unified Extensible Firmware Interface."

What a fascinating occurrence in the popular culture of 2016. It reminds me of the introduction of the "Unified" term to the 'Extensible Interface' when our circa 1998 EFI 1.02 specification was sent to the standards body www.uefi.org, and shortly afterward in the book

I wasn't the first choice for the book. The opportunity was offered to several others and only landed upon my doorstep after the editor had read the 2004 white paper UPDATE. I was motivated the pursue this effort in order to declare that UEFI was being implemented by "Intel's Framework", or our code base infrastructure that became EDKII on tianocore.org. This first implementation was also based upon the Intel Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html that subsequently became the UEFI Platform Initialization (PI) Specifications.

While at Intel, Richard Wirt https://www.crunchbase.com/person/richard-wirt-m-s-ph-d#/entity was our Vice President and told me that there is both 'real and perceived' leadership. I believe we demonstrated 'real' leadership by delivering the EFI 1.0 specification into UEFI 2.0, the Framework specifications into PI 1.0, and the Framework code into the EFI Developer Kit (and later the EFI Developer Kit II - EDKII). But the book helped highlight that our 'real' leadership also had attendant 'perceived' leadership in the market.

Another good sound bite from management in those days was "if you cannot describe your job in a sentence or two, you don't really know what you're doing."

We updated the book five years later

The part of the latter book that most pleased me was sneaking the work 'eschew' past the editor. From page 285

'Although the development and design team eschewed use of proper names in code or the resultant binaries, the "VZ" and "Vincent Zimmer" association appeared harmless, especially given the interoperability advantages.'

Regarding UEFI ,a nice thing about UEFI and PI include locking down interfaces for purposes of interoperability.  The Intel Firmware Support Package (FSP) builds upon this API codification, with the following quote from R. Minnich in the introduction to
So API's are one thing, but the system also has interfaces on the network. This is where networking and wire protocols come into play. I'm happy to see the boot-from-HTTP that we codified in UEFI 2.5 and expanded upon with RAM disk scenarios in UEFI 2.6 continuing its build out. We struggled a bit thinking about how to evolve the UDP/TFTP-based PXE to the HTTP-based use cases. One of the features of the UDP-based PXE was the multi-cast variant of TFTP. We explored evolving PXE to be more scalable with streaming, big block, and reducing the number of ACK's. Dave Thaler told me that with those efforts in hand we were 'inventing' TCP, thus the move to the best-known implementation of TCP today, namely the application protocol HTTP, built upon TCP.

And for use-cases where you need the type of scalability found in multicast TFTP if PXE, we have DNS and HTTP for the UEFI HTTP boot. And the entire web model, from content delivery networks (CDN's) to load balancers, optimize the scaling of HTTP. Given that 'the world' is working on that particular scaling problem, the meagre firmware network use case should ride that wave of industry R&D practices. This is in the spirit of EFI wherein we tended to avoid reinventing known art, like file systems (FAT12/16/32), image formats (PE/COFF), and image integrity (Authenticode).

Speaking of scaling HTTP in these first 10000 days of the web, I have to hearken back to my days at the University of Washington 1998 when I was pursuing my masters. I took the computer performance class from John Zahorjan https://homes.cs.washington.edu/~zahorjan/homepage/.

At UW, this project entailed working on evaluating Round Robin DNS policies using web data from Brian Pinkerton's https://en.wikipedia.org/wiki/WebCrawler MetaCrawler. My partner on this proejct was an engineer from the erstwhile Teledesic effort, and we built a discrete event simulator fed by web traffic to assess response latencies based upon DNS server load balancing techniques.

I now appreciate the blog and web posting of information, such as on github, since the code and documentation from this project are lost in the sands of time. If I were to do this project today, I'd definitely share the results on the web. At the time I was also interested in heavy tailed traffic characterization, including work by Mark Crovella http://www.cs.bu.edu/fac/crovella/list.html.

Now we are in 2016 and we are booting from web servers in a standards based fashion.  Cool.

Regarding networking use-cases, it is a continuous challenge deciding  how much functionality to put into the pre-OS versus just booting a deployment operating system, like Linux or Microsoft Windows Pre-installation Environment (PE). I'd say that for diskless workstations, P-blades (processor + memory only compute nodes without local disk), diskless clients, recovering a a failed main OS on disk, etc having integrated networking makes sense. But for sophisticated deployments that need a multi-processor, multi-threaded, interrupt-driven, high performance and feature rich environment, a Linux or Windows PE makes the most sense.

These questions of balanced design weigh upon me as I look after the UEFI networking and security subteams in the UEFI Forum. I worry that I sometimes starve the former given the amount of issues and work in the latter.

And now for some final thoughts on networking and security. At ToorCamp 2012 http://vzimmer.blogspot.com/2012/08/one-conference-down-one-to-go.html I still recall Jacob Appelbaum suggested a removable TPM that the platform owner could destroy when encountered by law enforcement, and then Cryptocat author Nadim Kobeissi mentioned porting to UEFI in order to have a safer environment to do network communications.

The other convention-time suggestion from this era occurred during a trek to the Ubuntu Developer Summit in Orlando. My colleague Harry and I bumped into Mark Shuttleworth in the expo area after the presentations. After discussing UEFI with Mark for a few moments he asked us both about just putting Linux in the hardware for booting Linux from disk.

I'm not sure if these 2012 suggestions will ever come to pass in the platform, but it's always to follow the arc of technology in this industry.

And speaking of following arcs, I need to follow the arc of 'getting back to work.'


And don't think about the meat clown

Tuesday, April 26, 2016

Open source platforms, FSP consumers, FSP producers, and STM updates

You've seen in the past when I have talked about Intel Firmware Support Package (FSP), hearkening back to 2014 [1][2]. There are 2 parts to FSP - the Consumer or use of the FSP in a platform, and the production or creation of an FSP binary.  We'll review examples of each in turn below, in addition to some updates since the 2015 IDF prezo.

By the way, some of these items were also posted to [22] but the latest posting seems to have disappeared.  As such, if you've already read some of this from that site, feel free to skip over the duplicate material.

FSP Consumer
We're posting an updated platform using the 1.1 FSP [3][4]. This tree moves beyond the Baytrail work in [2] and includes Braswell [5]. A good overview of porting the tree is provided, too [6]. This shows some of the best practices on building EDKII on top of FSP. Specifically, the only macrocode binary is in the Intel FSP, with the rest of the EDKII code to provide the core UEFI & PI services, along with the platform initialization, in open source.

This is an important step to show how FSP + open source can be used to build a full solution, or EDKII can'Consume' an FSP binary. This provides parallel work-flows to things like a coreboot Braswell solution [13], for example, that also builds upon Intel FSP. Turing equivalence argues that it is all 'just code', so we want to show a few 'equivalences' here.

This is a work in progress that should eventually migrate to [11], but in the interim take a look and provide feedback on some of the code partitioning and design.

Speaking of coreboot, EDKII and FSP, my colleague Lee Leahy [23] and I are slated to talk at the upcoming coreboot conference [24]. We'll review the EDKII CorebootPayloadPkg [26] at [25].

FSP Producer
In addition to the Intel Atom based platform that consumes an Intel FSP binary from [12], there has been a lack of public demonstration of producing an Intel FSP, as described in [2]. This is by design in the sense that the Intel FSP encapsulates matter that does not have public documentation, thus cannot be open sourced. This poses the challenge of how to provide guidance on how to create an Intel FSP. This is where the Intel Quark EDKII code comes into play. Since the low-level silicon initialization, including memory initialization, is already open source, the project providesan opportunity to show how to create an Intel FSP [7]. Luckily we now have an early example of this in public view [8].
I look forward to future platforms that move beyond FSP 1.1, too [10]. And to that end, the FSP 2.0 specification is now live [27], along with the Boot Setting File (BSF) specification [28] that has been used in all of FSP 1.0, 1.1, and now 2.0.

Good stuff.

Speaking of good stuff, here are some updates following last year's IDF prezo [19], including the SMI Transfer Monitor (STM) mentioned at [14]. Specifically, you can now find the STM source code on a public repository [15]. In addition to the documents on the STM itself [21] and the original STM [20], there is also another virtualization technology shared in the repo that wasn't in [20] release, namely the DMA protection work described in [16] which can be found at [17]. This complements the host-based protection of the FRM [18] with some protection from I/O devices performing errant DMA transactions.

You'll hopefully observe a theme here of having more open source platform solutions, including protection technology. This is one way to engage with the community and reduce the barriers to providing robust, transparent platform solutions.

[1] Zimmer, "EDKII, FSP, and other topics", blog posting, September, 2014

[2] Zimmer, "Firmware Flexibility using Intel(R) Firmware Support Package," Intel Developer Forum,
September 2014

[3] Yao, et al, "A Tour Beyond BIOS Using the Intel(R) Firmware Support Package 1.1 with the EFI Developer Kit II," April 2015

[4] Intel Firmware Support Specification External Architecture Specification (EAS), Version 1.1a, November 2015

[5] Braswell EDKII project, April 2016

[6] Wei, et al, "Open Braswell UEFI Codebase - Design and Porting Guide," February 2016

[7] Yao, et al, "A Tour Beyond BIOS Creating the Intel(R) Firmware Support Package 1.1 with the EFI
Developer Kit II, April 2015

[8] Quark FSP 1.1, April 2016

[9] Quark SOC code

[10] Intel FSP2.0 consumer code, March 2016

[11] EDKII project www.tianocore.org

[12] Intel Firmware Support Package (FSP)

[13] coreboot Braswell code that consumes Intel FSP 1.1, April 2016

[14] SMI Transfer Monitor (STM) overview, August 2015

[15] STM Source code, March 2016

[16] Yao, Zimmer, "A Tour Beyond BIOS Using Intel(R) VT-d for DMA Protection in a UEFI BIOS," January 2015, https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf

[17] DMA Package https://github.com/vincentjzimmer/STM/tree/master/Test/DmaPkg

[18] Yao, Zimmer, "A Tour Beyond BIOS Launching a VMM in EFI Developer Kit II," September 2015, https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_VMM_in_EFI_Developer_Kit_II_0.pdf

[19] Zimmer, "STTS003 - Developing Best-in-Class Security Principles with Open Source Firmware", Intel Developer Forum (IDF), San Francisco, August 2015

[20] STM 1.0 August 2015

[21] Yao, Zimmer, "A Tour Beyond BIOS Launching STM to Monitor SMM in EDK II", August 2015 https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf

[22] https://firmware.intel.com/blog

[23] coreboot Quark FSP MemoryInit support, January 2016 https://www.coreboot.org/pipermail/coreboot-gerrit/2016-January/039748.html

[24] coreboot convention 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016

[25] EDKII CorebootPayloadPkg overview, June 14, 2016 https://calendar.google.com/calendar/embed?src=6b1u8iq13jj8cp6kfokq4vlo20%40group.calendar.google.com&ct=America/Los_Angeles&dates=20160612/20160616&mode=agenda

[26] https://github.com/tianocore/edk2/tree/master/CorebootPayloadPkg

[27] Intel Firmware Support Package (FSP) 2.0 Specification, April 2016

[28] Boot Setting File (BSF) Specification version 1.0, March 2016

Tuesday, April 5, 2016

Colleagues across the Pacific

The nice thing about working with a multinational company (MNC) is that I have colleagues from around the world. The far east represents an important location for systems development, including Shanghai and Taipei. Regarding the former, below I had a lunch at the in-famous R&R mentioned in http://vzimmer.blogspot.com/2014/12/so-long-and-thanks-for-all-fish.html with Mike Kinney and Bryan Wang last Friday. I've worked with Mike since 1999 and he's one of the original developers of EFI1.02 through his role today in tianocore.org as one of the 3 stewards https://www.mail-archive.com/edk2-devel@lists.01.org/msg08825.html.

Moving from R&R in WA to another important Intel location, Hillsboro, OR, I caught a lunch yesterday with some colleagues from Oregon and Taipei. The below group includes Giri and Maurice. Maurice (2nd from right) is the inventor of the Intel Firmware Support Package (FSP) 1.0 - see his bio in http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/.

Maurice and Giri (middle) helped drive definition of Intel FSP 1.1 http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf, and Page and Elvis (left 2) create the FSP 1.1 implementation https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf and EDKII code to leverage the Intel FSP 1.1 https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf.

This group of technologists, with the input and assistance of others, have helped scale the Intel FSP, too. Hints of the successor to Intel FSP 1.1 are now visible in the upstream communities, as noted by http://firmwaresecurity.com/2016/03/15/intel-fsp-2-0-in-the-works/ and now visible at https://github.com/jyao1/FSP2.0.

Again, recall that Intel FSP helps us scale working with various open source communities https://firmware.intel.com/sites/default/files/resources/SF14_STTS001_102f.pdf

Working with bilingual colleagues is always interesting. If anyone complains about a Chinese engineer's English, I always remind them that their English is often much better than our Mandarin. Over lunch the aforementioned phenomena is sometimes called Chinglish for "Chinese English" https://en.wikipedia.org/wiki/Chinglish. I learned from Giri that there's a similar phenomena in India with "Hindi English" https://en.wikipedia.org/wiki/Hinglish.

So much for firmware and lunch today. Good tidings and firmware writing.

Monday, March 21, 2016

Open Compute 2016

I just returned from the Open Compute Project (OCP) U.S. Summit 2016 in San Jose. I gave a talk on firmware updates http://ocpussummit2016.sched.org/event/68u5/towards-a-firmware-update-standard. The talk has also been posted to Youtube  http://www.youtube.com/watch?v=3yGbwUwwjxcI This talk builds upon the background provided at the 2015 OCP and UEFI PlugFest, respectively, as described in the "UEFI and the Cloud" posting https://firmware.intel.com/blog/uefi-and-cloud.

For this talk we laser-focused in on the firmware update topic. I received feedback, such as "Good message this morning, glad you guys are interested/passionate about OCP from a FW ecosystem sanity perspective."

The material has a home at http://www.uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf, but it should get posted to the OCP website shortly.

One of the messages we wanted to provide is that the UEFI Capsule interface is both a host-based API. From the UEFI specification we have the interface to send a capsule (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf)
 and then the EFI System Resource Table (ESRT) to detect what are the capsule-updatable elements (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf).
 Beyond the API we have the envelope or data payload (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf):

All of these elements are brought together in the graphic from the prezo and former white papers (from figure 5 of https://firmware.intel.com/sites/default/files/resources/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf):

Our advocacy in the 2016 talk was that even if the update is delivered out-of-band, say via a service processor, the data envelope should be the same. Imagine an independent hardware vendor (IHV) curating an update blob. Why tax the IHV to create separate blobs for different delivery paths?

Going forward we will work with other standards bodies like the DMTF http://www.dmtf.org/, along with OCP opencompute.org and the UEFI Forum uefi.org, to harmonize these efforts. And along with the standards work engage with open source upstreams like tianocore.org to have a robust implementation. And given https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload it would be great to have co-equal support in both firmware ecosystems, including coreboot.org.

Sad news today about Andy Grove https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/.  It reminds me of my early days at Intel, including the signed copy of his man of the year issue I received as a new employee at Intel http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html.

Wednesday, February 17, 2016

Firmware Configuration, or "Is Feature XYZ enabled"

You may have noticed the recent posting on the EDKII mailing list https://www.mail-archive.com/edk2-devel@lists.01.org/msg06031.html about HII export. The mail questions the utility of exporting this information, especially when you cannot easily set the value.  So this begs the question - 'what is HII?'

There is already great material on the web about HII, including http://uefi.blogspot.com/2009/09/uefi-hii-part-1.htmlhttp://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2011Q4_P4_Intel.pdfhttps://www.youtube.com/watch?v=11PIctg6pz8, so I won't attempt to repeat those discourses.

Instead, I'll provide a quick background and why it's of interest to OS run times and management stacks. HII stands for "Human Interface Infrastructure." This was originally a set of Intel Framework technology specification http://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-human-interface-infrastructure-specification-v091.pdf for managing the platform setup.  It consists of a database of settings and forms. The forms have a list of questions and an associated setting. HII moved into the UEFI specification when it was observed that 3rd party UEFI drivers might publish forms to support the configuration of their respective devices.

My office neighbor here in Seattle Mike Rothman

authored much of the specification in this area, including how the HII database can be exported to the operating system runtime [from UEFI 2.6 http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf]

The left side of the figure shows the pre-OS usage of the information, such as a PC's 'setup/browser' application. The right hand side shows how this information can be ascertained via a pointer in the EFI_SYSTEM_TABLE to view the information at runtime. It is this 'export' behavior, a requiremetn of the UEFI specification, that the mailing list patch at the top wanted to make optional via the firmware build.

The strings are interesting, but today the questions are vendor-board specific. To provide additional utility, having the questions and settings normalized across a larger class of devices was pursued. As described in section 3 of https://firmware.intel.com/sites/default/files/resources/uefi-manageability-security-white-paper.pdf:

"OEMs typically have their own keywords and namespaces that they use when interacting with target platforms. Given that, a standard method to interact with a target platform might be one which leverages the syntax established by DMTF’s SMASH CLP [3]. The typical CIM_BIOSAttribute associated with CLP expresses configuration data by using a “:” syntax. Given the previous example, one can imagine that a UEFI-based syntax could be expressed by having the xi-UEFI language equivalent value replace the value and the value would be UEFI"

The The x-UEFI configuration language is now a reality. The latest keywords can now be found at http://uefi.org/confignamespace.  This list should grow over time as more configuration data emerges based upon new platform technologies, features in the UEFI and other industry standards, etc.

This type of facility helps provide infrastructure to provide visibility into 'Is Features XYZ enabled." A common instance of this is virtualization technology, hyper threading, and other art managed by the platform.

Going forward, I can imagine OS viewer utilities, maybe /dev/hii in Linux and an associated Microsoft Windows interface, to exposing this information. The EDKII community on tianocore.org ought to investigate some simple shell applications to export the information, too.

Monday, February 8, 2016

Anniversary.next^4, life, death, and debug

I have been trying to maintain a tradition of blogging on my work anniversary http://vzimmer.blogspot.com/2015/02/anniversary-next-3-and-3-behaviors.html. Given that this is a firmware blog, I will try to craft some interesting message on firmware. But ahead of the bits and bytes, another year has led me to reflect on life. The first reflection occurred while taking the train into Seattle and hearkens back to my boyhood in Houston.

When I was in early elementary school during those humidity-filled hours, I remember a particular 'Go Western Day.' The teacher would have us each share our cowboy attire. One particular student always appeared decked out in the cowboy regalia and was quite enthusiastic about the rodeo that occurred this time of year. While we were milling about showing off our western gear, the school principal came to the classroom and whispered something in the teacher's ear. After the principal departed, the teacher gave the as-always excited student the feather out of her hat, which thrilled the student even more. He was beaming ear-to-ear. While riding that wave of glee, the teacher then told the student there was a message waiting for him in the office. After he left, the teacher told us that the student's mother had just passed away.

A first view at the stark dichotomies attending death - happiness and pathos.

Fast forward twenty years. My hiring manager and his manager from 1997 both passed away while on the job.  When the 2nd line manager had a memorial service at the work facility, his son showed up and said to us “I hope you enjoyed my father’s company since he spent more time with you than he did with us.”

Another dichotomy - the hard-driving world of technology and missed hours at home.

So this isn't what you visited this blog to read, I suspect. The page-rank, keyword filter undoubtedly chanced upon some terms such as 'UEFI' or 'debug.' Lest I disappoint, I will talk a bit about debugging firmware and some of the stark dichotomies there, too.

I recall hearing recently about various classes of bugs - hindenbugs, mandelbugs, heisenbugs, .... The first is a bug that makes the system go 'boom' like the Hindenburg.  The second is a bug that when solved leads to series of similar bugs, like exploring one of Mandelbrot's fractals. The final bug term is an homage to Heisenberg and his uncertainty principle wherein you cannot measure a particle's position and location at the same time - measuring one property will perturb the other. In the case of debugging, the act of debugging can often perturb the device under test (DUT).

How is a heisenbug related to debugging? One of the reasons this can occur is that host-based software debuggers, such as an implementation of the EFI_DEBUG_SUPPORT and EFI_DEBUG_PORT protocol, are done as drivers within the UEFI firmware. The former serves as a means to interact with a debug agent, or some entity that intends to provide a debug messaging channel to a remote debugger. The latter interface abstracts a simple messaging interface in the platform hardware, such as the USB debug port, to allow for sending messages using the respective debugger's 'wire protocol.' https://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool provides an example of the host based tools to install into Windows or Linux, and https://github.com/tianocore/edk2/tree/master/SourceLevelDebugPkg provides the debug agent code to build into the platform firmware.

For the debug agent, the source provides instance of using simple messaging hardware, such as a serial port and USB debug port. The way that the debug agent and the communications libraries that comprise the debug port protocol avoid heisenbugs, or interference with the rest of the system, is to make the libraries of type base, or self-contained code flows that do not depend upon other protocols or PPI's. This means that there is a better chance of observing failures in the rest of the system and not having the debugging infrastructure interfere with or perturb the rest of the services.

This non-interference property is important, but it can be aggravated when richer communications services are required, namely moving from simple serial interfaces to a richer network-based communications stack. To achieve debugging over a wider area network, it is appealing to consider using the extant UEFI working services and then applying the debug port abstraction atop the IP-based comms stack. The problem with this approach is that the debug agent is now intertwined with the network stack, has to follow the TPL calling restrictions of the latter, and may in fact induce errors based upon this interaction. The other approach is to use an isolated stack, such as that in a baseboard management controller (BMC) of a server, or duplicate the host networking stack with an independent one that has its own network interface controller (NIC) or somehow safely multiplexes uses of the primary NIC.

Again, this is tricky stuff. It is provocative trying to reuse the host firmware stack, but there is no 'free lunch', I fear. As such, the best approach is to have dedicated hardware like the USB debug port and a dedicated UART (with simple UART hardware or proxied to an embedded subsystem like the BMC or smart networking device) so that the debug agent can be coded without depending upon the full UEFI I/O stack running upon the host. This model of dedicated debug hardware will at least avoid one of the dichotomies in system software - debug observability and the behavior of the DUT.

Before I forget, if you are performing TCG Measured Boot https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_TPM2_Support_in_EDKII.pdf and you have the UEFI Debugger enabled, don't forget to record "UEFI Debug Mode" into PCR[7] https://msdn.microsoft.com/en-us/library/windows/hardware/jj923068(v=vs.85).aspx.

As for the the other dichotomies of life mentioned earlier, there is no simple answer, free lunch, silver bullet, or technology palliative http://bigthink.com/think-tank/ray-kurzweil-the-nanotech-revolution-will-bring-immortality (no offense Ray).