What Linux developers need to know about UEFI 2.5

This year's LinuxCon Europe included a "mini-summit" about working with the Unified Extensible Firmware Interface (UEFI). The UEFI specification defines the modern replacement for BIOS and handles hardware initialization before the operating system boots. Therefore, many of its features can impact how an OS functions. At the mini-summit, Jeff Bobzin presented a session on "what Linux developers need to know" about the new 2.5 revision [PDF of considerable size] to the UEFI specification.

Bobzin described himself as being "literally an old BIOS guy: the companies that I sold my first BIOSes to have been gone so long that no one even remembers the names." He got interested in UEFI ten years ago, he said, specifically because of its ability to adapt to the needs of a wide range of computing platforms, from embedded to large clusters. The next version of UEFI includes features requested by computer manufacturers, silicon suppliers, and BIOS companies, but it also contains features requested by OS vendors, which are likely of use to Linux developers.

Bobzin briefly sketched out how the UEFI specification is made and amended. It starts with input from the various member companies (from the categories listed earlier), then proceeds with multiple rounds of draft writing and proposals, followed by edits and reviews. By the time the final update is published, hopefully, working implementations are ready to follow right behind.

This time, during the input phase, the UEFI committees heard three things from OS vendors. First, while the security features of Secure Boot (SB) are working well, provisioning keys to SB-enabled machines is not—it is particularly painful for large enterprises provisioning multiple machines at once. Second, the device firmware-update process is confusing and painful enough that many important firmware updates are being left unapplied, which poses security risks. Third, there are low-level tools like whole-disk encryption that are difficult to write because the UEFI bootloading process gets in the way. All three issues are being addressed in UEFI 2.5.

Provisioning

The SB provisioning problem is addressed by adding a new "audit mode" that the system can be placed into. In previous versions of the specification, a system can only be in Secure Boot mode (meaning that it is locked down) or in administrative mode (meaning that anyone at the console has full power to remove or add SB keys). The all-or-nothing security this offers was problematic for installers trying to provision many machines at once, who had to manually work through the UEFI setup screens (which vary by BIOS vendor) one at a time.

Audit mode is an intermediate boot mode, in which the booting system essentially performs a dry run of Secure Boot: all of the cryptographic checks are performed, but their results are simply logged rather than applied. A second, related new mode called Deployed mode has also been added. Deployed mode is locked down as in Secure Boot mode, but the system can still be re-provisioned if necessary.

The goal is that installers can at least partially automate key deployments; in Audit mode, systems can be tested en masse, but cannot accidentally be put into an unbootable state. Deployed mode allows one final opportunity to fix mistakes before putting a machine into service. Bobzin noted that UEFI considers this bulk-deployment scenario a high priority, but that it would not be releasing any mass-provisioning tools itself.

Audience members inquired about where the Audit mode logs are stored and about how vulnerable machines in Audit or Deployed mode were to potential attackers. The Audit logs, it seems, are only required by the specification to be stored in memory; BIOS vendors may choose to provide other options (such as saving to attached storage), but that is not required. As to the prospect of attackers interfering with Audit- or Deployed-mode machines, he said that provisioning must absolutely be done in a secure environment—as is the case today. If attackers are permitted to access the machines before they are provisioned, there is nothing UEFI can do.

Firmware

The firmware problem is shared by administrators of large deployments and by individual users alike. The root issue is while BIOSes have long allowed the user to install firmware updates (for the system motherboard and for attached peripherals), the process for doing so is inconsistent and manual. Users only learn about new firmware if they visit the OEM's web site and see an announcement; they then have to decipher the OEM's firmware version-numbering scheme to make sure that the firmware they download matches their hardware and is, indeed, newer than what they have. Finally, they have to navigate through the arcane screens of their BIOS to apply the update. The end result is that many firmware updates—including security-sensitive ones—are accidentally or intentionally skipped.

UEFI 2.5 addresses this by defining a standardized table (called the EFI System Resource Table or ESRT) that holds information on the firmware used in the main board, peripherals, and most expansion cards. Each device is identified by a globally unique ID and each firmware update uses a standardized version number. The ESRT table tracks the firmware version of each device and it stores the date and status of the last attempted update. This allows the possibility of automated updates, although the requisite security measures for such automation are still in development, starting with a verifiable "update capsule" package format.

ESRT requires manufacturers to participate, of course—making their firmware updates queryable and accessible in standardized fashion. But ESRT has already been deployed by several vendors, Bobzin said; making it part of the formal UEFI specification is designed to let the OS (and above) access the feature. The goal is to allow an OS to verify that the latest firmware update has been applied (such as one that closes an important security hole) or check that an organization's approved firmware version is in use. A Linux ESRT support framework is currently in development. Still to come, however, are user-space tools for downloading and installing new firmware releases, although some work has been started within Fedora.

System prep

The final OS-related problem addressed in the new specification is support for what are called "system prep" applications: low-level third-party code that needs to run after the BIOS but before the OS. Bobzin gave three examples: certain whole-disk-encryption implementations, set-up routines for disk-docking stations, and enterprise firmware verifiers. When developers tried to implement these applications in the past, they were stuck: when implemented as drivers, the code could not sufficiently interact with the user; when implemented as boot-order components (like a bootloader or the SB shim), the code was frequently trapped and disabled by OSes that viewed it as an attempted security breach.

UEFI 2.5 defines a "system prep" list of code to execute in the boot order; it is a different list than the OS bootloader list. System prep applications have access to some of the same hardware as the bootloader (notably the network, displays, and keyboards). There is an optional API for the application to request access to this hardware, so the BIOS can prompt the user to enter an access code or key before proceeding. How that "ask for permission" API will be enabled or disabled will likely vary between vendors. So far, these system-prep applications have not been widely deployed on Linux systems, but the OS still needs to be made aware of the change to avoid interfering with them.

Feedback

There are plenty of other changes in UEFI 2.5 (at least a dozen); enough that Bobzin said he had to choose only the most relevant to fit into the presentation slot. The specification was released in April, he said, but it can still be updated in response to real-world implementation experience. As a practical matter, it can be hard to find hardware shipping with UEFI 2.5 features so soon after the release of the specification, but for Linux to properly take advantage of the new capabilities, tests need to be done. He encouraged attendees to test the new features and to bring their feedback to the UEFI committee. "We don't exist in a vacuum; we need input from you OS developers, so let's figure out how to roll this out together." Some of the new features will likely be of greater use than others, of course, but Linux will at least need to be aware of all of them.

[The author would like the thank the Linux Foundation for travel assistance to attend LinuxCon Europe.]