 | |
| Abbreviation | UEFI |
|---|---|
| Status | Published |
| Year started | 2006[a] |
| Latest version | 2.11[1] December 16, 2024 |
| Organization | UEFI Forum |
| Related standards | |
| Predecessor | BIOS onIBM PC compatible computers[b] |
| Domain | Firmware |
| Website | uefi |
Unified Extensible Firmware Interface (UEFI,/ˈjuːɪfaɪ/ or as an acronym)[c] is aspecification for the firmwarearchitecture of acomputing platform. When a computeris powered on, the UEFI-implementation is typically the first that runs, before starting theoperating system. Examples includeAMI Aptio,Phoenix SecureCore,TianoCore EDK II,InsydeH2O.
UEFI replaces theBIOS that was present in theboot ROM of allpersonal computers that areIBM PC compatible,[5][6] although it can providebackwards compatibility with the BIOS usingCSM booting. Unlike its predecessor, BIOS, which is ade facto standard originally created byIBM as proprietary software, UEFI is an open standard maintained by an industryconsortium. Like BIOS, most UEFI implementations are proprietary.
Intel developed the originalExtensible Firmware Interface (EFI) specification. The last Intel version of EFI was 1.10 released in 2005. Subsequent versions have been developed as UEFI by theUEFI Forum.
UEFI is independent of platform and programming language, butC is used for the reference implementation TianoCore EDKII.
The original motivation for EFI came during early development of the first Intel–HPItanium systems in the mid-1990s.BIOS limitations (such as 16-bitreal mode, 1 MB addressable memory space,[7]assembly language programming, andPC AT hardware) had become too restrictive for the larger server platforms Itanium was targeting.[8] The effort to address these concerns began in 1998 and was initially calledIntel Boot Initiative.[9] It was later renamed toExtensible Firmware Interface (EFI).[10][11]
The firstopen source UEFI implementation, Tiano, was released by Intel in 2004. Tiano has since then been superseded by EDK[12] and EDK II[13] and is now maintained by the TianoCore community.[14]
In July 2005, Intel ceased its development of the EFI specification at version 1.10, and contributed it to theUnified EFI Forum, which has developed the specification as theUnified 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.[8][15]
Version 2.0 of the UEFI specification was released on 31 January 2006. It addedcryptography and security.
Version 2.1 of the UEFI specification was released on 7 January 2007. It added network authentication and theuser interface architecture ('Human Interface Infrastructure' in UEFI).
In October 2018, Arm announcedArm ServerReady, a compliance certification program for landing the generic off-the-shelf operating systems andhypervisors on Arm-based servers. The program requires the system firmware to comply with Server Base Boot Requirements (SBBR). SBBR requires UEFI,ACPI andSMBIOS compliance. In October 2020, Arm announced the extension of the program to theedge andIoT market. The new program name isArm 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.
In December 2018,Microsoft announced Project Mu, a fork of TianoCore EDK II used inMicrosoft Surface andHyper-V products. The project promotes the idea offirmware as a service.[16]
The latest UEFI specification, version 2.11, was published in December 2024.[17]
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 BIOS:[18]
With UEFI, it is possible to store product keys for operating systems such as Windows, on the UEFI firmware of the device.[21][22][23] UEFI is required forSecure Boot on devices shipping with Windows 8[24][25] and above.
It is also possible for operating systems to access UEFI configuration data.[26]
As of version 2.5, processor bindings exist for Itanium, x86, x86-64,ARM (AArch32) andARM64 (AArch64).[27] Onlylittle-endian processors can be supported.[28] Unofficial UEFI support is under development for POWERPC64 by implementingTianoCore on top of OPAL,[29] the OpenPOWER abstraction layer, running in little-endian mode.[30] Similar projects exist forMIPS[31] andRISC-V.[32] As of UEFI 2.7, RISC-V processor bindings have been officially established for 32-, 64- and 128-bit modes.[33]
Standard PC BIOS is limited to a 16-bit processor mode and 1 MB of addressable memory space, resulting from the design based on theIBM 5150 that used a 16-bitIntel 8088 processor.[8][34] In comparison, the processor mode in a UEFI environment can be either 32-bit (IA-32, AArch32) or 64-bit (x86-64, Itanium, and AArch64).[8][35] 64-bit UEFI firmware implementations supportlong mode, which allows applications in the preboot environment to use 64-bit addressing to get direct access to all of the machine's memory.[36]
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-basedlegacy boot is used) and the same applies to 32-bit. After the system transitions fromboot services toruntime 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).[37]: sections 2.3.2 and 2.3.4 As of version 3.15, theLinux kernel supports 64-bit kernels to bebooted on 32-bit UEFI firmware implementations running onx86-64 CPUs, withUEFI handover support from a UEFI boot loader as the requirement.[38] UEFI handover protocoldeduplicates the UEFI initialization code between the kernel and UEFI boot loaders, leaving the initialization to be performed only by the Linux kernel'sUEFI boot stub.[39][40]
In addition to the standard PC disk partition scheme that uses amaster boot record (MBR), UEFI also works with theGUID 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 fourprimary partitions per disk, and up to 2 TB(2 × 240bytes) per disk) are relaxed.[41] More specifically, GPT allows for a maximum disk and partition size of 8 ZiB(8 × 270 bytes).[42][43]
Support for GPT inLinux is enabled by turning on the optionCONFIG_EFI_PARTITION (EFI GUID Partition Support) during kernel configuration.[44] 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 bothGRUB 2 and Linux are GPT-aware. Such a setup is usually referred to asBIOS-GPT.[45][unreliable source?] 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'sbootstrap code area.[43] In the case of GRUB, such a configuration requires aBIOS 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'sPrimary Header andPrimary Partition Table). Commonly 1 MB in size, this partition'sGlobally Unique Identifier (GUID) in GPT scheme is21686148-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.[19][43][45]
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 anEFI system partition (ESP), which contains UEFI applications such as bootloaders, operating system kernels, and utility software.[46][47][48][unreliable source?] Such a setup is usually referred to asUEFI-GPT, while ESP is recommended to be at least 512 MB in size and formatted with a FAT32 filesystem for maximum compatibility.[43][45][49][unreliable source?]
Forbackward compatibility, some UEFI implementations also support booting from MBR-partitioned disks through the Compatibility Support Module (CSM) that provides legacy BIOS compatibility.[50] In that case, booting Linux on UEFI systems is the same as on legacy BIOS-based systems.
Some of the EFI's practices and data formats mirror those ofMicrosoft Windows.[51][52]
The 64-bit versions ofWindows Vista SP1 and later and 64-bit versions ofWindows 8,8.1,10, and11 can boot from a GPT disk that is larger than 2 TB.
EFI defines two types of services:boot services andruntime services. Boot services are available only while the firmware owns the platform (i.e., before theExitBootServices() 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 andNVRAM access.
Beyond loading an OS, UEFI can runUEFI applications, which reside as files on theEFI system partition. They can be executed from the UEFI Shell, by the firmware'sboot manager, or by other UEFI applications.UEFI applications can be developed and installed independently of theoriginal equipment manufacturers (OEMs).
A type of UEFI application is an OS boot loader such asGRUB,rEFInd,Gummiboot, andWindows 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.
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 theBIOS interrupt calls.
In addition to standardinstruction set architecture-specific device drivers, EFI provides for a ISA-independentdevice driver stored innon-volatile memory asEFI byte code orEBC. System firmware has an interpreter for EBC images. In that sense, EBC is analogous toOpen Firmware, the ISA-independent firmware used inPowerPC-basedApple Macintosh andSun MicrosystemsSPARC 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 includeefifs for 37 file systems (based onGRUB2 code),[56] used byRufus for chain-loading NTFS ESPs.[57]
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 withGOP (Graphics Output Protocol).[58]
UEFI 2.1 defined a "Human Interface Infrastructure" (HII) to manage user input, localized strings, fonts, and forms (in theHTML sense). These enableoriginal equipment manufacturers (OEMs) orindependent BIOS vendors (IBVs) to design graphical interfaces for pre-boot configuration. UEFI usesUTF-16 to encode strings by default.
Most early UEFI firmware implementations were console-based. Today many UEFI firmware implementations are GUI-based.
An EFI system partition, often abbreviated to ESP, is adata 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 systemboot loaders. Supportedpartition table schemes includeMBR andGPT, as well asEl Torito volumes on optical discs.[37]: section 2.6.2 For use on ESPs, UEFI defines a specific version of theFAT file system, which is maintained as part of the UEFI specification and independently from the original FAT specification, encompassing theFAT32,FAT16 andFAT12 file systems.[37]: section 12.3 [59][60][61] The ESP also provides space for a boot sector as part of the backward BIOS compatibility.[50]
Unlike the legacy PC BIOS, UEFI does not rely onboot sectors, 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 OSboot loader oroperating system kernel (usually boot loader[62]). The boot configuration is defined by variables stored inNVRAM, 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 easybooting from removable devices such asUSB flash drives. This automated detection relies on standardized file paths to the OS boot loader, with the path varying depending on thecomputer 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 anx86-64 system is\efi\boot\bootx64.efi,[37] and\efi\boot\bootaa64.efi on ARM64 architecture.
Booting UEFI systems from GPT-partitioned disks is commonly calledUEFI-GPT booting. Despite the fact that the UEFI specification requires MBR partition tables to be fully supported,[37] some UEFI firmware implementations immediately switch to the BIOS-based CSM booting depending on the type of boot disk's partition table, effectively preventing UEFI booting to be performed fromEFI System Partition on MBR-partitioned disks.[50] Such a boot scheme is commonly calledUEFI-MBR.
It is also common for a boot manager to have a textual user interface so the user can select the desired OS (or setup utility) from a list of available boot options.
To ensure backward compatibility, UEFI firmware implementations on PC-class machines could support booting in legacy BIOS mode from MBR-partitioned disks through theCompatibility 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 aboot sector.[50]
BIOS-style booting from MBR-partitioned disks is commonly calledBIOS-MBR, regardless of it being performed on UEFI or legacy BIOS-based systems. Furthermore, booting legacy BIOS-based systems from GPT disks is also possible, and such a boot scheme is commonly calledBIOS-GPT.
TheCompatibility Support Module allows legacy operating systems and some legacyoption ROMs that do not support UEFI to still be used.[63] It also provides required legacySystem Management Mode (SMM) functionality, calledCompatibilitySmm, 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 classicPS/2 counterparts.[63]
In November 2017, Intel announced that it planned to phase out support CSM for client platforms by 2020.[64]
In July, of 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.[65]
In August 2023, Intel announced that it planned to phase out support CSM for server platforms by 2024.[66]
Currently[when?] most computers based on Intel platforms do not support CSM.[citation needed]
The UEFI specification includes support for booting over network via thePreboot eXecution Environment (PXE). PXE bootingnetwork protocols includeInternet Protocol (IPv4 andIPv6),User Datagram Protocol (UDP),Dynamic Host Configuration Protocol (DHCP),Trivial File Transfer Protocol (TFTP) andiSCSI.[37][67]
OS images can be remotely stored onstorage area networks (SANs), withInternet Small Computer System Interface (iSCSI) andFibre Channel over Ethernet (FCoE) as supported protocols for accessing the SANs.[37][68][69]
Version 2.5 of the UEFI specification adds support for accessing boot images overHTTP.[70]
The UEFI specification defines a protocol known asSecure Boot, which can secure the boot process by preventing the loading of UEFI drivers or OS boot loaders that are notsigned with an acceptabledigital signature. The mechanical details of how precisely these drivers are to be signed are not specified.[71] 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.[72] 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.[73]
Secure Boot is supported byWindows 8 and8.1,Windows Server 2012 and 2012 R2,Windows 10,Windows Server 2016,2019, and2022, andWindows 11, VMware vSphere 6.5[74] and a number ofLinux distributions includingFedora (since version 18),openSUSE (since version 12.3), RHEL (since version 7), CentOS (since version 7[75]), Debian (since version 10),[76]Ubuntu (since version 12.04.2),Linux Mint (since version 21.3).,[77][78] andAlmaLinux OS (since version 8.4[79]). As of January 2025[update],FreeBSD support is in a planning stage.[80]
It has been observed, though, that Secure Boot causes issues with software, such as theUnity Engine, running on Linux (particularly Fedora Linux) and with the system locking up requiring a hard reboot.[citation needed] This issue also persists over into playing video games viaSteam using Proton compatibility tools where games will crash repeatedly.[citation needed]
UEFI provides ashell environment, which can be used to execute other UEFI applications, including UEFIboot loaders.[48] 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).[81][unreliable source?][82][83]
Source code for a UEFI shell can be downloaded from theIntel'sTianoCore UDK/EDK2 project.[84] A pre-built ShellBinPkg is also available.[85] 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.[81][86][87]
Methods used for launching UEFI shell depend on the manufacturer and model of the systemmotherboard. 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<EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Some other systems have an already embedded UEFI shell which can be launched by appropriate key press combinations.[88][unreliable source?][89] 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.[83][88][90][unreliable source?][91][unreliable source?]
The following is a list ofcommands supported by the EFI shell.[82]
Extensions to UEFI can be loaded from virtually anynon-volatile storage device attached to the computer. For example, anoriginal equipment manufacturer (OEM) can distribute systems with anEFI system partition on the hard drive, which would add additional functions to the standard UEFI firmware stored on the motherboard'sROM.
UEFI Capsule defines a Firmware-to-OS firmware update interface, marketed as modern and secure.[92]Windows 8,Windows 8.1,Windows 10,[93] andFwupd for Linux each support the UEFI Capsule.
LikeBIOS, UEFI initializes and tests system hardware components (e.g. memory training, PCIe link training, USB link training on typical x86 systems), and then loads theboot loader from amass storage device or through anetwork connection. Inx86 systems, the UEFI firmware is usually stored in theNOR flash chip of the motherboard.[94][95] In some ARM-based Android and Windows Phone devices, the UEFI boot loader is stored in theeMMC oreUFS flash memory.
UEFI machines can have one of the following classes, which were used to help ease the transition to UEFI:[96]
Starting from the 10th Gen Intel Core, Intel no longer provides LegacyVideo 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.[citation needed]
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, CPUmicrocode). It consists of minimal code written inassembly language for the specific architecture. It initializes a temporary memory (often CPU cache-as-RAM (CAR), or SoC on-chip SRAM) and serves as the system's software root of trust with the option of verifying PEI before hand-off.
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 asmain memory initialization (initializememory controller andDRAM) 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.[98]
This stage has several components including PEI foundation, PEIMs and PPI. Due less resources available in this stage, this stage must be minimal and do minimal preparations for the next stage(DXE), Which is more richer.
After SEC phase hand off, platform responsibility is taken by PEI Foundation. it's responsibility is:
This component is responsible for invoking PEIMs and managing there dependencies.
Those are minimal PEI drivers that is responsible for initialization of the hardware like permanent memory, CPU, chipset and motherboard. Each PEIMs has single responsibility and focused on single initialization. Those drivers came from different vendors.
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).
This stage consist 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.[99]
BDS is a part of the DXE.[100][101] In this stage, boot devices are initialized, UEFI drivers orOption ROMs of PCI devices are executed according to architecturally defined variables calledNVRAM.
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.
The UEFI hands off to theoperating system (OS) afterExitBootServices() 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 andACPI.[102][failed verification] A typical modern OS will prefer to use its own programs (such askernel 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.
Intel's implementation of EFI is theIntel Platform Innovation Framework, codenamedTiano. Tiano runs on Intel'sXScale,Itanium,IA-32 andx86-64 processors, and is proprietary software, although a portion of the code has been released under theBSD license orEclipse Public License (EPL) asTianoCore EDK II. TianoCore can be used as a payload forcoreboot.[103]
Phoenix Technologies' implementation of UEFI is branded as SecureCore Technology (SCT).[104]American Megatrends offers its own UEFI firmware implementation known as Aptio,[105] whileInsyde Software offers InsydeH2O,[106] and Byosoft offers ByoCore.
In December 2018,Microsoft released an open source version of its TianoCore EDK2-based UEFI implementation from theSurface line,Project Mu.[107]
An implementation of the UEFI API was introduced into the Universal Boot Loader (Das U-Boot) in 2017.[108] On theARMv8 architectureLinux distributions use the U-Boot UEFI implementation in conjunction withGNU GRUB for booting (e.g.SUSE Linux[109]), the same holds true for OpenBSD.[110] For booting from iSCSIiPXE can be used as a UEFI application loaded by U-Boot.[111]
Intel's firstItanium workstations and servers, released in 2000, implemented EFI 1.02.
Hewlett-Packard's firstItanium 2 systems, released in 2002, implemented EFI 1.10; they were able to bootWindows,Linux,FreeBSD andHP-UX;OpenVMS added UEFI capability in June 2003.
In January 2006,Apple Inc. shipped its firstIntel-based Macintosh computers. These systems used EFI instead ofOpen Firmware, which had been used on its previous PowerPC-based systems.[112] On 5 April 2006, Apple first releasedBoot 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.[113]
During 2005, more than one million Intel systems shipped with Intel's implementation of UEFI.[114][failed verification] 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 asembedded systems based onXScale cores.[114]
The EDK (EFI Developer Kit) includes an NT32 target, which allows EFI firmware and EFI applications to run within aWindows application. But 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, HP EliteBook Notebook PCs.
In 2009, IBM shippedSystem x machines (x3550 M2, x3650 M2, iDataPlex dx360 M2) andBladeCenter 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.[115]
In 2011, major vendors (such asASRock,Asus,Gigabyte, andMSI) launched several consumer-oriented motherboards using the Intel6-seriesLGA 1155 chipset and AMD 9 SeriesAM3+ chipsets with UEFI.[116]
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 tosmartphones, 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.[117][118]
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.[119] By 2019, all computers based on Intel platforms no longer have legacy PC BIOS support.
An operating system that can be booted from a (U)EFI is called a (U)EFI-aware operating system, defined by (U)EFI specification. Here the termbooted 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 beIA32,X64,IA64,ARM orAA64.[37] Some operating systems vendors may have their own boot loaders. They may also change the default boot location.
EDK2 Application Development Kit (EADK) makes it possible to usestandard C library functions in UEFI applications. EADK can be freely downloaded from theIntel's TianoCore UDK / EDK2SourceForge project. As an example, a port of thePython interpreter is made available as a UEFI application by using the EADK.[158] The development has moved to GitHub since UDK2015.[159]
A minimalistic "hello, world" C program written using EADK looks similar to itsusual C counterpart:
#include<Uefi.h>#include<Library/UefiLib.h>#include<Library/ShellCEntryLib.h>EFI_STATUSEFIAPIShellAppMain(INUINTNArgc,INCHAR16**Argv){Print(L"hello, world\n");returnEFI_SUCCESS;}
Numerous digital rights activists have protested UEFI.Ronald G. Minnich, a co-author ofcoreboot, andCory Doctorow, a digital rights activist, have criticized UEFI as an attempt to remove the ability of the user to truly control the computer.[160][161] It does not solve the BIOS's long-standing problems of requiring two different drivers—one for the firmware and one for the operating system—for most hardware.[162]
Open-source project TianoCore also provides UEFIs.[163] TianoCore lacks the specialized firmware drivers and modules that initialize chipset functions, but TianoCore is one of many payload options ofcoreboot. The development of coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.
In 2011, Microsoft announced that computers certified to run itsWindows 8 operating system had to ship with Microsoft's public key enrolled and Secure Boot enabled, which implies that using UEFI is a requirement for these devices.[164][165] Following the announcement, the company was accused by critics and free software/open source advocates (including theFree Software Foundation) of trying to use the Secure Boot functionality of UEFI tohinder or outright prevent the installation of alternative operating systems such asLinux. Microsoft denied that the Secure Boot requirement was intended to serve as a form oflock-in, and clarified its requirements by stating that x86-based systems certified for Windows 8 must allow Secure Boot to enter custom mode or be disabled, but not on systems using theARM architecture.[73][166]Windows 10 allowsOEMs to decide whether or not Secure Boot can be managed by users of their x86 systems.[167]
Other developers raised concerns about the legal and practical issues of implementing support for Secure Boot on Linux systems in general. FormerRed Hat developerMatthew Garrett noted that conditions in theGNU General Public License version 3 may prevent the use of theGNU GRand Unified Bootloader without a distribution's developer disclosing the private key (however, theFree Software Foundation has since clarified its position, assuring that the responsibility to make keys available was held by the hardware manufacturer),[168][122] and that it would also be difficult for advanced users to build customkernels that could function with Secure Boot enabled without self-signing them.[166] Other developers suggested that signed builds of Linux with another key could be provided, but noted that it would be difficult to persuade OEMs to ship their computers with the required key alongside the Microsoft key.[6]
Several major Linux distributions have developed different implementations for Secure Boot. Garrett himself developed a minimal bootloader known as a shim, which is a precompiled, signed bootloader that allows the user to individually trust keys provided by Linux distributions.[169]Ubuntu 12.10 uses an older version of shim[which?] pre-configured for use withCanonical's own key that verifies only the bootloader and allows unsigned kernels to be loaded; developers believed that the practice of signing only the bootloader is more feasible, since a trusted kernel is effective at securing only theuser space, and not the pre-boot state for which Secure Boot is designed to add protection. That also allows users to build their own kernels and use customkernel modules as well, without the need to reconfigure the system.[122][170][171] Canonical also maintains its own private key to sign installations of Ubuntu pre-loaded on certified OEM computers that run the operating system, and also plans to enforce a Secure Boot requirement as well—requiring both a Canonical key and a Microsoft key (for compatibility reasons) to be included in their firmware.Fedora also uses shim,[which?] but requires that both the kernel and its modules be signed as well.[170] shim has Machine Owner Key (MOK) that can be used to sign locally-compiled kernels and other software not signed by distribution maintainer.[172]
It has been disputed whether the operating system kernel and its modules must be signed as well; while the UEFI specifications do not require it, Microsoft has asserted that their contractual requirements do, and that it reserves the right to revoke any certificates used to sign code that can be used to compromise the security of the system.[171] In Windows, if Secure Boot is enabled, all kernel drivers must be digitally signed; non-WHQL drivers may be refused to load. In February 2013, another Red Hat developer attempted to submit a patch to the Linux kernel that would allow it to parse Microsoft's authenticode signing using a masterX.509 key embedded inPE files signed by Microsoft. However, the proposal was criticized by Linux creatorLinus Torvalds, who attacked Red Hat for supporting Microsoft's control over the Secure Boot infrastructure.[173]
On 26 March 2013, theSpanish free software development group Hispalinux filed a formal complaint with theEuropean Commission, contending that Microsoft's Secure Boot requirements on OEM systems were "obstructive" andanti-competitive.[174]
At theBlack Hat conference in August 2013, a group of security researchers presented a series of exploits in specific vendor implementations of UEFI that could be used to exploit Secure Boot.[175]
In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems.[176] Technically, no key was exposed, however, an exploitable binary signed by the key was. This allows any software to run as though it was genuinely signed by Microsoft and exposes the possibility ofrootkit andbootkit attacks. This also makes patching the fault impossible, since any patch can be replaced (downgraded) by the (signed) exploitable binary. Microsoft responded in a statement that the vulnerability only exists inARM architecture andWindows RT devices, and has released two patches; however, the patches do not (and cannot) remove the vulnerability, which would require key replacements in end user firmware to fix.[citation needed]
On March 1, 2023, researchers from ESET Cybersecurity Firm reported “The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot” named ‘BlackLotus’ in their public analyses findings describing the theory behind its mechanics exploiting the patches that “do not (and cannot) remove the vulnerability”.[177][178]
In August 2024, theWindows 11 andWindows 10 security updates applied the Secure Boot Advanced Targeting (SBAT) settings to device's UEFI NVRAM, which caused some Linux distributions to fail to load. SBAT is a protocol that supported in new versions ofWindows Boot Manager and shim, which refuse buggy or vulnerable intermediate bootloaders (usually older versions of Windows Boot Manager andGRUB) to load in the boot process. The change was reverted the next month.[179]
ManyLinux distributions support UEFI Secure Boot as of January 2025[update], such asRHEL (RHEL 7 and later),CentOS (CentOS 7 and later[180]),Ubuntu,Fedora,Debian (Debian 10 and later[181]),OpenSUSE, andSUSE Linux Enterprise.[182]
The increased prominence of UEFI firmware in devices has also led to a number of technical problems blamed on their respective implementations.[183]
Following the release of Windows 8 in late 2012, it was discovered that certainLenovo computer models with Secure Boot had firmware that was hardcoded to allow only executables named "Windows Boot Manager" or "Red Hat Enterprise Linux" to load, regardless of any other setting.[184] Other problems were encountered by severalToshiba laptop models with Secure Boot that were missing certain certificates required for its proper operation.[183]
In January 2013, a bug surrounding the UEFI implementation on someSamsung laptops was publicized, which caused them to bebricked after installing a Linux distribution in UEFI mode. While potential conflicts with a kernel module designed to access system features on Samsung laptops were initially blamed (also prompting kernel maintainers to disable the module on UEFI systems as a safety measure), Matthew Garrett discovered that the bug was actually triggered by storing too many UEFI variables to memory, and that the bug could also be triggered under Windows under certain conditions. In conclusion, he determined that the offending kernel module had caused kernel message dumps to be written to the firmware, thus triggering the bug.[54][185][186]
Q: What is the relationship between EFI and UEFI? A: The UEFI specification is based on the EFI 1.10 specification published by Intel with corrections and changes managed by the Unified EFI Forum. Intel still holds the copyright on the EFI 1.10 specification, but has contributed it to the Forum so that the Forum can evolve it. There will be no future versions of the EFI specification, but customers who license it can still use it under the terms of their license from Intel. The license to the Unified EFI Specification comes from the Forum, not from Intel
{{cite report}}: CS1 maint: url-status (link)The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby ... Platforms shall be UEFI Class Three (see UEFI Industry Group, Evaluating UEFI using Commercially Available Platforms and Solutions, version 0.3, for a definition) with no Compatibility Support Module installed or installable. BIOS emulation and legacy PC/AT boot must be disabled.
Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware because of the current status of mainstream 64-bit computing and platform costs. Therefore, Microsoft originally did not to ship support for 32-bit UEFI implementations.
| Processes | | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||