This file type includes high-resolution graphics and schematics when applicable.
When it comes to improving plug-and-play interoperability across multiple platforms and devices, technology standardization plays a key role. In current-generation PCs and mobile devices, there are dozens of standardized peripherals for hardware and code sets for software. And thanks to the transition from legacy BIOS to the Unified Extensible Firmware Interface (UEFI), a standardized interface also exists for firmware that simplifies and secures platform initialization prior to loading of the operating system.
In many cases, as it is for the UEFI firmware interface, the standardization process is led by a community of competing companies who set their individual agendas aside and work in partnership to produce architecture-agnostic specifications to be used in future product implementations.
The purpose of this article is to clarify any misconceptions around the development of the UEFI firmware interface. It also shines a light on how the community has joined hands, time and time again, to improve this foundational layer in the software stack.
1. UEFI technology is a WinTel (Microsoft Windows + Intel) initiative.
The belief that UEFI firmware was developed by Microsoft and Intel for the sole benefit of their own technology advances is easily refutable. The UEFI firmware interface is managed by a non-profit standards body, the UEFI Forum, via a coalition of more than 250 industry-leading technology companies. This group functions through community involvement, including PC manufacturers, server manufacturers, silicon processor vendors, independent BIOS vendors, hardware vendors, software vendors, and operating-system developers and open-source distributors.
A complimentary Adopter-level membership is offered to companies, as well as individual industry advisors, academics and best practices stewards. Companies may also join at the Contributor-level to participate in the working groups and help develop the specification content.
2. The UEFI Forum controls vendor implementations of UEFI technology.
The UEFI Forum community ensures that the UEFI specification is both platform- and architecture-independent. It was developed to promote cross-functionality and broad adoption across multiple hardware platforms and operating systems. Therefore, it is “open” and establishes interfaces and infrastructures to use in the boot process of nearly any platform of virtually any operating environment. While the UEFI specification is open, it doesn’t specify how the protocols are implemented. It’s up to the OEMs to decide how they want to tailor the device implementation in order to fulfill the optimal set of features required by their customers.
3. The UEFI specification is too extensive.
The UEFI Forum values community input from all of its members and industry advisors, and strives to incorporate optional protocols for any necessary feature sets. While this may add to the length of the UEFI specification, it allows developers to customize their UEFI implementations to only include the protocols needed for their specific product line. In other words, developers can determine the scope of the product and select the necessary interfaces that are tailored for a custom fit.
4. UEFI is too big to boot.
When comparing the UEFI boot image size versus that of another boot mechanism, it’s important to note that UEFI implementations provide both a firmware standard and basic bootstrap capabilities. Use of a firmware standard does mean certain choices around the modular design are made, resulting in a sacrifice of space for conformance and associated flexibility. The tradeoff for a modular design is minimal. Anyone who wishes to reuse their code across several designs will be able to easily add/remove components to/from the design.
The standard, modular interface also allows a single boot solution to support more than one target envinroment, including new operating environments. This isn’t the case with the non-modular, monolithic boot architectures. UEFI’s modularity allows the addition or removal of components, enabling software components to interoperate without additional code.
5. UEFI is too slow to boot.
When encountering the perception that UEFI is slow to boot, it’s important to note that the PC industry deployed UEFI as a means of “fast booting” a system. Thanks to UEFI, PC boot times no longer create a bottleneck for further technological improvements; rotational media is now a primary cause. By comparing UEFI boot and other mechanisms with identical hardware and equivalent boot settings, we can realize the full potential of UEFI boot. On a fully optimized UEFI implementation, in which the hardware initialization of external devices isn’t an issue, the time from “power on” to the end of the firmware boot and hand-off to the OS has been clocked at a half-second.
6. UEFI does not improve security.
While the standard nature of the UEFI interfaces can create opportunity for malicious attacks, the mechanisms included in the UEFI specification provide methods to detect and defend against such attacks. Current UEFI specifications and implementations incorporate security features, such as the optional protocol “UEFI Secure Boot,” key signing and signature checking. With these features available and enabled, it strengthens the security of the UEFI booting platform.
7. UEFI is not a fully open-source implementation.
The UEFI specification includes support for open-source implementations. However, vendors may not opt to provide open-source implementations for their products, due to their intellectual-property (IP) protections. Aside from IP protections, UEFI vendor implementations don’t always support open-source firmware, due to the absence of open-source silicon drivers. Nonetheless, several UEFI open-source implementations are already available in today’s market, including Tianocore, QEMU, BeagleBoard, Minnowboard, and ARM reference platforms.
8. Why use UEFI when Coreboot and Uboot are openly available?
While Coreboot and Uboot target specific customer needs and tactical niches in a single environment, UEFI is more extensible and can provide additional offerings, including added system security with UEFI Secure Boot. Depending on vendor and customer needs, there may be times when Coreboot or Uboot makes more sense for the implementation. Other times, if vendors wish to provide further extensibility and more capabilities in their implementations, UEFI firmware is a better solution. In the end, the vendor should make educated decisions on what elements go into solutions to satisfy customer needs.
9. UEFI is restrictive to processor architectures.
The UEFI specification has no architectural limits and allows flexibility in design implementations. The UEFI specification supports any processing architecture that has defined interface connections. Currently, the UEFI specification contains interface definitions for IA-32, IA-64, X64 (on IA architecture), ARM AArch32, and ARM AArch64 architectures. The UEFI Forum will add other processor architectures, as the proponents of those processors express an interest or need for UEFI boot support in additional architectures.
10. UEFI is not compatible with mobile devices.
Aside from the PC- and server-class platforms, UEFI has long been used as a boot mechanism and operating environment for other device classes, including printers, scanners, network routers, network switches, and storage devices. In recent years, tablet and smartphone manufacturers have begun incorporating UEFI boot technology in their product designs. In fact, the extensibility and flexibility provided by UEFI aligns with mobile and embedded-device design requirements.
UEFI bridges architectures supporting ARM and IA technologies. Furthermore, it provides interface layers that allow developers to reuse code—not only on similar platforms, but also across platform classes and architectures.
11. UEFI forum restricts which Certificate Authorities can provide signing keys.
The UEFI Forum doesn’t mandate who can serve as a Certificate Authority (CA) for signing keys. In fact, any independent foundation can set up a CA and offer to generate private key certificates. While Microsoft remains the sole CA for the UEFI Forum, invitations have been extended to other entities to provide additional signature authorities. The Forum has also considered setting up an internal CA, but the overhead cost mounting into millions of dollars isn’t financially feasible. Ultimately, the UEFI Forum is in search of a collaborative, alternative signing service, as this would be ideal for all parties—particularly those in the open-source community.
If you wish to learn more about the UEFI Forum community, please visit www.uefi.org.
Michael Krau is a technical marketing engineer at Intel Corporation and is the Industry Communications Working Group (ICWG) Chair of the UEFI Forum.
Other reading:
UEFI Secure Boot in Modern Computer Security Solutions
Looking for parts? Go to SourceESB.