UEFI
Unified Extensible Firmware Interface 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, 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 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 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.The first open-source UEFI 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 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. 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.
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 , 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 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 defined the Base Boot Requirements 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 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.
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:Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore on top of OPAL, the OpenPOWER abstraction layer, running in little-endian mode. For MIPS, there also exists an unofficial project
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, UEFI also works with the GUID Partition Table 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 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 optionCONFIG_EFI_PARTITION 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. Commonly 1 MB in size, this partition's Globally Unique Identifier 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, 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 that provides legacy BIOS compatibility. In that case, booting Linux on UEFI systems is the same as on legacy BIOS-based systems.
Microsoft Windows
Some of the EFI's practices and data formats mirror those of 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
Services
EFI defines two types of services: boot services and runtime services. Boot services are available only while the firmware owns the platform, 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.; Graphics Output Protocol services
; UEFI memory map services
; SMM services
; ACPI services
; SMBIOS services
; Devicetree services
; Variable services
; Time services
Applications
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.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.
Protocols
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.Device drivers
In addition to standard instruction set architecture-specific device drivers, EFI provides for a ISA-independent device driver stored in non-volatile memory as EFI byte code or EBC. System firmware has an interpreter for EBC images. In that sense, EBC is analogous to Open Firmware, the ISA-independent firmware used in PowerPC-based Apple Macintosh and Sun Microsystems SPARC computers, among others.Some architecture-specific 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, used by Rufus for chain-loading NTFS ESPs.