The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is a more secure replacement for the older BIOS firmware interface, present in all IBM PC-compatible personal computers, which is vulnerable to bootkit malware.[1][2]
The original EFI (Extensible Firmware Interface) specification was developed by Intel. In 2005, development of the EFI specification ceased in favour of UEFI, which had evolved from EFI 1.10. The UEFI specification is being developed by the industry-wide organization Unified EFI Forum.
UEFI is not restricted to any specific processor architecture and can run on top of, or instead of, older BIOS implementations.[3]
Contents |
The original motivation for EFI came during early development of the first Intel–HP Itanium systems in the mid-1990s. PC BIOS limitations (16-bit processor mode, 1 MB addressable space, PC AT hardware dependencies, etc.) were seen as unacceptable for the larger server platforms Itanium was targeting.[4] The effort to address these concerns was initially called Intel Boot Initiative, which began in 1998[5] and was later renamed EFI.[6][7]
In July 2005 Intel ceased development of the EFI spec at version 1.10, and contributed it to the Unified EFI Forum, which has evolved the specification as the Unified Extensible Firmware Interface (UEFI). The original EFI spec remains owned by Intel, which exclusively provides licenses for EFI-based products, but the UEFI specification is owned by the Forum.[4][8]
Version 2.1 of the UEFI (Unified Extensible Firmware Interface) specification was released on 7 January 2007. It added cryptography, network authentication and the User Interface Architecture (Human Interface Infrastructure in UEFI). The current UEFI specification, version 2.3.1, was approved in April 2011.
An overview of late 2011 usages of UEFI by independent hardware, BIOS, and software vendors.[9]
The interface defined by the EFI specification includes data tables that contain platform information, and boot and runtime services that are available to the OS loader and OS. UEFI firmware provides several technical advantages:[10]
Some existing enhancements to PC BIOS, such as the Advanced Configuration and Power Interface (ACPI) and System Management BIOS (SMBIOS), are also present in EFI, as they do not rely on a 16-bit runtime interface.
In addition to the standard PC disk partition scheme, which uses a master boot record (MBR), EFI works with a new partitioning scheme: GUID Partition Table (GPT). GPT is free from many of the limitations of DOS MBR. In particular, the DOS MBR limits on the number and size of disk partitions (up to 4 partitions per disk, up to 2.2 TB (241 bytes) per disk) are relaxed.[12] GPT allows for a maximum disk and partition size of 9.4 ZB (273 bytes).[12][13] The EFI specification does not prescribe any particular file system. The only Microsoft Windows versions that can boot from disks larger than 2.2 TB are 64-bit versions of Windows Vista and later client operating systems, Windows Server 2008 and later, and the Itanium versions of Windows Server 2003 and Windows XP.
As of version 2.3, processor bindings exist for Itanium, x86, x86_64 and ARM.
The BIOS is limited to a 16-bit processor mode and 1 MB of addressable space due to the design being based on the IBM 5150 which used the 16-bit Intel 8088.[4][14] In comparison, the UEFI processor mode can be either 32-bit (x86-32, ARM) or 64-bit (x86-64 and Itanium).[4][15] 64-bit UEFI understands long mode which allows applications in the pre-boot execution environment to have direct access to all of the memory using 64-bit addressing.[16]
UEFI requires the firmware and operating system to be size-matched; i.e. a 64-bit UEFI implementation can only boot a 64-bit UEFI operating system.
EFI defines two types of services: boot services and runtime services. Boot services are only available while the firmware owns the platform (before the "ExitBootServices" call). Boot services include text and graphical consoles on various devices and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access.
EFI defines protocols as set of software interfaces used for communication between two binary modules. All EFI drivers must provide services to others via protocols.
In addition to standard architecture-specific device drivers, the EFI specification provides for a processor-independent device driver environment, called EFI Byte Code or EBC. System firmware is required by the UEFI specification to carry an interpreter for any EBC images that reside in or are loaded into the environment. In that sense, EBC is similar to Open Firmware, the hardware-independent firmware used in PowerPC-based Apple Macintosh and Sun Microsystems SPARC computers, among others.
Some architecture-specific (non-EBC) EFI device driver types can have interfaces for use from the operating system. This allows the OS to rely on EFI for basic graphics and network functions until OS specific drivers are loaded.
UEFI does not rely on a working boot sector only, but needs a special partition table referring to a special partition containing a specially located file with a standardized name depending on the actual architecture to boot (\EFI\BOOT\boot[architecture name].efi).
Boot loaders are a class of UEFI applications. As such, they are stored as files on a file system that can be accessed by the firmware. Boot variables, stored in NVRAM, indicate the paths to the loaders. Boot loaders can also be auto-detected by firmware, for instance to enable booting on removable devices.
It is common for UEFI firmware to include a boot manager, to allow the user to select and load the operating system among the possible options.
EFI provides a shell environment.[17] The shell can be used to execute other EFI applications.
Extensions to EFI can be loaded from virtually any non-volatile storage device attached to the computer. For example, an original equipment manufacturer (OEM) can distribute systems with an EFI partition on the hard drive, which would add additional functions to the standard EFI firmware stored on the motherboard's ROM.
Intel's implementation of EFI is the Intel Platform Innovation Framework, codenamed "Tiano." Tiano runs on Intel's XScale, Itanium and IA-32 processors, and is proprietary software, although a portion of the code has been released under the BSD license or Eclipse Public License (EPL) as the "TianoCore project." TianoCore can be used as a payload for coreboot .
Phoenix Technologies currently sells Phoenix SecureCore Tiano and Phoenix MicroCore Bios implementing UEFI.[18]
Aptio or Aptio 4 is American Megatrend's next-generation BIOS firmware based on UEFI and the Intel Platform Innovation Framework for UEFI/EFI.[19]
InsydeH2O is Insyde Software's implementation of the Intel Platform Innovation Framework for UEFI/EFI.[20]
Intel's first Itanium workstations and servers, released in 2000, implemented EFI 1.02.
Hewlett-Packard's first Itanium 2 systems, released in 2002, implemented EFI 1.10; they were able to boot Windows, Linux, FreeBSD and HP-UX; OpenVMS added UEFI capability in June, 2003.
In January 2006, Apple Inc. shipped its first Intel-based Macintosh computers. These systems used EFI instead of Open Firmware, which had been used on its previous PowerPC-based systems.[21] On 5 April 2006, Apple first released Boot Camp, which produces a Windows drivers disk and a non-destructive partitioning tool to allow the installation of Windows XP or Vista without requiring a reinstallation of Mac OS X. A firmware update was also released that added BIOS compatibility to its EFI implementation. Subsequent Macintosh models shipped with the newer firmware.
During 2005, more than one million Intel systems shipped with the Framework.[22] New mobile, desktop and server products, using the Framework, started shipping in 2006. For instance, boards that use the Intel 945 chipset series use the Framework.
Since 2005, EFI has also been implemented on non-PC architectures, such as embedded systems based on XScale cores.[22]
The EDK (EFI Developer Kit) includes an NT32 target, which allows EFI firmware and EFI applications to run within a Windows application. But no direct hardware access is allowed by EDK NT32. This means only a subset of EFI application and drivers can be executed at the EDK NT32 target.
In 2008, more x86-64 systems have adopted UEFI. While many of these systems still allow booting only the BIOS-based OSes via the Compatibility Support Module (CSM) (thus does not appear to the user that the system is UEFI-based), other systems started to allow booting UEFI-based OSes. For example, IBM x3450 server, MSI motherboards with ClickBIOS, all HP EliteBook Notebook and Tablet PCs, newer HP Compaq Notebook PCs (e.g., 6730b, 6735b, etc.).
In 2009, IBM shipped System x machines (x3550 M2, x3650 M2, iDataPlex dx360 M2) and BladeCenter HS22 with UEFI capability. Dell shipped PowerEdge T610, R610, R710, M610 and M710 servers with UEFI capability. More commercially available systems are mentioned in a UEFI whitepaper.[23] Many Sandy Bridge PC platforms use UEFI.
An operating system that can be booted from a (U)EFI is called a (U)EFI-aware OS, defined by (U)EFI specification. Here the term booted from a (U)EFI means directly booting the system using a (U)EFI OS loader stored on any storage device. The default location for the OS loader is \EFI\BOOT\boot[architecture name].efi, where the architecture name can be e.g. IA32, X64 or IA64. Some OS vendors may have their own OS loader. They may also change the default boot location.
In 2011 ASRock, ASUSTeK, Gigabyte and MSI launched several consumer-based motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series Chipset for Upcoming AM3+ AMD FX (Bulldozer) and AMD Fusion Processors with EFI.[36]
EFI provides graphical menus and features, such as is implemented on Aptio or Great Wall UEFI.[37]
There are two graphics output protocols defined by EFI specifications. The first one is UGA, which stands for Universal Graphic Adapters. The second one is GOP, which stands for Graphic Output Protocol. The two are similar. UGA works only at EFI 1.1 or older. EFI does not define a user interface. This depends fully on the implementation by BIOS vendors. Currently most EFI-enabled machines only have a legacy BIOS-like text mode UI.
Ronald G. Minnich, a co-author of coreboot, and Cory Doctorow, a science fiction writer and digital rights activist, have criticized EFI as an attempt to preserve intellectual property by removing the ability of the user to truly control his computer.[38][39] It does not solve any of the BIOS's long standing problems of requiring two different drivers — one for the firmware and one for the operating system — for most hardware.[40]
TianoCore,[41] an open-source project which provides the tools to make a fully free firmware based on UEFI, lacks the specialized drivers that initialize chipset functions, thus requiring additional features from the chipset vendor. TianoCore is a payload option for coreboot, which includes chipset initialization code.
Because UEFI can allow for more flexible remote network booting than older BIOS technology, there are concerns over the security provisions in the standard.[42]
Red Hat developer Matthew Garrett in his article "UEFI secure booting" raised a concern that UEFI "secure boot" feature may impact Linux (machines with the Windows 8 logo with secure boot enabled that ships with only OEM and Microsoft keys will not boot a generic copy of Linux)[43][44] In response, Microsoft stated that customers may be able to disable the secure boot feature in the UEFI interface.[2][45] Concern remains that some OEMs might omit that capability in their computers.
Josh Gay of the Free Software Foundation (FSF) raised concerns on "secure boot" implementation to UEFI and FSF declared a public statement open for signing which states:
We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems.[46][47]