UEFI

Unified Extensible Firmware Interface
Abbreviation	UEFI
Status	Published
Year started	2006
Latest version	2.11 16 December 2024
Organization	UEFI Forum
Related standards	ACPI UEFI Platform Initialization
Predecessor	BIOS on IBM PC compatible computers
Domain	Firmware
Website	uefi.org

Boot order selection menu on a Lenovo ThinkPad T470 with both UEFI and BIOS support

The UEFI implementation is usually stored on NOR-based flash memory located on the motherboard. Various I/O protocols can be used, SPI being the most common.

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 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 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

See also: GPT § Operating systems support, and Protective MBR

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 (2 × 2⁴⁰ bytes) per disk) are relaxed. More specifically, GPT allows for a maximum disk and partition size of 8 ZiB (8 × 2⁷⁰ bytes) 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

See also: EFI System partition § 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 21686148-6449-6E6F-744E-656564454649 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.

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 BootOrder and Boot#### variables under the EFI_GLOBAL_VARIABLE 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.

All EFI drivers must provide services to others via protocols. Their role is therefore analogous to BIOS interrupt calls and the associated vector tables.

Applications

Interaction between the EFI boot manager and EFI drivers

UEFI executes independent programs known as UEFI applications, which are stored as files on the EFI system partition. These can be launched by the firmware boot manager or other UEFI applications. They may be developed independently of the original equipment manufacturer (OEM).

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. The UEFI Shell is an example of a UEFI application that launches other UEFI applications. Some OS loaders do the same, providing a user interface to allow the selection of another UEFI application to run.

Device drivers

UEFI drivers are a special class of UEFI applications, differing from regular applications by having a part that stays loaded when its entry point exits. They may be loaded by the UEFI boot manager or by an UEFI application. Like services, there are boot- and run-time drivers, the former being terminated at the ExitBootServices() call.

EFI drivers provide protocols for others to call. A driver that persists into runtime can be called on by the operating system to perform basic functions before, and if, operating-system-specific drivers are loaded.

EFI drivers can not only provide hardware support (device driver), but also act as filesystem drivers that allow for accessing and booting from other types of disk volumes. Examples include efifs for 37 file systems (based on GRUB2 code), used by Rufus for chain-loading NTFS ESPs.

In addition to standard instruction set architecture-specific device drivers, EFI allows the use of drivers written in EFI byte code (EBC). An interpreter in the system firmware executes the code. 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. A compiler used to be available for generating EBC from C source code and its discontinuation by Intel had rendered EBC defunct.

Graphics features

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). These protocols are generally implemented by the Video BIOS. They take the place of the legacy INT 10h and VESA BIOS Extensions, the basic cross-vendor mechanisms of graphics output on IBM PC.

Most early UEFI firmware implementations were console-based. Today many UEFI firmware implementations are GUI-based. 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; since at least UEFI 2.4, it allows using ASCII to encode ASCII-only strings.

EFI system partition

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. The ESP retains the BIOS-style boot sector from FAT, though this is not used by UEFI.

Booting

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).

UEFI booting

Unlike the legacy PC BIOS, UEFI does not rely on boot sectors on the computer's data storage, defining instead a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager checks the boot configuration and, based on its settings, then executes the specified OS boot loader or operating system kernel. The boot configuration is defined by variables stored in the computer's persistent NVRAM storage, including variables that indicate the file system paths to OS loaders or OS kernels.

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 <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is \efi\boot\bootx64.efi, and \efi\boot\bootaa64.efi on ARM64 architecture.

Boot process

Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. The alternative is to boot from an EFI System Partition on MBR-partitioned disks, commonly called UEFI-MBR. UEFI-MBR capability is required by the UEFI specification, but some UEFI firmware implementations immediately switch to BIOS-based CSM booting depending on the type of the boot disk's partition table, effectively preventing it from occurring.

It is also common for a boot manager to have a textual user interface to allow the user to select the desired OS (or setup utility) from a list of available boot options.

On PC platforms, firmware supporting UEFI boot is often referred to as a "UEFI BIOS", though some newer x86 platforms exclude CSM support entirely.

CSM booting

To ensure backward compatibility, UEFI firmware implementations on PC-class machines could support booting in legacy BIOS mode from MBR-partitioned disks through the Compatibility Support Module (CSM) that provides legacy BIOS compatibility. In this scenario, booting is performed in the same way as on legacy BIOS-based systems, by ignoring the partition table and relying on the content of a boot sector.

