Firmware Configuration, or "Is Feature XYZ enabled"

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

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

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

My office neighbor here in Seattle Mike Rothman

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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/

Black Lodge Research ‏@the_black_lodge  Jul 19

BLR would like to thank @vincentzimmer 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);
    break;

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.

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,
https://github.com/tianocore/edk2/tree/master/NetworkPkg/HttpDxe,
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."

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/7/5

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
http://firmwaresecurity.com/2015/07/13/uefi-mini-summit-at-linuxcon-europe-in-october/
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.

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.

Cheers

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

Cheers