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