Tuesday, August 18, 2015

SMI Transfer Monitor (STM) Unleashed

I'm happy to announce today that the SMI Transfer Monitor (STM) documentation and code have been released today. This aligns with my Intel Developer Forum (IDF) presentation "STTS003 - Developing Best-in-Class Security Principles with Open Source Firmware." that is now available from http://www.intel.com/idfsessionsSF.

The information can be found at https://firmware.intel.com/content/smi-transfer-monitor-stm and includes the source code of: 1) the STM, 2) a small virtualization pre-OS agent for launch/test, and 3) platform code to adapt the STM on a MinnowBoard Max platform. All of these elements are built using EDK II https://github.com/tianocore/edk2 technology.

The flow of the STM to virtualize a system management interrupt (SMI) can be seen in the figure below from my IDF presentation.

The STM is ideally suited to work with a Intel (R) Trusted Execution Technology (TXT) launch, but the recently released specification includes chapter 12 of https://firmware.intel.com/sites/default/files/STM_User_Guide-001.pdf https://www.intel.com/content/dam/develop/external/us/en/documents/stm-user-guide-001-819978.pdf for a VT-only usage. This allows for investigation and research around this technology on any system with Intel Virtualization Technology (VT) support, such as MinnowBoard Max https://firmware.intel.com/blog/security-technologies-and-minnowboard-max.

We created a companion document https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf https://www.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching-stm-to-monitor-smm-in-efi-developer-kit-ii-819978.pdf to describe the reference implementation https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip. This document was written in the spirit of our other "Tour" documents that dive into various implementation choices https://firmware.intel.com/blog/beyond-bios.

This is a preview release of the code that matches the 1.0 specification. Longer-term we intend to migrate this capability to the http://www.tianocore.org open source firmware community, especially given the fact that the STM is intended to be integrated within the firmware. Some of the choices in the preview release included duplicating some of the EDKII base library so that the STM can be produced only by using code within the STM.zip. Going forward it may make sense to use the existing MdePkg code, possibly accreting more virtualization-specific functions, for example.

This EDKII usage on MinnowBoard Max represents only one design integration choice, too. The STM specification and resultant STM binary derived from the source code could be integrated into a EDKI, PC/AT or coreboot-based platform initialization code. The STM binary would interact with EDKII PI, PC/AT, coreboot, or other system board firmware via the interfaces defined in the 1.0 STM User Guide.

There are some other interesting announcements from IDF that I will blog about later, including exciting advances in network boot. For now, though, take a look at the STM specification and code. Any feedback will be appreciated, too.

Saturday, August 1, 2015

EFI Byte Code

This short post will provide some history around the EFI Byte Code (EBC). There were some interesting questions around this at http://www.blacklodgeresearch.org/archive/defending-uefi-tools-lab-july-19th-2015/
BLR would like to thank for braving the heat and teaching us about the UEFI security model today. Thank you Vincent!
As such, I thought that I'd take both a trip down memory lane and provide some forward-looking thoughts, too.

The quick background is that EBC is intended to allow for writing a single binary UEFI driver that will work on a broad class of system boards supporting different native instruction set architectures. ARM interest in this capability was recently discussed at a UEFI event http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_May_2015_ARM.pdf, for example.

To begin, EBC is a software virtual machine described in the UEFI 2.5 specification http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf, with the Instruction Set Architecture (ISA) in Appendix J and the virtual machine architecture defined in chapter 21. The idea is that C coded UEFI drivers can be compiled into the EBC ISA and linked into a PE/COFF https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx image with a subsystem type of IMAGE_SUBSYSTEM_EFI_BOOT_ SERVICE_DRIVER and Machine Type of IMAGE_FILE_MACHINE_EBC. This is distinct from native mode UEFI images that are typically IMAGE_FILE_MACHINE_AMD64/I386/IA64/ARMNT/ARM64 for the x64/IA32/Itanium/32-bit ARM/and Aarch64 native CPU bindings in the UEFI specification today (in chapter 2). The Microsoft Linker will provide these image types, but today only the Intel EBC compiler https://software.intel.com/en-us/articles/intel-c-compiler-for-efi-byte-code-purchase will generate the images.

