Graphics Output Protocol

UEFI (Unified Extensible Firmware Interface) is a set of specifications written by the UEFI Forum. They define the architecture of the platform firmware used for booting and its interface for interaction with the operating system. Examples of firmware that implement these specifications are AMI Aptio, Phoenix SecureCore, TianoCore EDK II and InsydeH2O.

UEFI replaces the BIOS which 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. Intel developed the original ''Extensible Firmware Interface'' (''EFI'') specifications. Some of the EFI's practices and data formats mirror those of Microsoft Windows. In 2005, UEFI deprecated EFI 1.10 (the final release of EFI).

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 (such as 16-bit real mode, 1MB addressable memory space, assembly language programming, and PC AT hardware) 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).

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

The latest UEFI specification, version 2.9, was published in March 2021.

The first open source UEFI implementation, Tiano, was released by Intel in 2004. Tiano has since then been superseded by EDK and EDK2 and is now maintained by the TianoCore community.

In December 2018, Microsoft announced Project Mu, a fork of TianoCore EDK2 used in Microsoft Surface and Hyper-V products. The project promotes the idea of Firmware as a Service.

In October 2018, Arm announce
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 i
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 distros can support both recipes.

Advantages

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 over a traditional BIOS system:

* Ability to boot a disk containing large partitions (over 2  TB) with a GUID Partition Table (GPT)
* Flexible pre-OS environment, including network capability, GUI, multi language
* 32-bit (for example IA-32, ARM32) or 64-bit (for example x64, AArch64) pre-OS environment
* C language programming
* Modular design
* Backward and forward compatibility

Compatibility

Processor compatibility

As of version 2.5, processor bindings exist for Itanium, x86, x86-64, ARM (AArch32) and ARM64 (AArch64). Only little-endian processors can be supported. Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore on top of OPAL, the OpenPOWER abstraction layer, running in little-endian mode. Similar projects exist for MIPS and RISC-V. As of UEFI 2.7, RISC-V processor bindings have been officially established for 32-, 64- and 128-bit modes.

Standard PC BIOS is limited to a 16-bit processor mode and 1 MB of addressable memory space, resulting from the design based on the IBM 5150 that used a 16-bit Intel 8088 processor. In comparison, the processor mode in a UEFI environment can be either 32-bit ( x86-32, AArch32) or 64-bit ( x86-64, Itanium, and AArch64). 64-bit UEFI firmware implementations support long mode, which allows applications in the preboot environment to use 64-bit addressing to get direct access to all of the machine's memory.

UEFI requires the firmware and operating system loader (or kernel) to be size-matched; that is, a 64-bit UEFI firmware implementation can load only a 64-bit operating system (OS) boot loader or kernel (unless the CSM-based Legacy boot is used) and the same applies to 32-bit. After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over. At this point, the kernel can change processor modes if it desires, but this bars usage of the runtime services (unless the kernel switches back again). As of version 3.15, the Linux kernel supports 64-bit kernels to be booted on 32-bit UEFI firmware implementations running on x86-64 CPUs, with ''UEFI handover'' support from a UEFI boot loader as the requirement. UEFI handover protocol deduplicates the UEFI initialization code between the kernel and UEFI boot loaders, leaving the initialization to be performed only by the Linux kernel's ''UEFI boot stub''.

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

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

The 64-bit versions of Windows Vista SP1 and later and 32-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 (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.

; 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 provided by GOP during runtime mode.

; UEFI Memory map services

; SMM services

; ACPI services

; SMBIOS services

; Device tree services (for RISC processors)

; Variable services
: UEFI variables provide a way to store data, in particular non-volatile data. Some UEFI variables are shared between platform firmware and operating systems. Variable namespaces are identified by GUIDs, and variables are key/value pairs. For example, UEFI variables can be used 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, by default the hardware clock still has to be set to local time for compatibility with BIOS-based Windows, unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC.

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

A type of UEFI application is an OS boot loader such as GRUB, rEFInd, Gummiboot, 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 (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), used by Rufus for chain-loading NTFS ESPs.

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

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.

Most early UEFI firmware implementations were console-based. Today many UEFI firmware implementations are GUI-based.

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