Vincent Zimmer on the x-UEFI configuration language

Vincent Zimmer of Intel has a new blog post, explaining how UEFI’s HII user interface stuff works:

[…] The The x-UEFI configuration language is now a reality. The latest keywords can now be found at  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 ought to investigate some simple shell applications to export the information, too. […]

Full blog post:

The config namespace already has dozens of variables:

I am looking forward to someone writing a security test tool that works with this database. 🙂


EDK-II specs updated


UPDATE: Below I complain about lack of an announce mechanism to find these updates; TianoCore has an RSS feed that I’ve been neglecting to check, so they have been announcing it, but I’ve not been noticing…


Today, the EDK-II specs were revised.

“Announcing the 1.25 Updates to the EDK II Specifications (BUILD, DSC and FDF). Also Update to Visual Forms Representation (VFR) V 1.9.”

(I stumbled upon announcement on web page by accident; I wish these were announced on edk2-devel or somewhere else more easily-discoverable.)

More Information:

Two UEFI Form tools, plus one UEFI C Module complexity tool

UEFI has a “Browser”, and the browser shows various “Forms”. The browser is what you see when you get the OEM/IBV BIOS boot menu. OEMs/OBVs can reskin the browser, to add value, so the user experience will vary by vendor. In addition to the OEM/IBV, IHVs and ISVs can also add forms to a system’s browser. Each .efi binary contains resource strings, which get compiled into UEFI’s form language. The raw strings are IFR, Internal Forms Representation. The resulting view for the end user is VFR, Visual Forms Representation.  The UEFI browser is dynamic, you can programatically add new menu options by running an app. If you add foo.efi to your system, when you run the BIOS boot menu you may now see a new entry for the foo device, service, or application. For example, if you plug in a new device, that IHV’s config code will likely be now be in the BIOS boot menu. This is much nicer than having to run a DOS config.exe command (if you even have the ability to boot DOS), or boot into the vendor’s OEM firmware update CD (if they provide one).

At design-time, the EDK-II contains tools to build forms from source code. See’s EDK-II tools and sample parsing code (in C and Python). Also see Intel SSG’s training courseware and labs, they have UI examples.

At run-time, existing ROM images or .efi images may have an IFR in the binary. If you don’t have the source code, how do you evaluate the UI included, besides running it?

1) One tool is the “Universal IFR Extractor”, by Donovan6000. This tool can extract the internal forms representation from both EFI and UEFI modules and convert it into a human readable format. It is a Windows-centric tool, being an old-school native GDI GUI appplication written in C++. It may work on *nix via WINE, I’ve not tried it yet.

2) Another tool is “Language applications for UEFI BIOS”, by William Leara. This was his University of Texas thesis; he is now a BIOS engineer at Dell. Besides the thesis, there is a github project with source code. He created an ANTLR grammar for VFR and a tool that gives an HTML preview of what the form would look like.

3) He also created an ANTLR grammar for UEFI-based C source code, and performs complexity analysis application uses general-purpose and domain-specific measures to give a complexity score to UEFI BIOS modules. This second tool isn’t form-centric, but it is also interesting, perhaps more interesting to some security researchers; it’s a good foundation to create more sophisticated tools of this kind, too…