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

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

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

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

References
[1] Zimmer, "EDKII, FSP, and other topics", blog posting, September, 2014
https://firmware.intel.com/blog/edkii-fsp-and-other-topics

[2] Zimmer, "Firmware Flexibility using Intel(R) Firmware Support Package," Intel Developer Forum,
September 2014
https://firmware.intel.com/sites/default/files/SF14_STTS001_Intel%28R%29_FSP.pdf

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

[4] Intel Firmware Support Specification External Architecture Specification (EAS), Version 1.1a, November 2015
http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf

[5] Braswell EDKII project, April 2016
https://github.com/mangguo321/Braswell

[6] Wei, et al, "Open Braswell UEFI Codebase - Design and Porting Guide," February 2016
https://github.com/mangguo321/Braswell/blob/master/Documents/Open_Braswell_Platform_Designing_Porting_Guide.pdf

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

[8] Quark FSP 1.1, April 2016
https://github.com/feizwang/quarkfsp

[9] Quark SOC code
https://github.com/tianocore/edk2/tree/master/QuarkSocPkg

[10] Intel FSP2.0 consumer code, March 2016
https://github.com/jyao1/FSP2.0

[11] EDKII project www.tianocore.org

[12] Intel Firmware Support Package (FSP)
intel.com/fsp

[13] coreboot Braswell code that consumes Intel FSP 1.1, April 2016
https://github.com/coreboot/coreboot/tree/master/src/soc/intel/braswell

[14] SMI Transfer Monitor (STM) overview, August 2015
https://firmware.intel.com/blog/stm-updates
http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html

[15] STM Source code, March 2016
https://github.com/jyao1/STM