The Compatibility Support Module allows legacy operating systems and some legacy option ROMs that do not support UEFI to still be used. It also provides required legacy System Management Mode (SMM) functionality (CompatibilitySmm) in addition to features provided by the UEFI SMM. An example of such a legacy SMM functionality is providing USB legacy support for keyboard and mouse, by emulating their classic PS/2 counterparts.

In November 2017, Intel announced that it planned to phase out support CSM for client platforms by 2020.

In July 2022, Kaspersky Labs published information regarding a Rootkit designed to chain boot malicious code on machines using Intel's H81 chipset and the Compatibility Support Module of affected motherboards.

In August 2023, Intel announced that it planned to phase out CSM support for server platforms by 2024.

Network booting

The UEFI specification includes support for booting over network via the Preboot Execution Environment (PXE). PXE booting network protocols include Internet Protocol (IPv4 and IPv6), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) and iSCSI.

OS images can be remotely stored on storage area networks (SANs), with Internet Small Computer System Interface (iSCSI) and Fibre Channel over Ethernet (FCoE) as supported protocols for accessing the SANs.

Version 2.5 of the UEFI specification adds support for accessing boot images over HTTP.

Secure Boot

See also: Secure Boot criticism

Example of an active Secure Boot as detected by rEFInd boot manager

The UEFI specification defines a Secure Boot that can secure the boot process by preventing the loading of UEFI drivers or OS boot loaders that are not signed with an acceptable digital signature. When Secure Boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "platform key" (PK) to be written to the firmware. Once the key is written, Secure Boot enters "User" mode, where only UEFI drivers and OS boot loaders signed with the platform key can be loaded by the firmware. Additional "key exchange keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the platform key. Secure Boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key.

Secure Boot is supported by Windows 8 and 8.1, Windows Server 2012 and 2012 R2, Windows 10, Windows Server 2016, 2019, and 2022, and Windows 11, VMware vSphere 6.5 and several Linux distributions including Fedora (since version 18), openSUSE (since version 12.3), RHEL (since version 7), CentOS (since version 7), Debian (since version 10), Ubuntu (since version 12.04.2), Linux Mint (since version 21.3), and AlmaLinux OS (since version 8.4). As of January 2025, FreeBSD support is in its planning stage.

UEFI shell

Example of a UEFI shell 2.2 session

The UEFI standards include a specification for a shell environment. The shell is a UEFI application that can be used to execute other UEFI applications, including UEFI boot loaders. It also includes built-in commands for obtaining various other information about the system or the firmware, including getting the memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading UEFI drivers, and editing text files (edit). It implements a scripting language with support for if-statements, for-loops, and environment variables.

The UEFI shell is not a mandatory component of the firmware. It tends to be pre-loaded into server motherboards, which allows it to be launched by appropriate key press combinations. Some other motherboards provide a direct option in firmware setup for launching, e.g. compiled x86-64 version of the shell needs to be made available as <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. For other systems, the solution is either creating an appropriate USB flash drive (as BOOTxxxx.efi, making use of boot loader auto-detection) or adding manually (bcfg) a boot option associated with the compiled version of shell.

Source code for a UEFI shell can be downloaded from the Intel's TianoCore UDK/EDK2 project. A pre-built ShellBinPkg is also available. Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems.

Commands

The following is a list of commands supported by the EFI shell v1.

• alias
• attrib
• bcfg
• cd
• cls
• comp
• cp
• date
• dblk
• dh
• dmpstore
• echo
• Edd30
• EddDebug
• edit
• err
• guid
• help
• load
• ls
• map
• mem
• memmap
• mkdir
• mm
• mode
• mount
• pause
• pci
• reset
• rm
• set
• stall
• time
• type
• unload
• ver
• vol

The shell v2 includes a much broader set of features in its default build. For example, there is a new devtree for showing a tree of devices.

Extensions

Extensions to UEFI 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 system partition on the hard drive, which would add additional functions to the standard UEFI firmware stored on the motherboard's ROM.

UEFI Capsule

