ASSET recently joined the UEFI Forum and, enjoying the benefits of membership, we came across this paper extolling the virtues of the technology and clarifying some common misconceptions.
UEFI has become fairly ubiquitous in its support for x86 and ARM (at least 64-bit) platforms. The UEFI Forum, which ASSET recently joined, is a standards body responsible for developing, managing and promoting UEFI specifications. It’s a community effort by many companies in the personal-computer industry to modernize the booting process. Open-source implementations exist (see www.tianocore.org) and companies such as AMI, Insyde and Phoenix productize and sell versions for use by systems-makers.
Since UEFI evolved from Legacy BIOS, there are many misconceptions in the industry that are based upon confusion between the two. The term BIOS usually refers to an Intel architecture implementation rooted in the original IBM PC design. Written mostly in assembly language, its use has declined over time. UEFI is generally written in ‘C’ and came into play to allow support of new technologies, faster development time, and a better overall customer experience during the time prior to the operating system loading. Many modern Intel and ARM-based systems use UEFI as a boot loader.
Here’s an abbreviated list of the benefits of UEFI, with accompanying commentary:
- Enables better disk and network support
UEFI works well with today’s larger spinning and flash disks, and supports IPv6
- Ability to be emulated
UEFI is supported by numerous virtualization platforms
- Multiple OS support
Such as Windows, Linux, Android, etc.
- Serves as an abstraction layer between the firmware and the OS
This accelerates deployment of new hardware and OS features
- Serves as a boot device driver target
By targeting UEFI as opposed to unique hardware, this allows platform reuse.
- Provides a robust environment
Pre-OS diagnostic tools can be easily added.
- New modules are easily added to the graphical interface
Pre-boot front-ends are easily added and updated.
- Device functions are not tied to a particular platform
UEFI is hardware-agnostic, with current support for Intel and ARM
- Closer degree of integration between the OS and pre-boot environment
A streamlined interface allows for efficient transfer of data to the OS.
- Malware prevention with UEFI Secure Boot mechanism
This optional mechanism protects from tampering from the point of boot initiation.
Of course, misconceptions about UEFI can be traced to some incomplete understanding of its benefits. Common misconceptions from the paper are:
- UEFI is slow to boot
You really have to read the paper to get the details on this, but it is certainly true that a fully optimized UEFI implementation has been closed at 0.5 seconds.
- UEFI is too large to boot
This is entirely dependent upon right-sizing the implementation to the needs of the specific application. Although large server UEFI may be up to 7MB or more in size, a fully compliant UEFI boot image for IA has been put into 128KB of flash.
- The UEFI specification is too extensive
Yes, it is over 2,000 pages in length. But this is solely the result of being comprehensive. Length should not be mistaken for complexity. Making UEFI processor, platform and target OS-independent has necessitated some amount of thoroughness.
- The UEFI platform is just as insecure as the legacy BIOS
Security features are part of the UEFI specification.
- UEFI cannot support full open source implementations
TianoCore is only one example of an open source project that supports UEFI firmware. Others include QEMU (Quick Emulator), the Beagle Board, the MinnowBoard, and others.
Of course, UEFI vendors and silicon drivers may have IP used by UEFI that is not disclosed.
- UEFI has a restrictive processor architecture
UEFI supports both 32-bit and 64-bit implementations (but not on the same device). It currently supports x86 and ARM (32-bit and 64-bit) architectures. Others might be added in the future, if demand warrants.
- The UEFI Forum controls vendor implementations
This is simply not true. Enough said!
- UEFI is not compatible with mobile devices
For a long time, PCs and servers have used UEFI. However, UEFI has long been used as a boot mechanism and operating environment for other device classes, including printers, scanners, network routers, network switches, storage devices, tablets, and smartphones, amongst many others.
- The UEFI Forum restricts which Certificate Authorities can provide signing keys
Currently, Microsoft is the key provider for UEFI, but the UEFI Forum continues to search for at least one more certificate authority.
- The UEFI CA Key and the Firmware Key are the same thing
The UEFI CA key is intended for third-party UEFI application/driver images, while core firmware updates can be under a separate, private OEM key. Ultimately, OEMs own their implementations and can use their own signing keys for firmware updates, as well as add additional security.
In summary, UEFI is like many other large software communities: it’s based upon a combination of open source contributions with proprietary input from many vendors. In our brief tenure with the Forum, it seems to do a good job of making the specification open, while welcoming vendors to separately add value.
For an excellent treatise on debugging UEFI, check out the updated version of our eBook, UEFI Framework Debugging. Note that this eBook requires registration.
