Unified Extensible Firmware Interface or UEFI is a specification for the firmware architecture of a computing platform. When a computer is powered on, the UEFI implementation typically runs first, before the operating system or any other program is loaded. 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, although it can provide backwards compatibility with the BIOS using CSM booting. Unlike the BIOS, which was originally developed by IBM as a proprietary architecture, the UEFI specification is managed by an industry consortium. Most production firmware implementations for both remain 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.
History 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 for which Itanium was targeted. 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 EFI implementation, Tiano, was released by Intel in 2004. Tiano has since then been superseded by EDK and EDK II and is now maintained by the TianoCore community.
In July 2005, 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.
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 introduced Arm ServerReady, a compliance certification program intended to ensure standard operating systems and hypervisors run 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 incorporates a service-based firmware delivery model.
The latest UEFI specification, version 2.11, was published in December 2024.
Compatibility
Processor compatibility UEFI supports processor architectures that are 32-bit or higher. However, only processors with a little-endian mode are supported. The UEFI specification, version 2.11, has official documentation for the following processor architectures: x86 (IA-32, x86-64) Itanium (IA-64) ARM (AArch32, AArch64) RISC-V (32-bit, 64-bit, 128-bit) LoongArch (32-bit, 64-bit)
Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore EDK II on top of OPAL, the OpenPOWER abstraction layer, running in little-endian mode. For MIPS, there also exists an unofficial project, based on the original EDK. 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. 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, 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. 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.
Disk device compatibility
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. 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.
Linux
Support for GPT in Linux is enabled by turning on the option CONFIG_EFI_PARTITION (EFI GUID Partition Support) during kernel configuration. 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.
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. 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.
Microsoft Windows
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.
Features
Interface functions The basic building block of the UEFI APIs is the interface function: an ordinary function in the C programming language with a return type of EFI_STATUS. Invoking an interface entails making the corresponding function call. As of , Rust is used in EDK2 framework for enhance security.https://dl.acm.org/doi/10.1145/3728929
Services EFI defines two types of services: boot services and runtime services. Boot services are available only while the firmware owns the platform (i.e., before the 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. Each service exposes one or more interface functions.
Graphics Output Protocol (GOP) services The Graphics Output Protocol (GOP) provides runtime services; see also Graphics features section below. The operating system is permitted to directly write to the framebuffer and BLT provided by GOP during runtime mode. UEFI memory map services This boot service allows the bootloader to obtain information on how the memory is laid out. SMM services The SMM ("ring -2") is an x86 mode that provides secure code execution isolated from all lower rings. Modern UEFI generalizes the concept to Management Mode (MM) to also encompass alternative technologoies such as TrustZone. One common use of the MM/SMM services is as a secure store of variables. ACPI services SMBIOS services Devicetree services (for RISC processors) These runtime services allow the operating system to obtain information about the installed hardware and how to make use of them. Variable services UEFI variables store non-volatile data. The variable storage is conceptually divided into namespaces identified by GUIDs. Each namespace can contain any number of variable entries, which are key/value pairs (Unicode string key, variable-length byte-array value). Each entry also carries an attributes bitfield, which can restrict its access to only boot or run-time (among other, more advanced, uses). Some UEFI variables are shared between platform firmware and operating systems. For example, the OS may set the and variables under the namespace to influence the UEFI boot manager's future choices. Other variables may be private to one side. For example, UEFI variables can be used by an OS to keep crash messages in NVRAM after a crash for the operating system to retrieve after a reboot. Time services UEFI provides time services. Time services include support for time zone and daylight saving fields, which allow the hardware real-time clock to be set to local time or UTC. On machines using a PC-AT real-time clock, Microsoft Windows does not use the EFI time zone and DST fields, and expects the hardware clock to provide local time like traditional BIOS-based Windows did. As a result the HW clock cannot be set to UTC unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC.
Protocols EFI defines protocols as a set of software interfaces used for communication between two binary modules. An EFI Protocol is a C struct definition tied to a GUID. The struct usually includes a number of function pointers for the interface functions as well as some fields to store the data used by these functions.