The above description defines what the producer of the code needs to do, namely compile and link the driver C sources using the above tools. On the consumer side, the idea is that the EBC-formatted image will be located in the non-volatile storage (option ROM container) of a host-bus adapter card, such as the Peripheral Component Interconnect (PCI) http://pcisig.com/specifications. The PCI specification designates types of option ROM's, such as UEFI, PC/AT, or FCode open firmware. The underlying UEFI firmware on the system board with the PCI slots can optionally contain the EBC interpreter, such as the DXE driver variant at https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/EbcDxe/EbcExecute.c. The interpreter will be invoked after the image loader discovers, potentially authenticates via UEFI Secure Boot, and relocates the image into memory. One interesting thing that the interpreter has to do is create 'thunk' sections for instances of the EBC ISA calling the native ISA:

  // Create a thunk for EBC code. R7 points to a 32-bit (in a 64-bit slot)
  // "offset from self" pointer to the EBC entry point.
  // After we're done, *(UINT64 *)R7 will be the address of the new thunk.
  case 5:
    Offset            = (INT32) VmReadMem32 (VmPtr, (UINTN) VmPtr->Gpr[7]);
    U64EbcEntryPoint  = (UINT64) (VmPtr->Gpr[7] + Offset + 4);
    EbcEntryPoint     = (VOID *) (UINTN) U64EbcEntryPoint;

    // Now create a new thunk
    Status = EbcCreateThunks (VmPtr->ImageHandle, EbcEntryPoint, &Thunk, 0);
    if (EFI_ERROR (Status)) {
      return Status;

    // Finally replace the EBC entry point memory with the thunk address
    VmWriteMem64 (VmPtr, (UINTN) VmPtr->Gpr[7], (UINT64) (UINTN) Thunk);

Note:  Please no flames on the coding fragment. The CamelCase adheres to the coding standard more reminiscent of Windows Kernel Drivers http://tianocore.sourceforge.net/wiki/Code_Style/C that is distinct from the Unix-like Indian Hill http://www.cs.arizona.edu/~mccann/cstyle.html found in Linux and coreboot. To me the particular coding style is less important than both having and enforcing one for a given project.

The EBC ISA is a very simple load/store architecture with a strongly ordered memory model. It is not intended for high performance as much as lending itself to a small, simple interpreter architecture in order to minimize code space in the system board flash, and it features a relatively concise encoding, which ends up being slightly larger than a IA32 CISC encoding and smaller than a Itanium VLIW style encoding. The ISA also does not carry type encoding information like the Java Virtual Machine Language (JVML) since the EBC ISA is intended to be transformed from the type weak C language, versus the JVML supporting the type-safe Java Source Language.

What do they say about programming in C code?  It's like smoking a cigarette in a swimming pool full of gasoline. OK, enough of the jokes and back to the blog.

What the EBC ISA supports, though, is a concept from the UEFI Specification and the associated C sources of the 'natural integer.' The unsigned and signed natural integer, or UINTN/INTN, is the size of the VOID* of a particular native ISA. So if an EBC image is executing on a 64-bit x64 machine, sizeof(UINTN) is 8, namely 8 bytes, or 8*8 = 64 bits. Similarly, the EBC image on an IA32 machine has a sizeof (UINTN) as 4. Since the target UEFI driver's C code is compiled into a synthetic EBC ISA stream for the IMAGE_FILE_MACHINE_EBC path, the actual 'sizeof'' operation in the UEFI driver becomes a service that yields 4 on 32-bit machines and 8 on 64-bit machines. This support of naturally sized integers is something that most C compiler back ends do not support, thus the reported difficulty in creating a GCC https://gcc.gnu.org/onlinedocs/gcc/ back-end for EBC ISA, as reported by some compiler experts back in the early 2000's when EBC ISA was invented to support the EFI 1.10 driver model. At the time, the challenge was to support the two native ISA encodings in the EFI 1.10 specification - IA32 and Itanium - whith a goal to have single UEFI drivers from the Independent Hardware Vendor (IHV) Host Bus Adapter (HBA) PCI boards that would work on client IA32 and server Itanium systems.

Fast forward to 2015 from the circa 2001 creation of EBC and the EFI Driver model.

First let's talk about good ideas that didn't come to pass in the market. One idea was to have a EFI VM in the OS that could employ the EFI EBC drivers during operating system runtime. One use-case was the brown-out during OS initialization after Exit boot services and prior to loading the OS performance display driver. The usage therein included using the EFI 1.10 UGA driver (the predecessor to today's GOP) built as an EBC image to display characters while executing within an OS "EFI VM" environment. An "EFI VM" is emulating a UEFI boot services environment after Exit Boot Services; a popular instance thereof is the OVMF emulation of a BS environment for purposes of providing guest firmware in a virtual machine monitor, like VirtualBox https://www.virtualbox.org/wiki/VirtualBox. This idea was demonstrated on Linux, but ultimately concerns about 'yet another byte-code interpreter in the kernel' led to today's GOP with the framebuffer exposed by the pre-ExitBootServices environment that the OS early flow could just peek/poke directly.

Again, a good idea in theory, just like the original provision for the EFI 1.02 UNDI to be usable by the OS runtime in 'safe mode' usages. The UNDI has the ability for the OS to replace the memory and I/O services with the OS correlatives. This usage was eschewed by OS community even more viscerally in the last 16 years given the need to run 'native' pre-OS EFI driver code in the OS content, although it was demonstrated on how to build an "UNDI Class Driver" for OS's like Linux. The value of using the platform UEFI driver post-boot is that old OS boot media without an in-box OS driver can rely upon the system board, which typically has up-to-date firmware driver support for networking, as a simple path to reach an online resource to download the OS's performance driver.

So how important are PCI drivers on 2015 systems?
Today, most client machines do not have exposed PCI slots, but there is now a rich set of 64-bit class servers that are still consumers of enterprise storage and networking HBA's. High-end desktops still support external graphics cards, too.

Given the slot-based nature of EBC driver usage, the EBC support was made optional after EFI1.10 was contributed to the UEFI Forum and became part of the UEFI2.0 corpus. The primary motivation at the time was the embedded community with their often penurious flash budgets and no need for 3rd party driver interoperability of plug in cards.

On the security front, the pre-OS has become much more hostile in the following 1.5 decades. As such, another nice aspect of an interpreted byte stream is the ability to sandbox the code, as mentioned on pages 11-12 of https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Supporting_SMM_Resource_Monitor_using_the_EFI_Developer_Kit_II.pdf and https://www.google.com/patents/US8327415. Recall that even if your driver passes cryptographic verification, you only have some guarantee of authorship/provenance, not correct behavior. Malevolent or errant coding may still exist, thus the value of some defense in depth like the above-listed isolation techniques.

There has also been a renaissance in the compiler community with LLVM and CLang http://clang.llvm.org/. There is interesting security work ongoing with LLVM, such as KLEE https://klee.github.io/ on the producer side of the C code.  Given KLEE and the expansion of open source efforts on http://www.tianocore.org may additionally drive some interest in an open source C compiler will take up the challenge of supporting EBC? Time will only tell.

Tuesday, July 14, 2015

Software assurance, security, and more talks

On the topic of software assurance and security, I'd like to provide a quick summary of the Design Automation Conference (DAC) panel discussion
Fazzari, et al., “Panel: Design for Hardware Security: Can You Make Cents of It?”, Design Automation Conference, June 9, 2015  http://www2.dac.com/events/eventdetails.aspx?id=182-18  

I sometimes grab a picture with my phone of my travels, but this time the best I have is my parking space at Seatac airport. You know the picture, namely the one you take to remind oneself of 'where' you parked after a 22 hour travel day and you brain isn't quite running at peak efficiency.

So other than my above parking travails, back to the trip. DAC is historically a venue for Computer Aided Design (CAD) vendors and innovation from academia and industry. The above-listed panel was part of a security track. Both security and embedded are two notable additions to DAC's historically CAD-oriented theme. The morning had sessions on hacking software-defined radio and IOT devices. The panel session offered interesting perspectives, including such quotations as Dino's "Insecure software can burn up the world," which is a play on Marc Andressen's quotation "Software Is Eating The World" http://on.wsj.com/1w2FbVs.

Other discussions included Common Criteria and today's platforms, secure elements/smart cards. A funny quotation from another panel member was "it's all software, whether C code or Verilog." A more cynical comment was 'Hardware is more difficult than software. That's part of the problem."

The most inspiring question from the audience came from Todd Austin http://web.eecs.umich.edu/~taustin/. His observation was that formal methods experts for hardware should move up into software security. And the latter infosec experts should move their expertise more into evaluating hardware. He also observed that DAC is a perfect venue to evolve that type of dialectic.

Speaking of that feedback of moving hardware assurance experts into software (at least the 'firmware' class of software), I'm happy to note that:
Oleksandr Bazhaniuk, John Loucaides, Lee Rosenbaum, Mark R. Tuttle, Vincent Zimmer, "Symbolic Execution for BIOS Security," 9th Usenix Workshop on Offensive Technologies (WOOT) '15, August 10, 2015 https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk
has been accepted. This paper will describe how formal methods can be applied to the challenge of firmware assurance. I'm anxious for the paper and presentation to go public next month. I'll revisit the topic in this blog at that time.

Given the modular nature of thing like UEFI PI-based EDKII firmware, it's often not sufficient to do analysis from one supplier element. Testing needs to happen across the final composition of the modular elements. As such, I'm excited to see work like http://www.infoq.com/news/2015/06/facebook-infer being available in the open and covering C code. I'd like to see tools like this available for both the open source EDK II platforms on www.tianocore.org (a firmware upstream) and then for the various vendor consumers of this code, including vendor downstreams.

In general, I want to encourage more cross-over between tools researchers and the firmware producing community. Starting with the driver synthesis work https://ssrg.nicta.com.au/publications/nictaabstracts/Vij_KRHZRWL_13.abstract.pml in 2013, and now WOOT in 2015, I hope to observe more frequent instances of such opportunities in the future. I always say that most innovations happen at the seams between two domains. As such, I'm happy to see the boundary between formal methods and firmware bearing fruit.

Now to move from to-be-published security collateral, I bumped into some existing papers, namely an interesting UEFI Security paper curation at https://github.com/robguti/firmware_security_docs/tree/master/bios
I see a couple of mine - https://github.com/robguti/firmware_security_docs/blob/master/bios/SF13_STTS002_100.pdf … and https://github.com/robguti/firmware_security_docs/blob/master/bios/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf Nice to see what people cull as potentially useful material.

I'm also happy to see the following elements continually being updated in the open source, namely the UEFI 2.5 conformant HTTP driver,
HTTP boot https://github.com/tianocore/edk2/tree/master/NetworkPkg/HttpBootDxe
and finally, no need to type in octets
https://github.com/tianocore/edk2/tree/master/NetworkPkg/DnsDxe. Great progress on building out the HTTP scenarios, especially for data center usages where the needs of scale and connectionless downloads have been at odds historically.

I also look forward to participating in some upcoming talks.

The first talk is at the Intel Developer Forum (IDF) in San Francisco during late August. The talk is STTS003 - "Developing Best-in-Class Security Principles with Open Source Firmware."
There will be some messages I've delivered in the past, but hopefully an exciting announcement about an innovation in system software to provide some additional defenses.

The next talk is later in the year at LinuxCon Dublin in October. Great overview at
UEFI Mini-Summit at LinuxCon/CloudOpen/
Embedded Linux Conference Europe
Wednesday, Oct. 7 in Dublin, Ireland
The UEFI Forum will host its second LinuxCon Mini-Summit. The one day event includes presentations on UEFI and ACPI developments, including tools and resources available to the
Linux community.

Friday, July 10, 2015

Option ROM's, code size

I noticed the recent post on Google+ https://plus.google.com/u/0/113713059726404063654/posts/7KTPg174pm1 about the UEFI PlugFest presentation http://www.uefi.org/sites/default/files/resources/UPFS11_P6_OptionROM_AMI.pdf. Specifically, Brian's https://plus.google.com/u/0/+BrianRichardson/about slide 3 comment "–Designed to reduce code size".

Code size and host firmware implementations, such as UEFI-based solutions, can be a controversial topic. As can be boot-time, security,....

As such, I'm not going to discuss a feature comparison of coreboot versus EDK II for comparable hardware in this posting. I showed a design comparison of the firmware designs on slide 16 of https://firmware.intel.com/sites/default/files/resources/SF14_STTS001_102f.pdf, but size and / or other metrics like cyclomatic complexity weren't discussed. That'll be an exciting posting for another day. A data driven view is always the best way to approach this topic and I'd like to have 2 fully open platform trees build in coreboot www.coreboot.org (plus a payload like U-Boot http://www.denx.de/wiki/U-Boot with its I/O drivers) and EDK II http://www.tianocore.org/edk2/ on a community site.

There's no better way to teach developers about a topic than source trees, IMHO. I recall talking with a developer recently about SMM and Authenticated Variables. He had read https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf and kept asking follow-up questions. After seeing the EDK2 implementation https://downloadcenter.intel.com/download/23962/EDKII-Update-for-Intel-Quark-BSP and the PI SMM code therein he finally said "I get it."

And speaking of open source, glad to see posting of information like https://download.01.org/future-platform-configuration-hub/skylake/register-definitions/ to help enable open source firmware community development. Good stuff.

For this posting, though, I wanted to address the note above at the top of the blog regarding the plug fest presentation. The size comment was embedded in a broader point about "UEFI solves many problems for the IHV." It wasn't meant to be 'UEFI relative to something else', but more 'various embodiment options of UEFI.'

Specifically, the UEFI Driver Model has the concept of Bus drivers and Child device drivers. Common idioms are put into Bus Drivers, which today include USB, PCI, SCSI, Blue Tooth, etc. The bus drivers are typically stored in the system board ROM by the Original Equipment Manufacturer (OEM) so that the child device drivers built by the Independent Hardware Vendors (IHV's) only have to carry device specific code. The latter code is typically delivered as separate binaries in Host Bus Adapter (HBA) cards, such as PCI adapter, or embedded in the OEM system board firmware image.

The above figure from the UEFI 2.5 specification www.uefi.org above shows the relationship of the bus and child device drivers. Servers with sophisticated RAID and networking devices still enjoy the ROM savings and configurability afforded by the UEFI Driver Model. For small devices and more purpose build devices, this bus/device dichotomy may not yield as many code savings since you will not often observe a 1 bus to many devices relationship.

I don't want to be viewed as a UEFI apologist or partisan in this posting, but I did want to clarify the context of the 'size' comment here. It was size in the sense of, if given N PCI device drivers, either duplicate logic from the bus driver is copied into each device driver instance (e.g., EFI1.02), or the EFI1.10+ (now UEFI2.5) driver model with the bus and device driver dichotomy of sharing code logic pushed into the bus driver.


Sunday, June 28, 2015

Firmware-related blogs

This short post describes some firmware-related blogs, including this one. Does talking about one's own blog make this a meta-blog posting, or given the pain in getting through this read along w/ the subject matter of firmware make it a 'flog' (firmware + blog)? Just kidding.

So to begin, I started this blog in 2009 to discuss recent events in UEFI and PI. One of my favorite UEFI-related sites on blogger is Tim Lewis' http://uefi.blogspot.com. I've worked with Tim for over a decade and he is one of the most talent software engineers and architects in the field. When I bumped into Tim at the Open Compute Project conference in San Jose, I asked why he hasn't blogged since October of last year. His reply was 'When I get deep into a programming project, I forget to blog', or something like that. As such, as always, expect to see good things from Tim in the future.

Since starting my blog in 2009 I have expanded a bit in both the subject matter and the length. Recently I started posting at https://firmware.intel.com/blog/ on subjects directly related to that site. I try to elide opinions and other matter from that blog stream and stick to subjects closely related to UEFI, PI, coreboot, and other topics hosted on http://firmware.intel.com. Since I don't have write-access to the wiki's on http://www.tianocore.org, I typically beg someone to post a note for me on http://tianocore.sourceforge.net/wiki/SecurityPkg. It's easier for me to go to the firmware blog and post entries like https://firmware.intel.com/blog/security-technologies-and-minnowboard-max

On the Intel front, you'll see that fellow Intel colleague & blogger Brian Richardson from the above blogging site also has an evangelist blog at https://blogs.intel.com/evangelists/author/brichar2/ When last in the Seattle area Brian stopped by my house; I don't know if he appreciated the story I related later wherein my teen-age daughter asked me "why was Kurt Cobain visiting you, Dad?" 

Another site that I follow is relatively new. Its author harkens from the Pacific Northwest and I met him at the Black Lodge back in 2013 https://twitter.com/vincentzimmer/status/381940011974656000/photo/1. His site is http://firmwaresecurity.com/ and as the masthead notes, it is "a blog focused on hardware/firmware security news/info for BIOS, UEFI, and Coreboot, on Linux, Android, FreeBSD, Chrome, and other OSes." Although the site also treats OS's, it has a rich feed of stories on firmware.

Other firmware sites closely related to UEFI and PI includes William Leara's "Basic Input/Output" http://www.basicinputoutput.com/. "Beyond BIOS" (oh the pun hurts this morning), the coreboot community has an interesting blog stream I follow at http://blogs.coreboot.org/, and the commercial coreboot entity Sage Engineering's Jeff Thomas has an interesting set of postings at https://www.se-eng.com/author/sagejeff/

Another rich set of blog postings on BIOS and firmware can be reached via http://bioshacking.blogspot.com/. The blogger is also the author of http://www.amazon.com/BIOS-Disassembly-Ninjutsu-Uncovered/dp/1931769605 which sits nearby on a bookshelf crowded by the hefty Stevens TCP/IP series and ancient computer architecture books by Organick and Levy.

Although not a blog, I have followed Jack Ganssle's e-newletter http://www.ganssle.com/tem-subunsub.html on embedded for years. And although the subject matter is more trusted computing than firmware, I like the community postings of Chris Maher on http://www.linkedin.com since there are often cross-overs of firmware and trusted computing in his citations.

Twitter http://www.twitter.com also has a rich set of news on firmware, but it's difficult to filter signal from noise on that site. I've been accused of being one of those noise generators at time, too https://twitter.com/vincentzimmer. Accounts like https://twitter.com/uefibios and https://twitter.com/coreboot are obvious postings to follow.

I hope that these locations help in your hunt of interesting reads regarding firmware on the internet. If you have a favorite site that I missed, please send me a mail or comment on this blog. Remember on the internet that 'sharing is caring.'


Sunday, June 7, 2015

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

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

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.


Sunday, May 3, 2015

Open Compute Project, CanSecWest and new specifications from the UEFI Forum

"The goal in technical writing is not to be possible to understand, but to be hard to misunderstand."- Cook

"Writing is nature's way of letting you know how sloppy your thinking is." - Guidon

This blog is probably disappointing Cook and affirming Guidon's wisdom at the same time.

The danger of delaying posting a blog is catching up with recent events. As such, I have a bit of content to soldier through in this posting. The most exciting of late is the posting of the UEFI 2.5, PI 1.4, and ACPI 6.0 specifications http://www.uefi.org/specifications, but the preceding events definitely argued for much of the content and motivation which has appeared in those specifications.

I was on the road for a few weeks in March and April. First I attended the Open Compute Project (OCP) Summer 2015 summit http://www.opencompute.org/community/events/summit/ocp-us-summit-2015/ in sunny San Jose.

After that I sojourned north to attend the CanSecWest (CSW) conference in less-than-sunny Vancouver, B.C., Canada.

Although OCP treated opening up the designs of servers, and CSW was an information security conference, there were some common threads, such as openness, firmware, UEFI,....

And speaking of openness, I finished the tour in southern Washington State at the Open Source Technology Summit (OSTS).

To begin, the Open Compute Project http://www.opencompute.org/ hosts a community where common elements to build out the data center, such as network switch, server board schematics, rack mechanicals, etc can be shared.

Many companies are involved in OCP, with a recent discussion of resultant hardware at http://www.anandtech.com/show/9138/open-compute-hardware-tried-and-tested.

The keynote videos and presentations can be found at http://www.opencompute.org/blog/ocp-u.s.-summit-2015-video-and-presentation-links/.

OCP has made a lot of progress on opening up board designs, chassis specs, etc over the last few years.  But aligning on firmware hasn’t been a first priority.  I chatted w/ one company VP and his engineer afterward.  The quote from engineer was “firmware is our biggest head-ache, it should have been the first focus area of OCP.” This is because of requirements around device update, boot policy, and other aspects of a system that read directly on host boot firmware.

Mallik Bulusu from Microsoft and I https://www.flickr.com/photos/106659057@N08/16966691206/in/set-72157651601950765 spoke about some of the problem statements and opportunities in the cloud.  Material presented can be found at:

This paper also treats briefly on the topic of open source support for these technologies and possibly entire server platforms.

Regrettably, the talk preceded the release of UEFI 2.5, ACPI6.0, and PI1.4, so we were not able to discuss some of that material as it was under UEFI Confidentiality at the time. We mentioned the firmware-related Cloud problem statements, such as scalable configuration and network provisioning. The latter, namely the boot-from-HTTP work defined in UEFI 2.5 via wire protocols, DHCP extensions, and new API's for HTTP, TLS, and DNS, will be touched upon later in this blog posting.

This talk seemed well-received, with some nice social media responses, too
2 retweets3 favorites

Speaking of Curt Brune above, his company Cumulus announced a usage of ACPI http://www.enterprisenetworkingplanet.com/netsp/cumulus-networks-introduces-the-acpi-platform-description-apd.html for network switches. Essentially the effort entails making the switch look like a server for purposes of running general purpose OS’s.  That’s another trend that is auspicious for the UEFI Forum-based technology and Intel as a component supplier to the switch hardware as a more open platform.

Beyond accretion of new functional technology in the UEFI Forum specification corpus, there were discussions of open source from http://www.rackspace.com/ in the context of their Power8 support. Specifically, from
"The parts that Rackspace is changing are inside the server and will take advantage of all of the firmware and systems software work that Rackspace has done already with X86-based systems and will also leverage the open firmware that IBM and Google have created for Power8 systems, which weighs in at around 420,000 lines of code."

Facebook also had a session on open sourcing their BMC with Yocto Linux, and discussions around mini-BMC's and FreeRTOS were also in the air.

So the addition of consistency of interfaces, in addition to more openness in the development model were described.

Open source is a prevailing theme of this blog, and I was chided by some in the open source community that firmware should be one of these things:

1- either perfect at inception
2- give people the source to do themselves
3- remove from pre-OS altogether

I argue that no software is perfect, but a community can strive to patch software, #1 can become 'imperfect but will patch." This is a place where UEFI2.5, ESRT, and capsules can help.

On #2, there are challenges with technology like hardware-verified boot, where 'protecting the user' and 'allowing innovation' have some interesting tension.  NIST 800-147 reads on allowing for physically present users to bypass protections, and Chromebooks have both developer mode and the write-protect screw, so I believe that you can balance the end-user protection and choice dialectic.

Finally, on #3 maybe there is a path forward? For client systems that boot in non-human perceptible time, maybe deferring things like graphics initialization into the operating system and omitting from the pre-OS could be a future-looking option?

Next, I embarked on a road trip from Seattle to Vancouver, BC, to attend CanSecWest https://cansecwest.com/agenda.html

As shown in the agenda, the Friday sessions led off with three offence talks and one defender talk, namely mine.  Throughout the sessions Dragos reiterated "The BIOS vulnerability beatings will continue until morale improves." https://twitter.com/dragosr/status/578988308853698560

My talk, now posted at https://cansecwest.com/slides/2015/UEFI%20open%20platforms_Vincent.pptx was intended to provide an alternative perspective on the firmware ecosystem. I led off with a summary of the history of boot firmware, the present standards and open source activities, and detailed a list of the salient open source collateral and platforms.

The one slide that most resonated with the crowd detailed the difference between the open source trunk, with fixes on http://www.tianocore.org/security/ and the resultant product trees on shipping platforms.

This is again where UEFI 2.5 and capsule updates, ESRT, and OS support across the Linux upstreams, disributions, and Windows comes into play.

Luckily I had the opportunity to speak to David Aucsmith ahead of my session, and he mentioned that a review of UEFI Secure Boot as a "Ceremony" was an appropriate lens to apply https://eprint.iacr.org/2007/399.pdf.

Carl Ellison http://world.std.com/~cme/ was a great mentor http://www.google.com/patents/US7328340 of mine during his time at Intel. Methodologies like Ceremonies remind us that the security of a system is rarely just in the mechanics of the cryptography, but instead spans the human and organizational actors. In the case of UEFI Secure Boot this includes the ecosystem, manufacturing-time provisioning, end user and enterprise management, etc. All of these flows need to be considered for purposes of system assurance.

Speaking of mentors, happy to see http://www.google.com/patents/US9015455 issued with Jim Held http://newsroom.intel.com/community/intel_newsroom/bios?n=James%20P.%20Held&f=searchAll, too.

SUSE's pioneering work on MOK https://www.suse.com/communities/conversations/uefi-secure-boot-details/ is a great example of a broader view of the solution space and required technology. Additional details on SUSE's work was also discussed at http://intelstudios.edgesuite.net/idf/2013/sf/aep/STTS002/STTS002.html.

I also had the opportunity to meet with the USB Armory http://www.inversepath.com/usbarmory.html team. They described how ARM TrustZone (TZ), although an architectural CPU mode, has configuration issues. Specifically, each SOC vendor does the configuration differently of ranges reserved for TZ. I smiled since this is similar to some of the malaise around System Management Mode (SMM) on IA32/x64, namely a consistent set of CPU behaviors but different SOC/CPU/chipset configuration techniques per product families.

The final aspect of the talk included threat modeling and open platforms. On the former, I reminded the audience of the threat modeling that motivates today's UEFI features and some future looking opportunities on protection. I also reviewed the Quark and Minnowboard MAX platforms, with their fully and partially open source UEFI EDK II implementations, respectively, as great opportunities to collaborate. On the topic of the MAX I elaborated recently on some of these sentiments at http://firmware.intel.com/blog/security-technologies-and-minnowboard-max.

Although it was tough to follow several hours of attack talks on UEFI, I felt it important to show up at CSW for several reasons. I wanted to show that the UEFI community was engaged, concerned and results-oriented in the face of these issues afflicting the platform. And I also wanted to reach out to the researchers on how we can work together to make the platforms, and thus the internet, a safer place for all of us.

Beyond this talk, we also posted some material on how to defend a EDK II-based platform during boot http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf.

The UEFI Forum has posted the revocation list, or DBX for UEFI Secure Boot, at http://uefi.org/revocationlistfile.

My final stop has been the Open Source Technology Summit (OSTS), an Intel-hosted event in Skamania, WA. You can find some mention with the Twitter hash-tag #osts2015.

https://www.flickr.com/photos/davest/3339316813/in/photostream/ provides one view of the surroundings.

This final talk folded in some of the open source trends touched upon at OCP and CSW, and added some color on other community evolution.

I was jovial at the beginning, at least.

At this point I was fielding questions on secure boot, and I see that Linus in the audience has a grin.

Speaking of open source, another notable event since the last posting has been the release of the coreboot payload on http://www.tianocore.org. I mentioned this technology in http://firmware.intel.com/blog/edkii-fsp-and-other-topics and have some content in http://www.apress.com/9781484200711, but the code's now live at https://github.com/tianocore/edk2/tree/master/CorebootPayloadPkg and  https://github.com/tianocore/edk2/tree/master/CorebootModulePkg with a wiki at https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload.

Interesting community response after the posting included:

Patrick Georgi

Shared publicly  -  Mar 31, 2015

coreboot support in Tianocore (so Tiano acts as coreboot payload, providing UEFI services to the OS), committed by Intel employees.

I'm not sure I would have believed this 4 years ago.

Although I cannot hope to do this topic justice tonight, I'd like to elaborate on
PI1.4 spec http://www.uefi.org/sites/default/files/resources/PI_release_1_4.zip,
ACPI6.0 http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, and
UEFI2.5 http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf,
as described in the press release http://www.uefi.org/node/897.

On the back of the PI1.4 release, the Intel Firmware Support Package (FSP) 1.1 release has also been made
http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf. The latter leverages some of PI1.4, such as the graphics HOB definition. We also published a couple of papers on the creation / production of a FSP http://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 consumption / integration / usage 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, respectively.

These specifications tie into the above talks via a few threads. One thread is the need to evolve UEFI technology for the cloud, and to that end the boot-from-HTTP portion of the UEFI 2.5 specification squarely targets this space. Below shows schematically model of booting wherein TFTP (and thus UDP) based PXE can move to HTTP (and thus TCP) based booting. The move to a connection oriented protocol removes some of the chronic data center complaints, such as time-outs in "booting the Skynet" http://en.wikipedia.org/wiki/Skynet_%28Terminator%29, or more formally, provisioning warehouse-scale computers http://research.google.com/pubs/pub35290.html.

In addition to the wire protocols and DHCP extensions, additional API's for the network boot program were created, such as HTTP, DNS, and TLS. The latter allows for an optional boot-from-HTTP-s flow. This solution also allows for in-band and out-of-band RESTful messaging, such as http://www.redfishspecification.org/. Although many data centers use dark fibre and don't have threat models beyond the integrity concerns mitigated by UEFI Secure Boot, TLS allows for confidentiality cover where deemed necessary.

And TLS comes more into play in order to support another scenario enabled by the UEFI 2.5 specification, namely boot-from-wifi.  Wi-Fi security requires a supplicant, which is typically EAP-TLS support. So the UEFI 2.5 specification updated EAP to work on concert with TLS for the WI-FI use case. Some of the WI-FI support is shown below.

In addition to WIFI, Bluetooth support was also added to the UEFI 2.5 specification. This allows for building IOT-style usages in UEFI, but more importantly works in tandem with WIFI above for the no-wires style usages found in today's phone, tablets, and slim laptops. Without this wireless evolution, UEFI and its wired networking support was becoming more of a server/datacenter technology and missing some of the prevailing client trends.

In order to support boot-from-HTTP, and other firmware network boot art, such as U-Boot, the
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml list has also evolved since the last blog posting.

Processor Architecture Types

Registration Procedure(s)
Expert Review
Vincent Zimmer
Available Formats

Type Architecture Name Reference 
0x00 0x00x86 BIOS[RFC5970][RFC4578]
0x00 0x01NEC/PC98 (DEPRECATED)[RFC5970][RFC4578]
0x00 0x02Itanium[RFC5970][RFC4578]
0x00 0x03DEC Alpha (DEPRECATED)[RFC5970][RFC4578]
0x00 0x04Arc x86 (DEPRECATED)[RFC5970][RFC4578]
0x00 0x05Intel Lean Client (DEPRECATED)[RFC5970][RFC4578]
0x00 0x06x86 UEFI[RFC5970][RFC4578]
0x00 0x07x64 UEFI[RFC5970][RFC4578]
0x00 0x08EFI Xscale (DEPRECATED)[RFC5970][RFC4578]
0x00 0x09EBC[RFC5970][RFC4578]
0x00 0x0aARM 32-bit UEFI[RFC5970]
0x00 0x0bARM 64-bit UEFI[RFC5970]
0x00 0x0cPowerPC Open Firmware[Thomas_Huth]
0x00 0x0dPowerPC ePAPR[Thomas_Huth]
0x00 0x0ePOWER OPAL v3[Jeremy_Kerr]
0x00 0x0fx86 uefi boot from http[Samer_El-Haj-Mahmoud]
0x00 0x10x64 uefi boot from http[Samer_El-Haj-Mahmoud]
0x00 0x11ebc boot from http[Samer_El-Haj-Mahmoud]
0x00 0x12arm uefi 32 boot from http[Samer_El-Haj-Mahmoud]
0x00 0x13arm uefi 64 boot from http[Samer_El-Haj-Mahmoud]
0x00 0x14pc/at bios boot from http[Samer_El-Haj-Mahmoud]
0x00 0x15arm 32 uboot[Joseph_Shifflett]
0x00 0x16arm 64 uboot[Joseph_Shifflett]
0x00 0x17arm uboot 32 boot from http[Joseph_Shifflett]
0x00 0x18arm uboot 64 boot from http[Joseph_Shifflett]
0x00 0x19-0xff 0xffUnassigned

In addition to boot-from-HTTP, DNS, TLS, wireless, Bluetooth, UEFI 2.5 also added REST support. REST can be built upon the new HTTP API for in-band networking usages, such as https://www.redfishspecification.org/, or via out-of-band to a baseboard management controller (BMC), with the new BMC device path providing identity.

As the chair of the UEFI Networking Sub-Team (UNST) and the UEFI Security Sub-Team (USST), I am proud of the work that the team members did the create this collateral.

And this is just a taste. USST also produced interfaces for inline cryptographic interface (ICI) hardware, smart cards, enterprise deployment of UEFI Secure boot, additional protection capabilities of the boot, stylized operating system and platform recovery, among the various additions. I am working with the subteams to provide rationale documents in order to let the world into the insights and deliberations that gave birth to these new technologies. In no way can a blog like this hope to scratch the surface on the topic areas.

Upcoming talks

Next stop of the talking tour is a bit easier for me. I only need to wander to the nearby UEFI Plugfest in Seattle to speak about "Addressing Firmware Challenges for the Cloud with UEFI" in mid-May http://www.uefi.org/node/887. This is a variant of the OCP talk above that will include insights and matter that is now public in the UEFI 2.5, ACPI 6.0, and PI1.4 specifications.

And then it's off to San Francisco to share a panel talk at the Design Automation Conference (DAC)
http://www2.dac.com/events/eventdetails.aspx?id=182-18 on hardware versus software security.

TUESDAY June 09, 1:30pm - 3:00pm | Room 300 

PANEL: Design for Hardware Security: Can You Make Cents of It?

Saverio Fazzari - Defense Advanced Research Projects Agency, Washington, DC

 Saverio Fazzari

Given the proliferation of counterfeit electronics in the supply chain, recent breaches at major retailers and the ever-growing Internet of Things, there is evidence that electronic hardware is the "new frontier" for security compromise.  Yet the protection of hardware continues to take a back seat to software in cyber-defense. How real is the problem of hardware security?  Should there be a stronger push to develop and deploy security techniques in design? Finally, is there money to be made in hardware security? Who benefits and who pays?  


Ingrid Verbauwhede - Katholieke Univ. Leuven, Belgium
Siva G. Narendra - Tyfone, Inc., OR
Vincent Zimmer - Intel Corp., Seattle, WA
Dino A. DaiZovi - New York Univ., New York, NY
Lisa McIlrath - Raytheon BBN Technologies, Cambridge, MA

I'm glad to see "Intel Corp, Seattle, WA" next to my name. I'm hoping to put more of the Intel-in-the-Emerald-City visibility out in the community.

On the latter topic of "Hardware Security", as the 'firmware guy' it's always interesting to see which side of the fence I most straddle (psst - I still say 'software').