| Unified Extensible Firmware Interface | |
| Abbreviation: | UEFI |
| Status: | Published |
| Year Started: | 2006 |
| Version: | 2.11[1] |
| Version Date: | 16 December 2024 |
| Organization: | UEFI Forum |
| Predecessor: | BIOS on IBM PC compatible computers |
| Domain: | Firmware |
Unified Extensible Firmware Interface (UEFI, as an initial) is a specification for the firmware architecture of a computing platform. When a computer is powered on, the UEFI implementation is typically the first that runs, before starting the operating system. Examples include AMI Aptio, Phoenix SecureCore, TianoCore EDK II, and InsydeH2O.
UEFI replaces the BIOS that was present in the boot ROM of all personal computers that are IBM PC compatible,[2] although it can provide backwards compatibility with the BIOS using CSM booting. Unlike its predecessor, BIOS, which is a de facto standard originally created by IBM as proprietary software, UEFI is an open standard maintained by an industry consortium. Like BIOS, most UEFI implementations are proprietary.
Intel developed the original Extensible Firmware Interface (EFI) specification. The last Intel version of EFI was 1.10 released in 2005. Subsequent versions have been developed as UEFI by the UEFI Forum.
UEFI is independent of platform and programming language, but C is used for the reference implementation TianoCore EDKII.
The original motivation for EFI came during early development of the first Intel–HP Itanium systems in the mid-1990s. BIOS limitations had become too restrictive for the larger server platforms Itanium was targeting. The effort to address these concerns began in 1998 and was initially called Intel Boot Initiative. It was later renamed to Extensible Firmware Interface (EFI).
The first open-source UEFI implementation, Tiano, was released by Intel in 2004. Tiano has since then been superseded by EDK[3] and EDK II[4] and is now maintained by the TianoCore community.[5]
In July 2008, Intel ceased its development of the EFI specification at version 1.10 and contributed it to the Unified EFI Forum, which has developed the specification as the Unified Extensible Firmware Interface (UEFI). The original EFI specification remains owned by Intel, which exclusively provides licenses for EFI-based products, but the UEFI specification is owned by the UEFI Forum.[6]
Version 2.0 of the UEFI specification was released on 31 January 2006. It added cryptography and security.
Version 2.1 of the UEFI specification was released on 7 January 2007. It added network authentication and the user interface architecture ("Human Interface Infrastructure" in UEFI).
Version 2.3.1 of the UEFI specification was released on 6 April 2011. It added Secure Boot, as well as ARM architecture support.
In October 2018, Arm announced Arm ServerReady, a compliance certification program for landing the generic off-the-shelf operating systems and hypervisors on Arm-based servers. The program requires the system firmware to comply with Server Base Boot Requirements (SBBR). SBBR requires UEFI, ACPI and SMBIOS compliance. In October 2020, Arm announced the extension of the program to the edge and IoT market. The new program name is Arm SystemReady. Arm SystemReady defined the Base Boot Requirements (BBR) specification that currently provides three recipes, two of which are related to UEFI: 1) SBBR: which requires UEFI, ACPI and SMBIOS compliance suitable for enterprise-level operating environments such as Windows, Red Hat Enterprise Linux, and VMware ESXi; and 2) EBBR: which requires compliance to a set of UEFI interfaces as defined in the Embedded Base Boot Requirements (EBBR) suitable for embedded environments such as Yocto. Many Linux and BSD distributions can support both recipes.
In December 2018, Microsoft announced Project Mu, a fork of TianoCore EDK II used in Microsoft Surface and Hyper-V products. The project promotes the idea of firmware as a service.[7]
The latest UEFI specification, version 2.11, was published in December 2024.[8]
Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore EDK II on top of OPAL,[9] the OpenPOWER abstraction layer, running in little-endian mode.[10] For MIPS, there also exists an unofficial project, based on the original EDK.[11] [12] However, both projects have since been abandoned as of November 2016 and September 2015 respectively.
UEFI only allows executing UEFI applications that match the firmware's bit-width, even if the processor supports smaller or larger bit-widths. For example, a 64-bit UEFI firmware may only execute 64-bit UEFI applications, even if the processor has a 32-bit processor mode. Some low-end computers have been shipped with 32-bit UEFI firmware running on 64-bit CPUs.[13] Once a UEFI application ends the boot services and gets granted full control over the system, it becomes possible to change the processor execution mode. However, calling runtime services requires shortly changing back to the original processor mode,[14] as runtime services may only be called from the same processor mode as the firmware implementation.
The Linux kernel added support for booting 64-bit kernels on 32-bit UEFI firmware implementations with x86-64 CPUs since version 3.15, requiring the UEFI boot loader to support the EFI handover protocol.[15] The EFI handover protocol allows UEFI boot loaders to defer the UEFI initialization to the kernel's EFI boot stub, so that only the kernel does the UEFI initialization.[16] [17] [18]
In addition to the standard PC disk partition scheme that uses a master boot record (MBR), UEFI also works with the GUID Partition Table (GPT) partitioning scheme, which is free from many of the limitations of MBR. In particular, the MBR limits on the number and size of disk partitions (up to four primary partitions per disk, and up to 2 TB per disk) are relaxed. More specifically, GPT allows for a maximum disk and partition size of 8 ZiB with 512 byte sectors.[19] The UEFI specification only supports FAT12/16/32 partitions that are on GPT or MBR disks as well as El Torito-formatted optical discs. Although GPT is a part of the UEFI standard, it may also be usable by BIOS PCs to boot an operating system off of.
Support for GPT in Linux is enabled by turning on the option CONFIG_EFI_PARTITION (EFI GUID Partition Support) during kernel configuration.[20] This option allows Linux to recognize and use GPT disks after the system firmware passes control over the system to Linux.
For reverse compatibility, Linux can use GPT disks in BIOS-based systems for both data storage and booting, as both GRUB 2 and Linux are GPT-aware. Such a setup is usually referred to as BIOS-GPT. As GPT incorporates the protective MBR, a BIOS-based computer can boot from a GPT disk using a GPT-aware boot loader stored in the protective MBR's bootstrap code area. In the case of GRUB, such a configuration requires a BIOS boot partition for GRUB to embed its second-stage code due to absence of the post-MBR gap in GPT partitioned disks (which is taken over by the GPT's Primary Header and Primary Partition Table). Commonly 1 MB in size, this partition's Globally Unique Identifier (GUID) in GPT scheme is and is used by GRUB only in BIOS-GPT setups. From GRUB's perspective, no such partition type exists in case of MBR partitioning. This partition is not required if the system is UEFI-based because no embedding of the second-stage code is needed in that case.[21]
UEFI systems can access GPT disks and boot directly from them, which allows Linux to use UEFI boot methods. Booting Linux from GPT disks on UEFI systems involves creation of an EFI system partition (ESP), which contains UEFI applications such as bootloaders, operating system kernels, and utility software.[22] [23] Such a setup is usually referred to as UEFI-GPT, while ESP is recommended to be at least 512 MB in size and formatted with a FAT32 filesystem for maximum compatibility.
For backward compatibility, some UEFI implementations also support booting from MBR-partitioned disks through the Compatibility Support Module (CSM) that provides legacy BIOS compatibility. In that case, booting Linux on UEFI systems is the same as on legacy BIOS-based systems.
Some of the EFI's practices and data formats mirror those of Microsoft Windows.[24] [25]
Windows 11, 64-bit versions of Windows Vista SP1/SP2 and 7, and both 32-bit and 64-bit versions of Windows 8, 8.1, and 10 can boot from a GPT disk that is larger than 2 TB.
ExitBootServices call), and they 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.Beyond loading an OS, UEFI can run UEFI applications, which reside as files on the EFI system partition. They can be executed from the UEFI Shell, by the firmware's boot manager, or by other UEFI applications. UEFI applications can be developed and installed independently of the original equipment manufacturers (OEMs).
A type of UEFI application is an OS boot loader such as GRUB, rEFInd, systemd-boot, and Windows Boot Manager, which loads some OS files into memory and executes them. Also, an OS boot loader can provide a user interface to allow the selection of another UEFI application to run. Utilities like the UEFI Shell are also UEFI applications.
EFI defines protocols as a set of software interfaces used for communication between two binary modules. All EFI drivers must provide services to others via protocols. The EFI Protocols are similar to the BIOS interrupt calls.
Some architecture-specific (non-EFI Byte Code) EFI drivers for some device types can have interfaces for use by the OS. This allows the OS to rely on EFI for drivers to perform basic graphics and network functions before, and if, operating-system-specific drivers are loaded.
In other cases, the EFI driver can be filesystem drivers that allow for booting from other types of disk volumes. Examples include efifs for 37 file systems (based on GRUB2 code),[27] used by Rufus for chain-loading NTFS ESPs.[28]
The EFI 1.0 specification defined a UGA (Universal Graphic Adapter) protocol as a way to support graphics features. UEFI did not include UGA and replaced it with GOP (Graphics Output Protocol).[29]
UEFI 2.1 defined a "Human Interface Infrastructure" (HII) to manage user input, localized strings, fonts, and forms (in the HTML sense). These enable original equipment manufacturers (OEMs) or independent BIOS vendors (IBVs) to design graphical interfaces for pre-boot configuration. UEFI uses UTF-16 to encode strings by default.
Most early UEFI firmware implementations were console-based. Today many UEFI firmware implementations are GUI-based.
See main article: EFI system partition.
An EFI system partition, often abbreviated to ESP, is a data storage device partition that is used in computers adhering to the UEFI specification. Accessed by the UEFI firmware when a computer is powered up, it stores UEFI applications and the files these applications need to run, including operating system boot loaders. Supported partition table schemes include MBR and GPT, as well as El Torito volumes on optical discs. For use on ESPs, UEFI defines a specific version of the FAT file system, which is maintained as part of the UEFI specification and independently from the original FAT specification, encompassing the FAT32, FAT16 and FAT12 file systems.[30] The ESP also provides space for a boot sector as part of the backward BIOS compatibility.
Computers are started up by a process which has been called booting: the computer loads its operating software by means of a very small program built into the hardware, which typically loads a program, still small, to load and start the operating system (OS).
OS boot loaders can be automatically detected by UEFI, which enables easy booting from removable devices such as USB flash drives. This automated detection relies on standardized file paths to the OS boot loader, with the path varying depending on the computer architecture. The format of the file path is defined as