UEFI Capsule defines a firmware update interface. The OS can use a runtime service to hand a signed firmware capsule, which contains the new firmware image, to the UEFI layer for processing at next boot. Other capsule types may contain a boot logo or a CPU microcode. At the next boot the firmware checks the cryptographic signature on the capsule before applying it. This interface is used by Microsoft Windows since Windows 8, and by various Linux distributions through Fwupd.

Hardware

Like BIOS, UEFI initializes and tests system hardware components, and then loads the boot loader from a mass storage device or through a network connection. In x86 systems, the UEFI firmware is usually stored in the NOR flash chip of the motherboard, and the boot loader stored in a hard drive or solid state drive. In some ARM-based Android and Windows Phone devices, both the UEFI firmware and the boot loader are stored in the main flash chip (eMMC or eUFS) – see Booting process of Android devices.

On systems with advanced periphery buses such as PCI Express, additional steps are required for devices detection and initialization.

Classes

UEFI machines can have one of the following classes, which were used to help ease the transition to UEFI:

• Class 0: Legacy BIOS
• Class 1: UEFI with a CSM interface and no external UEFI interface. The only UEFI interfaces are internal to the firmware.
• Class 2: UEFI with CSM and external UEFI interfaces, e.g. UEFI Boot.
• Class 3: UEFI without a CSM interface and with an external UEFI interface.
• Class 3+: UEFI class 3 that has Secure Boot enabled.

Starting from the 10th Gen Intel Core, Intel no longer provides Legacy Video BIOS for the iGPU (Intel Graphics Technology). Legacy boot with those CPUs requires a Legacy Video BIOS, which can still be provided by a video card.

Boot stages

SEC – Security Phase

This is the first stage of the UEFI boot but may have platform specific binary code that precedes it. (e.g., Intel ME, AMD PSP, CPU microcode). It consists of minimal code written in assembly language for the specific architecture. It initializes a temporary memory (often CPU cache-as-RAM (CAR), or SoC on-chip boot processor) and serves as the system's software root of trust with the option of verifying PEI before hand-off.

Responsibilities

• Initialization of temporary memory for next stage, PEI.
• Root of trust, by the means of verifying the integrity of PEI.
• Passing handoff information to the PEI foundation. The information includes the location and size of temporary memory, location and size of stack and state of the platform.

PEI – Pre-EFI Initialization

The second stage of UEFI boot consists of a dependency-aware dispatcher that loads and runs PEI modules (PEIMs) to handle early hardware initialization tasks such as main memory initialization (initialize memory controller and DRAM) and firmware recovery operations. Additionally, it is responsible for discovery of the current boot mode and handling many ACPI S3 operations. In the case of ACPI S3 resume, it is responsible for restoring many hardware registers to a pre-sleep state. PEI also uses CAR. Initialization at this stage involves creating data structures in memory and establishing default values within these structures.

This stage has several components including PEI foundation, PEIMs and PPI. Due to less resources available in this stage, this stage must be minimal and do minimal preparations for the next stage, DXE, which is richer.

PEI Foundation

After SEC phase hand off, platform responsibility is taken by PEI Foundation. Its responsibilities are:

• Successful dispatching of PEIMs (pre-EFI initialization modules).
• Initializing permanent memory (RAM).
• Handing over to the next stage, DXE.
• Facilitating the communication of PEIMs called PPI.

PEI Dispatcher

This component is responsible for invoking PEIMs and managing their dependencies.

Pre-EFI Initialization Modules

These are minimal PEI drivers that are responsible for initialization of hardware components, such as permanent memory, CPU, chipset and motherboard. Each of the PEIMs have single responsibilities and focus on single initialization. These drivers come from different vendors.

PEIMs-to-PEIMs Interfaces

This is a data structure that composed of GUID pairs of pointers. PPIs are discovered by PEIMs through PEI services.

After minimal initialization of the system for DXE, PEI foundation locates and passes control to DXE. The PEI foundation dispatches DXE foundation through special PPI called IPL (Initial Program Load).

DXE – Driver Execution Environment

This stage consists of C modules and a dependency-aware dispatcher. With main memory now available, CPU, chipset, mainboard and other I/O devices are initialized in DXE and BDS. Initialization at this stage involves assigning EFI device paths to the hardware connected to the motherboard, and transferring configuration data to the hardware. In this stage, UEFI drivers / Option ROMs of PCI / AMBA devices are executed.

BDS – Boot Device Select (Boot Manager)

