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 and
bit blit provided by GOP during runtime mode. ; UEFI
memory map services ;
SMM services ;
ACPI services ;
SMBIOS services ;
Devicetree 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. 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,
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 (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. UEFI uses
UTF-16 to encode strings by default; since at least UEFI 2.4, it allows using
ASCII to encode ASCII-only strings. 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 volumes on optical discs. The ESP also provides space for a boot sector as part of the backward BIOS compatibility.
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 ; for example, the file path to the OS loader on an
x86-64 system is , It also provides required legacy
System Management Mode (SMM) functionality, called
CompatibilitySmm, as an 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 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. Currently most computers based on Intel platforms do not support CSM.
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 boot manager The UEFI specification defines a protocol known as
Secure Boot, which 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 a number of
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). ,
FreeBSD support is in a planning stage.
UEFI shell UEFI provides a
shell environment, which can be used to execute other UEFI applications, including UEFI
boot loaders. Apart from that, commands available in the UEFI shell can be used 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). 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. Methods used for launching UEFI shell depend on the manufacturer and model of the system
motherboard. Some of them already provide a direct option in firmware setup for launching, e.g. compiled x86-64 version of the shell needs to be made available as /SHELLX64.EFI. Some other systems have an already embedded UEFI shell which can be launched by appropriate key press combinations. For other systems, the solution is either creating an appropriate USB flash drive or adding manually (bcfg) a boot option associated with the compiled version of shell.
Windows 8,
Windows 8.1,
Windows 10, and
Fwupd for Linux each support the UEFI Capsule.
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 process is more complex, for example
PCI Express devices detection and initialization. In some ARM-based Android and Windows Phone devices, the UEFI boot loader is stored in the
eMMC or
eUFS flash memory. == Classes ==