[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
https://firmware.intel.com/sites/default/files/STTS003%20-%20SF15_STTS003_100f.pdf

[20] STM 1.0 August 2015
https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip

[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
https://calendar.google.com/calendar/embed?src=6b1u8iq13jj8cp6kfokq4vlo20%40group.calendar.google.com&ct=America/Los_Angeles&dates=20160612/20160616&mode=agenda

[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
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

[28] Boot Setting File (BSF) Specification version 1.0, March 2016
https://firmware.intel.com/sites/default/files/BSF_1_0.pdf 

GUIDs, Revisions, Interrupts

This blog will cover a few topics, including GUIDs, Revisions, Hardware Interrupts, and Portable Libraries.

GUID versus Revision
To being, I was recently asked about how one should evolve a protocol interface. There are two ways to extend an interface, including: 1) have a revision field that designates if the service set or data has been extended, and 2) define a new protocol GUID.

The first technique will be familiar with some of the original EFI1.02 style API's, such as the EFI_BLOCK_IO_PROTOCOL and the various service tables, such as the EFI System Table, PEI Service Table in the PI specification, etc. For this technique, the service table or protocol can be extended in a back compatible fashion by appending new services to the end of the table while at the same time increasing the revision number.

This leads to a programming technique wherein the caller locates the protocol or service table and has to check the revision to see if the revision is greater than or equal to a number that matches the industry standard. An example of this technique in action includes the EFI_PEI_RESET2_SYSTEM in the recently published PI1.4 specification http://www.uefi.org/sites/default/files/resources/PI_1_4.zip. If a calling PEIM wants to use this service but also maintain portability across PI1.0 through PI1.3 conformant systems, the caller would only invoke the new PI1.4 service if PEI Service table revision greater than or equal to 1.40.

This first technique is required for the service tables, but for protocols the preferred extension method is to define a new GUID. Although the original EFI Protocols featured the revision field, and protocols like EFI_BLOCK_IO_PROTOCOL have been extended via the revision field, all other protocols have been evolved via new GUIDs. This can include the EFI_SIMPLE_TEXT_INPUT to the EFI_SIMPLE_TEXT_INPUT_EX change, but more often the growth is seen via appending a '2' to the original protocol, such as in EFI_LOAD_FILE2_PROTOCOL, EFI_DRIVER_DIAGNOSTICS2_PROTOCOL, EFI_COMPONENT_NAME2_PROTOCOL, EFI_FORM_BROWSER2_PROTOCOL, etc. These can be found in the UEFI 2.5 specification http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf.

The nice thing about the second technique is that the caller doesn't have to do the cumbersome revision check, PI variants can include the proper name in the dependency expression, and API bug fixes can span all of the services. In addition, the producer of the protocol can produce the original and '2' variant quite easily by sharing implementations of the common services in a single driver.

Windows has done a similar evolution of its API's, although it often appends 'Ex' to designate the new API. Examples therein include IoConnectInterrupt https://msdn.microsoft.com/en-us/library/windows/hardware/ff548371(v=vs.85).aspx to IoConnectInterruptEx https://msdn.microsoft.com/en-us/library/windows/hardware/ff548378(v=vs.85).aspx.

Hardware Interrupts
Speaking of hardware interrupts, the question of hardware interrupt usage in UEFI has been brought up http://sourceforge.net/p/edk2/mailman/message/28764215/ many times since the roll out of EFI 1.02 in 1999.

It turns out hardware interrupts are used in UEFI, including at least the hardware timer tick. But as table 22 of the UEFI 2.5 specification notes, the system may choose to implement "firmware interrupts" between TPL_NOTIFY and TPL_HIGH_LEVEL.

The table says "This level is internal to the firmware."

This means that the firmware must adhere to the TPL mapping in the specification in order to maintain interoperability, viz.,

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

but nothing stops a given underlying UEFI implementation, such as one based upon PI DXE that also uses TPL's, to define

#define  TPL_DEVICE_1                 18
#define  TPL_DEVICE_2                 20
#define  TPL_DEVICE_MAX         28

And if you look at the DXE core implementation, a TPL level is really just a linked list. So the way that a hardware interrupt protocol driver could be implemented would be to use the CPU architectural protocol to register interrupt service handlers (ISRs) with the SOC, using something like a programmable interrupt controller's priorities to map TPL_DEVICE_1 to lower priority devices and TPL_DEVICE_MAX to higher priority. Think low-speed consoles like a UART to the former and a high-speed networking device to the latter.

The implementation of the ISR would be similar to the top half http://www.makelinux.net/ldd3/chp-10-sect-4 of a Linux driver, namely just enough code to quiesce the device that triggered the interrupt and then signalling an event to invoke a lower TPL handler, or something like a bottom half of a Linux driver. Another technique is to invocation of a Deferred Procedure Call (DPC). The motivation for the DPC-like logic is to do most of the long-lived processing at a lower TPL than the interrupt in order to allow for other activity to be interleaved and to have the richer service set of a lower TPL, as shown in the Table 23 "TPL Restrictions" of the UEFI 2.5 specification.

In fact the EDK II implementation has a DPC implementation https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/Dpc.h. This is a useful API that may one day go to the UEFI specification, just like the useful PI interfaces of the LockBox https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h and Variable Lock Protocol https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h would help interoperability by joining a future PI specification.

So we see that the plumbing is in place to have hardware device interrupts, but the reason that a UEFI specification conformant driver cannot depend upon hardware interrupts, beyond the implicit timer tick for the timed event services, is that the DEVICE TPL mapping above is not codified by the UEFI specification. Each vendor may provide different TPL mappings for the range between NOTIFY and HIGH_LEVEL. In addition, there is no API like IoConnectInterrupt which abstracts the use of TPL's and managing of the IO interrupt controller from a given UEFI implementation to a portable UEFI driver.

This doesn't stop a vendor who provides the full UEFI implementation, such as a EDK II-based DXE core and platform drivers, from providing this capability and a customer interrupt protocol, of course. You could also retrofit an existing polled UEFI driver to be modal, namely have the driver entry point looks for the platform interrupt protocol and register an ISR if it exists, and if it doesn't default to the existing polled behavior that is most broadly compatible.

And given that EFI has been shipping for the last 15 years with the present polled driver model, there is some question as to whether hardware device interrupts are necessary. For boot scenarios where the pre-OS is typically doing a single activity, such as accessing an I/O device, the polled model suffices. When there are performance concerns, the system designer can vary the system timer tick, sometimes going as low as 1ms for the timer period in order to service the device actions. Today, performance sensitive drivers like the Pxe basecode driver aggressively poll the underlying network API's in order to maintain line-rate.

The only cracks in the armor for this model appear when different I/O stacks interact. For example, if we are performing a network download into a memory buffer, only the networking stack is in play. But if the networking download interleaves packet transition with writes to a durable storage media, then the networking stack and file system storage stack compete for resources. This is an area where the polled model can observe system performance challenges.

As we enhance the scenarios with the recent UEFI HTTP API's and other capabilities, it will be fun to watch this space.

Even OpenFirmware 1275 didn't drive their network stack with the Forth FCode but instead it used native code NanoKernel http://www.physik.uni-regensburg.de/strongnet/documents/STRONGnet2010/schick1.pdf

Libaries
Speaking of spaces to watch, another area that interests me is portable libraries. Specifically, the MdePkg of EDK II has different library classes, including 'base'. The nice thing about a library of type base is that I can use the code in PEI pre-memory, PEI post-memory, DXE, DXE SMM, UEFI boot service, UEFI Runtime, and SEC. You can see from the last sentence that firmware programming in the UEFI PI world is pretty challenging. There are seven regimes to write code, and business and technical reasons sometimes dictate moving code from one area to the other, such as re-using the UEFI FAT driver to create a PI recovery PEIM to load a recovery FV from disk, or moving SI code from DXE to PEI for purposes of creating an Intel (R) Firmware Support Package (FSP) binary http://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.

Beyond the UEFI PI world, imagine having a routine that does error handling, such as the Reliability, Availability, and Serviceability flows that a server designer might want to migrate from SMM http://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf to a system service processor/baseboard management controller (BMC). If these error management flows had their core logic implemented as libraries, then the movement from the host processor to the non-host processor environment would be much easier.

The business value is the fundamental logic in the C code, not the syntactic sugar around the code to make it a SMM driver or a service processor task in the RTOS/process in the OS.

TXT and UEFI Secure Boot & Measured Boot
We just left left off talking about adjacent technologies of UEFI PI and service processors. Another adjacent and quite complementary technology includes UEFI PI and Trusted Computing, including Intel(R) Trusted Execution Technology (TXT). I sometimes get asked about this so I thought that I'd spend a couple of moments on this topic I gave a quick overview of UEFI Secure Boot and Measured Boot using a Trusted Platform Module (TPM) on open hardware at http://firmware.intel.com/blog/security-technologies-and-minnowboard-max, but I omitted TXT since this open platform's Intel Baytrail CPU doesn't support those extensions. For hardware that does support TXT, such as Xeon class CPU's and client VPro, though, the relationship bears mentioning.

If you do the reference chasing on the latter link, though, you'll see that the UEFI Secure Boot and the Static Root of Trust for Measurement (SRTM) are a blended scenario, with the latter using the non-resettable, static PCR's 0..7 for the pre-OS, and PCR's 8..15 for the OS. This scenario can co-exist with TXT, such as in slide 10 https://01.org/sites/default/files/openstacksummit_vancouver_trusteddockercontainers.pdf where the "BIOS" here is the early PI code that loads SMM, and the latter BIOS with option ROM's falls under the purview of UEFI Secure Boot. T-Boot is a type of Measured Launch Environment (MLE) https://www.kernel.org/doc/Documentation/intel_txt.txt and using SENTER instruction will activate measurement into the resettable PCR's above PCR15. As such, it provides a Dynamic Root of Trust for Measurement (DRTM) alongside the SRTM. And for purposes of attestation, having more platform elements in the attestation vector provides a richer management experience.

In fact, Bill and I described blending of these various technologies on server class systems 2.5 years ago http://firmware.intel.com/sites/default/files/resources/Platform_Security_Review_Intel_Cisco_White_Paper.pdf. There is a also a TCG-defined API to abstract the DRTM launch, as described in http://www.trustedcomputinggroup.org/resources/drtm_architecture_specification, although few systems publish this interface today as far as I know.

In memory
Enough on GUIDs, libraries, and interrupts. I'd like to close this blog with a more personal thought.  I had written a small message about my friend George Cox last June http://vzimmer.blogspot.com/2014_06_01_archive.html upon hearing about his retirement. Fast forward a year and I was saddened to see the message of his passing at https://twitter.com/fortnow/status/602872182579015681

 

Lance Fortnow‏@fortnow

George Cox, Intel Security Architect, passed away yesterday.

George was a great friend, technologist, and mentor. The picture below shows George as I remember him best, teaching a technical concept and interacting with others.

Good-bye friend.  You'll be missed.

Vincent

Anniversary .next ^3 and 3 behaviors

Today marks eighteen years in my Intel journey, so I am keeping up the tradition of writing a blog entry on this day, as started with http://vzimmer.blogspot.com/2012/02/anniversary-day.html. The title exponentiates '.next' versus '.next.next.next'-style usage. This makes me eligible for a half-sabbatical, too. Since the last posting I've firmly moved into the new Seattle office. Below is a picture of the facility from across the street. It is located in south Seattle, adjacent to the International District.

I managed to get a cube-with-view, too.

The view also affords me a vantage in case of an invasion https://twitter.com/vincentzimmer/status/565562482383527936

So with a new office and work anniversary afoot, I will continue my blogging tradition. I'll begin with a few thoughts on being an engaged engineer. These sentiments include:

1. Being present

Even before chancing across http://www.forbes.com/sites/ellevate/2015/02/20/why-face-to-face-meetings-are-so-important/ this evening, I have always believed in face-to-face engagements in the workplace. Although I've always worked at a remote site, namely WA-state Intel, I purposely go out of my way to visit the larger sites, such as Intel in Hillsboro, OR, or the headquarters in Santa Clara.

It's imperative to have such meetings early in an engagement so as to build rapport, and then possibly maintain the relationship remotely for subsequent collaboration. Showing up demonstrates that 'you care' and that the other person 'matters.' Nothing can substitute for these gestures.

Also, having badged into five Intel sites across three states during the preceding four-day-week  using plane, train, and automobile, I have recently practiced what I'm preaching on this topic.

2. Saying you don't know

A colleague in Oregon last Thursday suggested I treat this topic, although I've opined on it before. So here goes.

Another behavior I've observed includes reluctance of many technical leader to say "I don't know." Not having the immediate answer is OK. Just commit to following up and supporting the party. Feigning understanding doesn't help your standing with the other party or the overall business goals.

The technology and business landscape changes constantly. Strictly speaking it's impossible 'to know' everything.' But it is possible to keep and open mind, customer-oriented disposition, and desire to 'learn.'  Let an occasional 'I don't know' help fuel the fire of curiosity and pedagogy.

I've touched on the former two items in past blogs, but I have yet to treat the next topic.

3, Ownership

In general, ownership can be powerful in that it highlights the party culpable for furthering a business or technical agenda. Recently, though, I've seen the dark side of ownership. For example, in some discussions people will assert "I own that." This is a variant of the logical fallacy of argument from authority in that the act of ownership is posited in lieu of providing other data, such as results.

Instead of 'ownership', I am more of a fan of 'helping lead,' 'coordinate', 'drive'. What matters is the business result. None of us truly 'own' anything in the company. The upper management, and reductio ad absurdum, the stockholders, 'own' the company. We are entrusted as employees, and especially as technical leaders, to drive a goal.

On the flight Friday morning, a senior manager gave me a nice definition of a leader. Minimally, a leader must 'have followers' and 'make changes.' I'd say that's necessary but not sufficient. Sufficiency may include a qualification of change such that it is 'conducive to the growth of the business,' and followers who 'grow and advance in their careers' as a result of the interaction. Good stuff.

So next time I hear "I own X," I'd rather hear "This is what we've produced with X."

So speaking of X's, let's talk about security and open source.

On the security front, I don't want to say too much other than note that I'll be speaking at CanSecWest (CSW) next month https://cansecwest.com/post/2015-02-01-11:00:00_Speaker_Announcements. The title of my talk, "UEFI, Open Platforms, and the Defender's Dilemma", sums up my thoughts on platform security.

To begin, let's dissect the title. The first portion of the title UEFI provides mechanism, such as many of the technologies found on http://www.tianocore.org and also recent write-up's like http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf.

The next portion of the title Open platforms provides a great opportunity to demonstrate a reduction to practice of these technologies, with a goal of demonstrating the design intent of the specifications in bits.

Finally, the defender's dilemma element of the title will review the relative asymmetry of platform defenders to the attackers. The cardinality of the attack presentations at this conference, namely 3 offense UEFI talks, to my 1 defense talk, brings this home. In fact, I represent one of the few defense talks hosted to be found in this conference series.

So let's get to the mapping of our three behaviors to the elements of the title. I will present in person so I get a check-mark on #1 of Being Present without much fan fare. On the topic of saying I don't know, I will not take the posture of being the omniscient guru of firmware. Instead, I want to enjoin the researchers in a dialogue, learning from them as much as I might be teaching. And I may up uttering those 3 humbling words more than I'd like. Finally, I would never claim to "own" platform security. There is a rich community of security professionals with whom I have the honor of working in the UEFI forum, open source community, and as professional colleagues. We all collaborate on providing a solution. I might lead in some venues, such as the UEFI Forum, but I am loathe to ever say I 'own' this topic area.

So that's for CSW next month.

Another application of these 3 behaviors to an X an include open source and open platforms. I've talked in the past about how thing like Intel(R) FSP can support various open source ecosystems and my excitement around Intel(R) Quark-based platforms like Galileo having open sourced their EDK II implementation. I also noted in my Intel Developer Forum 2014 talk that a book was coming. Well, the book Embedded Firmware Solutions: Development Best Practices for the Internet of Things has been published and can acquired via http://www.amazon.com/Embedded-Firmware-Solutions-Development-Practices/dp/1484200713/ or http://www.apress.com/9781484200711.

An interview with the authors was also recently posted, too http://www.se-eng.com/2015/02/authors-of-embedded-firmware-solutions-include-key-industry-architects-of-open-solutions/.

I am a believer in collaboration, too. This book adds Google and Sage to the list of companies with whom I've publicly presented and co-authored material. Examples can be found at https://www.linkedin.com/in/vzimmer and includes AMI, Cisco, Dell, HP, IBM, Insyde, Intel, McAfee, Microsoft, NICTA, Phoenix, SuSE, Toronto.

So how do the three behaviors map to this topic? The easiest to answer is 'being present.' In the earliest days of Intel FSP and this book I had the opportunity to meet my colleagues in Mt. View, San Jose, and San Francisco. In this various venues I helped forge a relationship that evolved remotely, but the pioneering engagement was face-to-face.

And on the topic of "I don't know", I have to cite the spate of libre boot emails I received internally and externally in the wake of announcements like http://www.fsf.org/news/libreboot-x200-laptop-now-fsf-certified-to-respect-your-freedom. I don't know the extent to which the various business partners can open, but I'm always open to learn about the various viewpoints and desires of the ecosystem. But I do believe in more openness and transparency, just as 'open' is in my CSW title and talk, and the book above talks about 'open' solutions.

And finally, I don't 'own' open source firmware and platforms at Intel. I am luckily to have spent the last 15+ years on a team that has been open sourcing reference implementations of industry standards and firmware. We recently posted some elements of http://firmware.intel.com/projects/minnowboard-max to http://www.tianocore.org, such as https://github.com/tianocore/edk2/tree/master/Vlv2DeviceRefCodePkg and https://github.com/tianocore/edk2/tree/master/Vlv2TbltDevicePkg. These packages, and the ability to absorb Intel FSP binaries from http://www.intel.com/fsp, along with the more granular source plus binary builds, shows progress toward more open platforms in this community.

So that's about it for the inaugural blog of 2015. I've marked a work anniversary with a blog three-years-running on this date, I discussed three behaviors, and finally, I mapped those three behaviors to two case studies.

I have been invited to co-present at the Open Compute Summit http://www.opencompute.org/community/events/summit/ocp-us-summit-2015/ next month, too. I should have conjured up a 3rd case study on this topic area of "firmware and Cloud" challenges" to have a 3-3-3 balance in the former paragraph, but work beckons and time to close up this entry.

Have a safe and happy rest of 2015 to all.

Regarding a prediction for 2015

Given it is the final day of 2014, I thought that my final blog of 2014 would treat the year.next which commences in a few hours, maybe with another one of my infamous TL:DR-style postings? Specifically, I'd like to build upon missive from Tim Lewis at http://uefi.blogspot.com/2014/10/security-to-eclipse-user-features-as.html wherein he shared his belief that security concerns in the platform firmware will predominate as the top user story of 2015. Given the sampling below from 2014, he may be observing an unenviable trend line.

Regarding that trend, there have been talks at several venues in 2014, such as the Black Hat (BH) talks a few months ago https://www.blackhat.com/docs/us-14/materials/us-14-Kallenberg-Extreme-Privilege-Escalation-On-Windows8-UEFI-Systems.pdf. This talk had an associated CVE http://www.kb.cert.org/vuls/id/552286 and white paper https://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation.pdf.

In addition, just this week there were a couple of talks featured on UEFI at the Chaos Communications Conference (CCC), including https://www.youtube.com/watch?v=5BrdX7VdOr0 and the associated presentation https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf
by researchers from Bromium and Mitre, respectively.

The other CCC talk was on EFI and Thunderbolt https://www.youtube.com/watch?v=5BrdX7VdOr0. Glad to hear from the Matthew Garrett question to the presenter near the end of the talk that the option ROM vulnerability could have been mitigated if the Apple platforms implemented UEFI Secure Boot with option ROM verification (i.e., UEFI Driver Loading) enabled.

These security events and broad use of UEFI and edk II-based platforms definitely argue for the need to have additional industry coordination. This is a role that CERT has done admirably, but as Tim noted, they are now joined by the UEFI Security Response Team (USRT) http://www.uefi.org/security. This effort has been followed by a more code base-specific effort, too http://tianocore.sourceforge.net/wiki/Security. I am happy to be involved in both and although my CVSS-Fu isn't too evolved yet, I'm trying my best in writing technical advisories and doing the associated grading.

It is interesting that the references for both BH and CCC  https://www.youtube.com/watch?v=5BrdX7VdOr0 talks above cite the Intel Framework Specifications at www.intel.com and not the superseding UEFI Platform Initialization (PI) specifications http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. This might contribute to some of the ambiguity seen in the boot script implementations, for example, noted in the CCC talk, since the Intel Framework specifications are frozen after having been contributed to the UEFI Forum. Maybe posting a ZIP of the PI specs and a PDF of the Framework makes the latter more search-engine friendly?

For the CCC talk https://frab.cccv.de/system/attachments/2557/original/AttacksOnUEFI_Slides.pdf, it was good to see that slide 53 mentions the work done with my Intel colleague

      [11] A Tour Beyond BIOS:
      Implementing S3 Resume with EDK2 –JiewenYao and Vincent Zimmer,
      October 2014

Jiewen and I designed features like the Lock Box protocol https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h to allow for protecting the boot script memory, via SMM or other container, back in 2009. But issues in seeing the protections deployed are compounded by the sheer difficulty in implementing S3 resume in platforms. Specifically, getting the functionality correct and having less-easily testable properties like securing the boot script has proven challenging. As a platform developer the last call you want to hear during product development is from the SQA team, saying "Everything works great, but our S3 resume testing fails once out of 10,000 times."

The above S3 document represents part of an effort to document some of the design intent on edk II source artifacts. We already have architectural intent documents such as http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf (including the companion talk https://www.youtube.com/watch?v=lZ505uz1TZ4).

Regarding other defenses, in the S3 talk Corey also mentioned the "SMI Transfer Monitor" (STM). Corey's co-presenter Rafal discusses the STM in more detail at http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf. This is also mentioned in CCC 2013 talk http://events.ccc.de/congress/2013/Fahrplan/system/attachments/2266/original/Gal_Diskin_-_Virtually_Impossible_-_30C3__release_version_.pdf by former Intel researcher Gal Diskin.on slide 13. Chapter 13 of Grawrock's 2nd edition of Safe Computing http://www.amazon.com/Dynamics-Trusted-Platform-Building-Approach/dp/1934053171 also describes this feature. The gist of the STM is that it represents a usage of the peer-monitor capability in IA32, a hardware feature defined in chapter 34.15 of the Intel Software Development Manual (SDM) https://www-ssl.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html. There is a nice peer monitor overview at http://virtualizationtechnologyvt.blogspot.com/2011/07/vmx-and-smm-dual-monitor-mode.html. The use of the peer monitor, which is essentially virtualization controls in System Management Mode (SMM), allows for de-privileging today's ring 0 SMM code, such as that built responsive to the infrastructure in volume 4 of the PI 1.3 specification http://www.uefi.org/sites/default/files/resources/PI_Spec_1.3.zip. So when Corey said "where is the STM specification?", he was referring to the firmware convention for loading the STM, interaction with Intel TXT, and how to expose resource lists for which the guest SMM code can access. This class of firmware interaction is the "STM specification" and it is built upon the hardware specifications of the peer monitor virtualization capability treated in the SDM. The SDM is the bible for software-visible parts of IA32, i.e., the 'architecture.' The SDM hasn't changed over the last decade plus, whereas the STM specification has, er, evolved. 

I have spent quite a bit of time on SMM over the last decade plus, from having defined the Framework SMM CIS http://www.intel.com/content/www/us/en/processors/itanium/efi-smm-cis-v09.html infrastructure http://www.google.com/patents/US6848046, from which the present PI 1.3 SMM design has been derived, to collaborating on peer monitor and STM work. I'm a big fan of isolation technologies and trusted computing, but I'll have to pause here for this 2014 entry on this topic. If I were a smarter guy I would follow in the foot-steps of Fermat's Last Theorem and claim to have the final proof of solving the SMM security issues but excuse myself for today by noting that the answer is "too large to fit in the margin" of this blog http://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem.

Just as a document cannot replace well commented codes, having more executable methods for assurance are always preferred. These include efforts such as the CHIPSEC work https://github.com/chipsec/chipsec which I also describe in http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw. These tests are run after boot and provide an a posteriori view of the platform.

More recent technology includes having security testability in-situ with the platform, versus a CHIPSEC style post-boot test, and reporting the results. This type of test and reporting capability was mentioned in 2013 at http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf and now has a public specification realization at  http://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx (HSTI) This work bridges the semantic gap historically faced by platform builders wherein the various system requirements in a Windows Hardware Certification document, such as http://download.microsoft.com/download/7/0/E/70E74967-B0FE-477A-974F-C1ED16EE31DF/windows8-1-hardware-cert-requirements-system.pdf, can now have a companion reporting channel. Examples include injunctions in System.Fundamentals.Firmware.UEFILegacyFallback, such as

"An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships with a UEFI-compatible OS. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded."

These Compatibility Support Module (CSM) behaviors are something that only the platform implementation can deduce and are difficult to detect via a later test, although heuristics like scanning 0xC0000p through 0x100000p in the address space 'could' be done.

The HSTI interface builds upon the Adapter Interface Protocol (AIP) class of structure defined in the UEFI 2.4 specification http://www.uefi.org/sites/default/files/resources/2_4_Errata_A.pdf. Since AIP producers are boot service only, a pre-OS agent needs to query the HSTI interface in order to cull the settings and convey the results into the operating system run time, if needed, in a vendor-specific fashion.

Related work to HSTI that goes beyond mapping to Windows requirements include the ability to report BIOS Integrity Attributes, as described in http://csrc.nist.gov/publications/drafts/800-155/draft-SP800-155_Dec2011.pdf in 3.2.1.1. And in order to surface this information, we defined in http://www.trustedcomputinggroup.org/files/static_page_files/D4268663-1A4B-B294-D05DE87EE90558B6/TCG_EFI_Platform_1_22_Final_-v15.pdf the following:

    typedef struct {

       UINT32 VendorId;

       EFI_GUID ReferenceManifestGuid;

    } TCG_Sp800-155-PlatformId_EventStruct

This structure can be used to reference an off-machine Reference Manifest (RM). The idea is that the GUID in the structure above would be specific to a vendor, model, and firmware instance in a XML-based manifest document on the platform suppliers website. The schemas are defined in http://www.trustedcomputinggroup.org/files/resource_files/73638609-1A4B-B294-D0902CC2A13C8697/Reference_Manifest_Schema_Specification_v2.0.r5.pdf, so now it's a set of work items for the industry to map the RM's to platform attributes, such as mentioned in 155.

Who knows, at some point maybe these reporting and testing efforts will all align?

Well, if you have gotten this far, the 'Didn't Read" portion of "Too Long, Didn't Read" (TL;DR) hasn't been the case for you. I'm not sure whether to reward you for your stoicism or not for wading through this entry.

To summarize, 2014 has shows a spate of security-related activities, both by the attackers (BH, CCC) and the defenders (USRT). The firmware-producing and consuming community is acutely aware of assurance concerns and new testing methodologies have been deployed in '14 and are coming in '15, too, including HSTI. I don't necessarily subscribe to the 'Spy versus Spy' aspect of security, or fall into existential angst that the "Defenders Dilemma" is not solvable. Instead, I see many parties passionate about having robust, usable systems and collaboration on art to achieve those goals. Open source, open documentation, open specifications, open platforms,.... All help in the cause.

And if you're still working these last hours of today, pause and have a coffee.

Also, enjoy a happy and safe new year.

Cheers,

V.Z.兹梅

"So Long, and Thanks for All the Fish"

Yesterday my last day in DuPont after nearly 18 years, 15 of those in the same cube, here at this WA Intel site. Off to work at the Seattle office in early '15. So long, DuPont, and thanks for the memories. And all of the Fish, although in this case 'Andrew Fish.' Although Fish doesn't work at Intel any longer, the inventor of the "Intel Boot Initiative" (IBI), which became EFI/UEFI, still lives in the South Puget Sound. We broke bread for the final time at our favorite local restaurant.

This is the "R&R" mentioned in the acknowledgements section of the 2nd edition of Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, "Also many of this team will recall over ten years of "design discussions" at R&R." I captured Fish on the left and Mark Doran http://newsroom.intel.com/community/intel_newsroom/bios?n=Mark%20S.%20Doran&f=searchAll on the right eating our final Teriyaki bowls. As always, good conversations on firmware and technology. And the picture is also epic in that the duo often introduces itself as "Andrew Fish who invented EFI, and Mark Doran who delivered it to the industry."  Mike Kinney & I held down the other side of the table. I've learned quite a bit working with all three of these colleagues over these many years.

During my final days at Compaq in late 1996 I talked to Intel about joining, and my options were "Join Portland for Xeon, or DuPont for Merced." I was inspired by the thought of joining the 64-bit revolution, so there was no doubt in my mind as to which locale to choose.  Also, having grown up in Texas, the Pacific Northwest was a large unknown, so the distinction between OR and WA didn't even factor into my decision.

And my whole tenure at Intel in DuPont since February 1997 has been boot firmware.  I began with a PC/AT BIOS underneath the Merced System Abstraction Layer (SAL), with the original OS loader interface of SAL_PROC (0x13), as a 64-bit mapping of BIOS 13h.  Same for video mapping of SAL_PROC (0x10), keyboard of SAL_PROC (0x13), etc. The OS community wasn't amused.

As the OS interface evolved to C-based IBI, then EFI, the underlying boot infrastructure changed. I moved from driving some of the SAL-on-BIOS for server (aka "FrankenBIOS"), to the short-lived Workstation Product Division (WPD) where we evolved a C-based boot solution. The latter pioneered art such as the Furball and interposer, which were the predecessor of the Intel Framework Compatibility Support Module (CSM) and CSM16 binary.  We called the former 'furball' because it was something we imagined a native 32-bit (IA32) and 64-bit (Itanium) firmware solution would eventually 'cough up', with a less than pleasant imagery derived from the world of cats.

In 1999 we had evolved the workstation firmware to binary modules called "Plug-In Modules", or PIM's. I recall a fateful meeting with the lead on that effort and my colleague visiting from OR. The conversation went something like 'And we can also put the PIM's into option ROMs, too.' At that point I realized the trajectory was ill-fated since the problem with open platforms and option ROM's isn't factoring code to run in that storage container so much as 'how' to interoperate with the system firmware, namely what API's to expose, where to define them, and how to evolve this art. And to that end, I realized that EFI would win as it was the only man standing to solve this problem.

Specifically, EFI nailed down the interface methodology to the OS loader and option ROM community where the broad interoperability was needed.  Moving the underlying initialization firmware to a new methodology, such as what became Intel Framework and then UEFI PI was valuable, but not the necessary first step.  The first step was to lay the foundation for broad interop in order to have time for the top-level OS and IHV ecosystem to start moving their dependent infrastructure.

At that point in my career when I had that realization, I was lucky enough to have a friend and Intel colleague like Andrew Fish who suggested I have lunch with Mark Doran.  Afterward I on-boarded to the EFI team in 1999 and the rest has been a great 15 run on helping evolve EFI into UEFI, EFI-on-BIOS into Framework and then UEFI PI, and the open source offering from "EFI Sample" to EDK to today's EDK II.  Since then a lot of code and specifications have ensued

with hopefully more to come in 2015+.  Not sure if there is another 15 years into the run.  Although one co-developer of Tiano, the code-name for the underlying Framework (and now PI work) quipped a few years ago "We said Tiano was the '20 year' BIOS replacement solution, so when did you start counting?"

Speaking of 2015+, I had better get back to work if I want to get a head start on the next way of the firmware revolution started in South Puget Sound, WA.

Cheers