BDS is a part of the DXE. In this stage, boot devices are initialized, and the operating system boot loaders (such as Windows Boot Manager) are started.

TSL – Transient System Load

This is the stage between boot device selection and hand-off to the OS. At this point one may enter a UEFI shell, or execute a UEFI application such as the OS boot loader.

RT – Runtime

The UEFI hands off to the operating system (OS) after ExitBootServices() is executed. A UEFI compatible OS is now responsible for exiting boot services triggering the firmware to unload all no longer needed code and data, leaving only runtime services code/data, e.g. SMM and ACPI. A typical modern OS will prefer to use its own programs (such as kernel drivers) to control hardware devices.

When a legacy OS is used, CSM will handle this call ensuring the system is compatible with legacy BIOS expectations.

Usage

Implementations

Microsoft Surface UEFI, the UEFI used on all Surface models made after 2015

Intel's implementation of EFI is the Intel Platform Innovation Framework, codenamed Tiano. Tiano runs on Intel's XScale, Itanium, IA-32 and x86-64 processors, and is proprietary software, although a portion of the code has been released under the BSD license or Eclipse Public License (EPL) as TianoCore EDK II. TianoCore can be used as a payload for coreboot.

Phoenix Technologies' implementation of UEFI is branded as SecureCore Technology (SCT). American Megatrends offers its own UEFI firmware implementation known as Aptio, while Insyde Software offers InsydeH2O, and Byosoft offers ByoCore.

In December 2018, Microsoft released an open source version of its TianoCore EDK2-based UEFI implementation from the Surface line, Project Mu.

An implementation of the UEFI API was introduced into the Universal Boot Loader (Das U-Boot) in 2017. On the ARMv8 architecture Linux distributions use the U-Boot UEFI implementation in conjunction with GNU GRUB for booting (e.g. SUSE Linux), the same holds true for OpenBSD. For booting from iSCSI iPXE can be used as a UEFI application loaded by U-Boot.

Platforms

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. These systems 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. 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 (now macOS). 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 Intel's implementation of UEFI. New mobile, desktop and server products, using Intel's implementation of UEFI, started shipping in 2006. For instance, boards that use the Intel 945 chipset series use Intel's UEFI firmware implementation.

Since 2005, EFI has also been implemented on non-PC architectures, such as embedded systems based on XScale cores.

The EDK (EFI Developer Kit) includes an NT32 target, which allows EFI firmware and EFI applications to run within a Windows application. However, no direct hardware access is allowed by EDK NT32. This means only a subset of EFI application and drivers can be executed by the EDK NT32 target.

In 2008, more x86-64 systems adopted UEFI. While many of these systems still allow booting only the BIOS-based OSes via the Compatibility Support Module (CSM) (thus not appearing to the user to be UEFI-based), other systems started to allow booting UEFI-based OSes. For example, IBM x3450 server, MSI motherboards with ClickBIOS and HP EliteBook Notebook PCs.

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.

In 2011, major vendors (such as ASRock, Asus, Gigabyte, and MSI) launched several consumer-oriented motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series AM3+ chipsets with UEFI.

With the release of Windows 8 in October 2012, Microsoft's certification requirements now require that computers include firmware that implements the UEFI specification. Furthermore, if the computer supports the "Connected Standby" feature of Windows 8 (which allows devices to have power management comparable to smartphones, with an almost instantaneous return from standby mode), then the firmware is not permitted to contain a Compatibility Support Module (CSM). As such, systems that support Connected Standby are incapable of booting Legacy BIOS operating systems.

In October 2017, Intel announced that it would remove legacy PC BIOS support from all its products by 2020, in favor of UEFI Class 3. By 2019, all computers based on Intel platforms no longer have legacy PC BIOS support.

Operating systems

A operating system that can be booted from (U)EFI is called a (U)EFI-aware operating system, defined by (U)EFI specification. Here the term booted from a (U)EFI means directly booting the system using a (U)EFI operating system loader stored on any storage device. The default location for the operating system loader is <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI, where short name of the machine type can be IA32, X64, IA64, ARM or AA64. Some operating systems vendors may have their own boot loaders. They may also change the default boot location.

• The Linux kernel has been able to use EFI at boot time since the early 2000s, using the elilo EFI boot loader and more recently, EFI versions of GRUB or systemd-boot. Grub+Linux also supports booting from a GUID partition table without UEFI. The distribution