View source for UEFI

{{Short description|Technical specification for firmware architecture}}
{{Use dmy dates|date=February 2020}}
{{Infobox technology standard
| title             = Unified Extensible Firmware Interface
| long_name         = 
| image             = Logo of the UEFI Forum.svg
| image_size        = 100px
| alt               = 
| caption           = 
| abbreviation      = UEFI
| status            = Published
| year_started      = 2006{{efn|Originally started in 1998 as Intel Boot Initiative and later as Extensible Firmware Interface (EFI), which was deprecated in 2005 and replaced by UEFI.}}
| first_published   = <!-- {{Start date|YYYY|MM|DD|df=y}} -->
| version           = 2.11<ref>{{cite web |title=UEFI Forum Releases the UEFI 2.11 Specification and the PI 1.9 Specification To Streamline User Implementations {{!}} Unified Extensible Firmware Interface Forum |url=https://uefi.org/press-release/uefi-forum-releases-uefi-211-specification-and-pi-19-specification-streamline-user |website=uefi.org |publisher=UEFI Forum |access-date=22 December 2024}}</ref>
| version_date      = December 16, 2024
| preview           = 
| preview_date      = 
| organization      = [[UEFI Forum]]
| committee         = 
| series            = 
| editors           = 
| authors           = 
| base_standards    = 
| related_standards = {{plain list|
* [[ACPI]]
* [[UEFI Platform Initialization]]
}}
| predecessor       = [[BIOS]] on [[IBM PC compatible]] computers{{efn|Part of the BIOS that is required for booting an operating system that is not UEFI-compatible can be implemented as a CSM DXE module, see {{section link||CSM booting}}}} 
| domain            = [[Firmware]]
| license           = 
| copyright         = 
| website           = {{URL|https://uefi.org/}}
}}
[[File:Lenovo ThinkPad T470 UEFI BIOS 1.75 setup - boot menu selection.JPG|thumb|right|Boot order selection menu on a [[ThinkPad T470|Lenovo ThinkPad T470]] with both UEFI and [[BIOS]] support.]]
[[File:WD Blue WD5000LPVX - controller - Winbond 25X20CLVIG-0182.jpg|thumb|right|The UEFI implementation is usually stored on [[NOR flash|NOR]]-based [[flash memory]]<ref>{{cite web | url=https://www.winbond.com/hq/support/documentation/?__locale=en&line=/product/code-storage-flash-memory/index.html&family=/product/code-storage-flash-memory/serial-nor-flash/index.html&pno=W25X20CL&category=/.categories/resources/datasheet/ | title=Documentation - Winbond }}</ref><ref>{{cite web | url=https://www.ifixit.com/Guide/Microsoft+Surface+Laptop+7+(13.8-inch)+Chip+ID/173921 | title=Microsoft Surface Laptop 7 (13.8-inch) Chip ID | date=22 June 2024 }}</ref><ref>{{cite book | url=https://books.google.com/books?id=wylDDgAAQBAJ | title=Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition | isbn=978-1-5015-0569-0 | last1=Zimmer | first1=Vincent | last2=Rothman | first2=Michael | last3=Marisetty | first3=Suresh | date=2017 | publisher=Walter de Gruyter GmbH & Co KG }}</ref> located on the [[motherboard]]. Various I/O protocols can be used, [[Serial Peripheral Interface|SPI]] being the most common.]]

'''Unified Extensible Firmware Interface''' ('''UEFI''', {{IPAc-en|'|juː|ᵻ|f|aɪ}} as an acronym){{efn|Historically also written as Unified EFI, when UEFI was the newly introduced successor to EFI.}} is a [[Specification (technical standard)|specification]] for the firmware [[Software architecture|architecture]] of a [[computing platform]]. When a computer [[booting|is powered on]], the UEFI-implementation is typically the first that runs, before starting the [[operating system]]. Examples include [[AMI Aptio]], [[Phoenix Technologies|Phoenix SecureCore]], [[TianoCore EDK II]], [[InsydeH2O]]. 

UEFI replaces the [[BIOS]] that was present in the [[boot ROM]] of all [[personal computers]] that are [[IBM PC compatible]],<ref name="Intel2000">{{cite web |url=http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |title=Solving BIOS Boot Issues with EFI |first=Michael |last=Kinney |date=1 September 2000 |access-date=14 September 2010 |pages=47–50 |archive-date=23 January 2007 |archive-url=https://web.archive.org/web/20070123141151/http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |url-status=dead }}</ref><ref name="ElReg1" /> although it can provide [[Backward compatibility|backwards compatibility]] with the BIOS using [[#CSM booting|CSM booting]]. Unlike its predecessor, BIOS, which is a [[de facto]] standard originally created by [[IBM]] as proprietary software, UEFI is an open standard maintained by an industry [[consortium]]. Like BIOS, most UEFI implementations are proprietary.

[[Intel]] developed the original ''Extensible Firmware Interface'' (''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 (programming language)|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]], 1&nbsp;MB addressable memory space,<ref>{{Cite web|title=Memory Map (x86) - OSDev Wiki|url=https://wiki.osdev.org/Memory_Map_(x86)|access-date=2020-12-11|website=wiki.osdev.org}}</ref> [[assembly language]] programming, and [[PC AT]] hardware) had become too restrictive for the larger server platforms Itanium was targeting.<ref name = "EmulexUEFI" /> The effort to address these concerns began in 1998 and was initially called ''Intel Boot Initiative''.<ref>{{citation | url = http://www.intel.com/technology/efi/ | archive-url = https://web.archive.org/web/20100105051711/http://www.intel.com/technology/efi/ | archive-date = 5 January 2010 | title = Extensible Firmware Interface (EFI) and Unified EFI (UEFI) | publisher = Intel}}</ref> It was later renamed to ''Extensible Firmware Interface'' (EFI).<ref>{{citation | first = Dong | last = Wei | title = Beyond BIOS | chapter = foreword | publisher = Intel Press | year = 2006 | isbn = 978-0-9743649-0-2}}</ref><ref>{{citation | chapter-url = http://www.intel.com/technology/efi/main_specification.htm | title = Extensible Firmware Interface | chapter = 1.10 Specification overview | publisher = Intel}}</ref>

The first [[open source]] UEFI implementation, Tiano, was released by Intel in 2004. Tiano has since then been superseded by EDK<ref>{{Cite web | url=https://github.com/tianocore/edk |title =GitHub - tianocore/Edk: Git mirror of EDK.|website =[[GitHub]]|date = 19 March 2019}}</ref> and EDK II<ref>{{Cite web | url=https://github.com/tianocore/tianocore.github.io/wiki/EDK-II | title=GitHub - tianocore/Tianocore.github.io: Tianocore website.| website=[[GitHub]]| date=8 August 2019}}</ref> and is now maintained by the TianoCore community.<ref>{{Cite web | url=https://www.tianocore.org/ |title = What is TianoCore?}}</ref>

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.<ref name = "EmulexUEFI">{{cite news | url = http://www.emulex.com/artifacts/757d23e7-8acb-41a7-872a-afb733ab0688/elx_tb_all_uefi_ibm.pdf |title=Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems |publisher=Emulex | access-date =14 September 2010}}</ref><ref>{{citation | url = http://www.uefi.org/about/ | publisher = Unified EFI Forum | title = About | quote = 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}}</ref>

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

In October 2018, Arm announced [https://developer.arm.com/architectures/platform-design/server-systems Arm ServerReady], a compliance certification program for landing the generic off-the-shelf operating systems and [[hypervisor]]s on Arm-based servers. The program requires the system firmware to comply with Server Base Boot Requirements (SBBR). SBBR requires UEFI, [[Advanced Configuration and Power Interface|ACPI]] and [[System Management BIOS|SMBIOS]] compliance. In October 2020, Arm announced the extension of the program to the [[Edge computing|edge]] and [[Internet of things|IoT]] market. The new program name is [https://developer.arm.com/architectures/system-architectures/arm-systemready Arm SystemReady]. Arm SystemReady defined the Base Boot Requirements ([https://developer.arm.com/documentation/den0044/latest 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 ([https://github.com/ARM-software/ebbr 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 in [[Microsoft Surface]] and [[Hyper-V]] products. The project promotes the idea of [[firmware as a service]].<ref>{{cite web|url= https://betanews.com/2018/12/20/microsoft-project-mu/|title= Microsoft announces Project Mu, an open-source release of the UEFI core|date= 20 December 2018}}</ref>

The latest UEFI specification, version 2.11, was published in December 2024.<ref name="UEFISpec2.11">{{cite web |url=https://uefi.org/sites/default/files/resources/UEFI_Spec_Final_2.11.pdf |title=Unified Extensible Firmware Interface (UEFI) Specification Version 2.11 |website=www.uefi.org |date=December 2024 |access-date=22 Dec 2024}}</ref>

== 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 BIOS:<ref name="UEFI2009Microsoft">{{cite web |url=http://www.microsoft.com/whdc/system/platform/firmware/UEFI_Windows.mspx |title=UEFI and Windows |publisher=Microsoft |date=15 September 2009 |access-date=14 September 2010 }}</ref>

* Ability to boot a disk containing large partitions (over 2&nbsp;[[terabyte|TB]]) with a [[GUID Partition Table]] (GPT)<ref name="grub-bios-installation">{{cite web
 | url = https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html
 | title = Installation
 | work = 3.4 BIOS installation
 | access-date = 25 September 2013
 | publisher = [[GNU GRUB]]
}}</ref>{{Efn|name="note1"|Large disk support and features such as [[Advanced Configuration and Power Interface]] (ACPI) and [[SMBIOS|System Management BIOS]] (SMBIOS) were subsequently implemented in BIOS-based systems.}}<ref name="Non-boot GPT disk">{{cite web |url=https://superuser.com/a/1245320/1291014 |title=Non-boot disks can use a GPT partition table even with no UEFI bios}}</ref>
* 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 (programming language)|C language]] programming
* Python programming using [https://github.com/tianocore/edk2-libc/blob/master/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt Python interpreter for UEFI] shell
* Modular design
* Backward and forward compatibility

With UEFI, it is possible to store product keys for operating systems such as Windows, on the UEFI firmware of the device.<ref>{{cite web | url=https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/oa3-using-on-factory-floor?view=windows-11 | title=Using the OA 3.0 Tool on the factory floor | date=25 October 2021 }}</ref><ref>{{cite web | url=https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/oa3-command-line-config-file-syntax?view=windows-11 | title=OA 3.0 Tool: Command-line and config file syntax | date=29 July 2021 }}</ref><ref>{{Cite report |url=https://h10032.www1.hp.com/ctg/Manual/c03857419.pdf |title=UEFI pre-boot guidelines and Microsoft® Windows® 8 UEFI Secure Boot for HP Business PCs |url-status=live}}</ref> UEFI is required for [[Secure Boot]] on devices shipping with Windows 8<ref>{{cite web | url=https://www.networkworld.com/article/738394/microsoft-subnet-next-gen-boot-spec-could-forever-lock-linux-off-windows-8-pcs.html | title=Next-gen boot spec could forever lock Linux off Windows 8 PCS }}</ref><ref>{{cite web | url=https://arstechnica.com/information-technology/2011/09/windows-8-secure-boot-will-complicate-linux-installs/ | title=Windows 8 secure boot could complicate Linux installs | date=21 September 2011 }}</ref> and above.

It is also possible for operating systems to access UEFI configuration data.<ref>{{cite book | url=https://books.google.com/books?id=wylDDgAAQBAJ | title=Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition | isbn=978-1-5015-0569-0 | last1=Zimmer | first1=Vincent | last2=Rothman | first2=Michael | last3=Marisetty | first3=Suresh | date=2017 | publisher=Walter de Gruyter GmbH & Co KG }}</ref>

== Compatibility ==

=== {{Anchor|HANDOVER|BOOT-STUB}}Processor compatibility ===
As of version 2.5, processor bindings exist for Itanium, x86, x86-64, [[ARM architecture family|ARM]] (AArch32) and [[ARM64]] (AArch64).<ref>UEFI Specification 2.4, section 2.3</ref> Only [[endianness|little-endian]] processors can be supported.<ref>UEFI specification 2.3.1, section 1.8.1.</ref> Unofficial UEFI support is under development for POWERPC64 by implementing [[#Intel EFI|TianoCore]]{{Broken anchor|date=2025-04-15|bot=User:Cewbot/log/20201008/configuration|target_link=#Intel EFI|reason= The anchor (Intel EFI) [[Special:Diff/1115112177|has been deleted]].|diff_id=1115112177}} on top of OPAL,<ref>{{cite web|url=https://github.com/andreiw/ppc64le-edk2|title=GitHub - andreiw/ppc64le-edk2: TianoCore UEFI for OPAL/PowerNV (PPC64/PowerPC64 Little-Endian)|work=GitHub|date=3 May 2021}}</ref> the OpenPOWER abstraction layer, running in little-endian mode.<ref>{{cite web|url=http://firmwaresecurity.com/2015/10/12/tianocore-for-openpower/comment-page-1/|title=Tianocore for OpenPOWER|work=Firmware Security|date=12 October 2015}}</ref> Similar projects exist for [[MIPS architecture|MIPS]]<ref>{{cite web|url=http://sourceforge.net/projects/efi-mips/|title=EFI-MIPS|author=kontais|work=SourceForge|date=3 September 2015 }}</ref> and [[RISC-V]].<ref>{{cite web|url=http://www.lowrisc.org/|title=lowRISC · lowRISC}}</ref> As of UEFI 2.7, RISC-V processor bindings have been officially established for 32-, 64- and 128-bit modes.<ref>{{cite web|title=Unified Extensible Firmware Interface Specification, Version 2.7|date=May 2017|url=http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf}}</ref>

Standard PC BIOS is limited to a 16-bit processor mode and 1&nbsp;MB of addressable memory space, resulting from the design based on the [[IBM Personal Computer|IBM 5150]] that used a 16-bit [[Intel 8088]] processor.<ref name="EmulexUEFI"/><ref name="BitTechUEFI">{{cite news | url = http://www.bit-tech.net/hardware/storage/2010/06/01/are-we-ready-for-3tb-hard-disks/2 |title=LBA explained — Solving the 3TB Problem? |publisher=bit-tech |first=Ben |last=Hardwidge |date = 1 June 2010 | access-date =18 June 2010}}</ref> 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).<ref name="EmulexUEFI" /><ref name="AskBIOSGuyWhyUEFI">{{cite news |url=http://community.edc.intel.com/t5/New-to-Intel-Architecture-Blog/Ask-a-BIOS-Guy-quot-Why-UEFI-quot/ba-p/2781 |title=Ask a BIOS Guy: "Why UEFI" |publisher=Intel Architecture Blog |first=Brian |last=Richardson |date=10 May 2010 |access-date=18 June 2010 |url-status=dead |archive-url=https://web.archive.org/web/20101009214219/http://community.edc.intel.com/t5/New-to-Intel-Architecture-Blog/Ask-a-BIOS-Guy-quot-Why-UEFI-quot/ba-p/2781 |archive-date=9 October 2010  }}</ref> 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.<ref name="WinHec2008UEFI">{{cite news |url=http://download.microsoft.com/download/5/e/6/5e66b27b-988b-4f50-af3a-c2ff1e62180f/cor-t605_wh08.pptx |archive-url=https://web.archive.org/web/20140104004546/http://download.microsoft.com/download/5/e/6/5e66b27b-988b-4f50-af3a-c2ff1e62180f/cor-t605_wh08.pptx |format = PPTX |title = UEFI Momentum — The AMD perspective |archive-date=4 January 2014 |publisher=AMD |first=Gary |last=Simpson |access-date=20 September 2014}}</ref>

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).<ref name="uefi-spec-24" />{{rp|sections 2.3.2 and 2.3.4}} As of version 3.15, the [[Linux kernel]] supports 64-bit kernels to be [[Booting|booted]] on 32-bit UEFI firmware implementations running on [[x86-64]] CPUs, with ''UEFI handover'' support from a UEFI boot loader as the requirement.<ref>{{cite web
 | url = http://kernelnewbies.org/Linux_3.15#head-e6cf8178e4d5eafc23b0abda81974d2b71ffecf4
 | title = Linux kernel 3.15, Section 1.3. EFI 64-bit kernels can be booted from 32-bit firmware
 | date = 8 June 2014 | access-date = 15 June 2014
 | website = kernelnewbies.org
}}</ref> UEFI handover protocol [[Data deduplication|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''.<ref>{{cite web
 | url = https://lwn.net/Articles/507827/
 | title = x86, efi: Handover Protocol
 | date = 19 July 2012 | access-date = 15 June 2014
 | publisher = [[LWN.net]]
}}</ref><ref>{{cite web
 | url = https://www.kernel.org/doc/Documentation/efi-stub.txt
 | title = Linux kernel documentation: Documentation/efi-stub.txt
 | date = 1 February 2014 | access-date = 15 June 2014
 | publisher = [[kernel.org]]
}}</ref>

=== {{Anchor|DISKDEVCOMPAT}}Disk device compatibility ===
{{See also|GUID Partition Table#OSSUPPORT|Protective MBR|l1=GPT § Operating systems support}}

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 partition]]s per disk, and up to 2&nbsp;[[Terabyte|TB]] {{nowrap|(2 × 2<sup>40</sup> [[byte]]s)}} per disk) are relaxed.<ref name="UEFI_Drive_Partition_Limits_Fact_Sheet">{{cite news
 | url = http://www.uefi.org/sites/default/files/resources/UEFI_Drive_Partition_Limits_Fact_Sheet.pdf
 | title = FAQ: Drive Partition Limits
 | publisher = UEFI Forum
 | access-date =5 December 2019
}}</ref> More specifically, GPT allows for a maximum disk and partition size of 8&nbsp;[[Zebibyte|ZiB]] {{nowrap|(8 × 2<sup>70</sup> bytes)}}.<ref name="UEFIDrivePartitionFAQ">{{cite news
 | url = http://www.uefi.org/learning_center/UEFI_MBR_Limits_v2.pdf
 | title = FAQ: Drive Partition Limits
 | publisher = UEFI Forum
 | access-date = 9 June 2010
 | archive-date = 22 March 2013
 | archive-url = https://web.archive.org/web/20130322172831/http://www.uefi.org/learning_center/UEFI_MBR_Limits_v2.pdf
 | url-status = dead
 }}</ref><ref name=IBMLargeDrivesGPT>{{cite web
 | url = http://www.ibm.com/developerworks/library/l-gpt/index.html
 | title = Make the most of large drives with GPT and Linux
 | first = Roderick W.
 | last = Smith
 | publisher = [[IBM]]
 | date = 3 July 2012
 | access-date = 25 September 2013}}</ref>

==== Linux ====
{{See also|EFI System partition#Linux}}
Support for GPT in [[Linux]] is enabled by turning on the option <code>CONFIG_EFI_PARTITION</code> (EFI GUID Partition Support) during kernel configuration.<ref>{{cite web
 | url = https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/block/partitions/Kconfig?id=refs/tags/v3.11.1#n247
 | title = block/partitions/Kconfig (3.11.1)
 | work = CONFIG_EFI_PARTITION (line #247)
 | publisher = kernel.org
 | access-date = 25 September 2013
}}</ref> 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''.<ref name="arch-grub">{{cite web
 | url = https://wiki.archlinux.org/index.php/GRUB#BIOS_systems
 | title = GRUB
 | work = BIOS systems
 | publisher = [[Arch Linux]]
 | access-date = 25 September 2013
}}</ref>{{unreliable source?|date=September 2013}} 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 [[Master boot record#Sector layout|bootstrap code area]].<ref name="IBMLargeDrivesGPT" /> 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&nbsp;[[megabyte|MB]] in size, this partition's [[Globally Unique Identifier]] (GUID) in GPT scheme is {{Mono|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.<ref name="grub-bios-installation"/><ref name="IBMLargeDrivesGPT" /><ref name="arch-grub" />

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.<ref>{{cite web
 | url = https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s2-grub-whatis-booting-uefi.html
 | title = GRUB and the boot process on UEFI-based x86 systems
 | access-date = 14 November 2013
 | website = redhat.com
}}</ref><ref>{{cite web
 | url = http://blog.fpmurphy.com/2010/09/uefi-booting-64-bit-redhat-enterprise-linux-6.html
 | title = UEFI Booting 64-bit Redhat Enterprise Linux 6
 | date = September 2010 | access-date = 14 November 2013
 | website = fpmurphy.com
}}</ref><ref name="arch-uefi-loaders">{{cite web
 | url = https://wiki.archlinux.org/index.php/UEFI_Bootloaders
 | title = UEFI Bootloaders
 | access-date = 25 September 2013
 | website = archlinux.org
}}</ref>{{unreliable source?|date=September 2013}} Such a setup is usually referred to as ''UEFI-GPT'', while ESP is recommended to be at least 512&nbsp;MB in size and formatted with a FAT32 filesystem for maximum compatibility.<ref name="IBMLargeDrivesGPT" /><ref name="arch-grub" /><ref name="arch-uefi">{{cite web
 | url = https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#EFI_System_Partition
 | title = Unified Extensible Firmware Interface: EFI System Partition
 | access-date = 25 September 2013
 | website = archlinux.org
}}</ref>{{unreliable source?|date=September 2013}}

For [[backward compatibility]], some UEFI implementations also support booting from MBR-partitioned disks through the Compatibility Support Module (CSM) that provides legacy BIOS compatibility.<ref name="arch-forum-uefi-mbr">{{cite web
 | url = https://bbs.archlinux.org/viewtopic.php?id=142637
 | title = UEFI system booting from MBR partition table and GRUB legacy
 | date = June 2012 | access-date = 6 October 2013
 | publisher = Arch Linux Forums
|url-status=live
|archive-url=https://web.archive.org/web/20231208223031/https://bbs.archlinux.org/viewtopic.php?id=142637
|archive-date=2023-12-08
}}</ref> In that case, booting Linux on UEFI systems is the same as on legacy BIOS-based systems.

==== Microsoft Windows ====

Some of the EFI's practices and data formats mirror those of [[Microsoft Windows]].<ref>[https://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html IBM PC Real Time Clock should run in UT]. Cl.cam.ac.uk. Retrieved on 30 October 2013.</ref><ref name="Matthew Garrett">{{cite web |url=https://www.youtube.com/watch?v=V2aq5M3Q76U#t=14m45s | archive-url=https://ghostarchive.org/varchive/youtube/20211113/V2aq5M3Q76U| archive-date=2021-11-13 | url-status=live|title=EFI and Linux: The Future Is Here, and It's Awful |first=Matthew |last=Garrett |date=19 January 2012 |work=[[linux.conf.au]] 2012 |access-date=2 April 2012}}{{cbignore}}</ref> 

The 64-bit versions of [[Windows Vista]] SP1 and later and 64-bit versions of [[Windows 8]], [[Windows 8.1|8.1]], [[Windows 10|10]], and [[Windows 11|11]] can boot from a GPT disk that is larger than 2&nbsp;[[Terabyte|TB]].

== Features ==

=== {{Anchor|GOP|MM|VARIABLE|TIME}}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 <code>ExitBootServices()</code> 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 [[Non-volatile random-access memory|NVRAM]] access.

; Graphics Output Protocol (GOP) services
: The ''Graphics Output Protocol'' (GOP) provides runtime services; see also [[#Graphics features|Graphics features]] section below. The operating system is permitted to directly write to the framebuffer provided by GOP during runtime mode.<ref>{{Cite web|title=What is efifb? — The Linux Kernel documentation|url=https://www.kernel.org/doc/html/latest/fb/efifb.html|access-date=2020-11-24|website=www.kernel.org}}</ref>
; UEFI [[Memory map]] services
; [[System Management Mode|SMM]] services
; [[ACPI]] services
; [[System Management BIOS|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.<ref name=theh-brickwindows/>
; 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.<ref>UEFI specification, section 7.3</ref> 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,<ref name="Matthew Garrett"/> unless using recent versions and an entry in the [[Windows registry]] is set to indicate the use of UTC.

=== {{Anchor|APPLICATIONS}}Applications ===
[[File:Efi flowchart extended.svg|thumb|upright=1.9|Interaction between the EFI boot manager and EFI drivers]]

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|boot manager]], or by other UEFI applications. ''UEFI applications'' can be developed and installed independently of the [[original equipment manufacturer]]s (OEMs).

A type of UEFI application is an OS boot loader such as [[GRUB]], [[rEFInd]], [[Gummiboot (software)|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]].

=== {{Anchor|EBC}}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),<ref>{{cite web |title=Free Software EFI Drivers |url=https://efi.akeo.ie/}}</ref> used by [[Rufus (software)|Rufus]] for chain-loading NTFS ESPs.<ref>{{cite web |last1=Batard |first1=Pete |title=pbatard/uefi-ntfs |url=https://github.com/pbatard/uefi-ntfs |website=GitHub |date=13 March 2020}}</ref>

=== 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 [[Graphics Output Protocol|GOP (Graphics Output Protocol)]].<ref>{{cite web
 | url = http://www.intel.com/content/www/us/en/intelligent-systems/intel-embedded-graphics-drivers/faq-bios-firmware.html
 | title = Intel Embedded Graphics Drivers FAQ: BIOS and firmware
 | access-date = 19 May 2014
 | publisher = [[Intel]]
}}</ref>

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 manufacturer]]s (OEMs) or [[independent BIOS vendor]]s (IBVs) to design graphical interfaces for pre-boot configuration. UEFI uses [[UTF-16]] to encode strings by default.

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

=== EFI system partition ===
{{Main|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 loader]]s. Supported [[partition table]] schemes include [[Master boot record|MBR]] and [[GUID Partition Table|GPT]], as well as [[El Torito (CD-ROM standard)|El Torito]] volumes on optical discs.<ref name="uefi-spec-24">{{cite web
 | url = http://www.uefi.org/specifications
 | title = UEFI Specifications (version 2.4 and older)
 | format = PDF | publisher = Unified EFI, Inc.
 | date = June 2013 | access-date = 25 September 2013
}}</ref>{{rp|section 2.6.2}} 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.<ref name="uefi-spec-24" />{{rp|section 12.3}}<ref name="uefi-spec-2.5">{{cite web
 | url = http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf#page=536
 | title = UEFI Specification Version 2.5, Section 12.3 File System Format
 | date = April 2015 | access-date = 29 May 2015
 | website = uefi.org
 | format = PDF | pages = 536, 537
 | quote = 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.
}}</ref><ref>{{cite web
 | url = https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION6
 | title = Technical Note TN2166: Secrets of the GPT
 | date = 6 November 2006 | access-date = 6 May 2015
 | website = developer.apple.com
}}</ref><ref>{{Cite web|title=UEFI - OSDev Wiki|url=https://wiki.osdev.org/UEFI|access-date=2020-09-26|website=wiki.osdev.org}}</ref> The ESP also provides space for a boot sector as part of the backward BIOS compatibility.<ref name="arch-forum-uefi-mbr" />

=== Booting ===

==== {{Anchor|UEFIBOOT|BOOT-MANAGER}}UEFI booting ====
Unlike the legacy PC BIOS, UEFI does not rely on [[boot sector]]s, 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]] (usually boot loader<ref>{{Cite web|title=EFISTUB - ArchWiki|url=https://wiki.archlinux.org/index.php/EFISTUB|access-date=2020-10-27|website=wiki.archlinux.org}}</ref>). The boot configuration is defined by variables stored in [[NVRAM]], 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 drive]]s. 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 {{Mono|<nowiki><EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI</nowiki>}}; for example, the file path to the OS loader on an [[x86-64]] system is {{Mono|\efi\boot\bootx64.efi}},<ref name="uefi-spec-24" /> and {{Mono|\efi\boot\bootaa64.efi}} on ARM64 architecture.
[[File:UEFI boot process.png|thumb|541x541px|Boot process]]
Booting UEFI systems from GPT-partitioned disks is commonly called ''UEFI-GPT booting''. Despite the fact that the UEFI specification requires MBR partition tables to be fully supported,<ref name="uefi-spec-24" /> 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 from [[EFI System Partition]] on MBR-partitioned disks.<ref name="arch-forum-uefi-mbr" /> Such a boot scheme is commonly called ''UEFI-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.

On PC platforms, the BIOS firmware that supports UEFI boot can be called ''UEFI BIOS'', although it may not support CSM boot method, as modern x86 PCs deprecated use of CSM.

==== {{Anchor|CSMBOOT}}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]].<ref name="arch-forum-uefi-mbr" />

BIOS-style booting from MBR-partitioned disks is commonly called ''BIOS-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 called ''BIOS-GPT''.

The ''Compatibility Support Module'' allows legacy operating systems and some legacy [[option ROM]]s that do not support UEFI to still be used.<ref name="intel-csm-r097">{{cite web
 | url = http://www.intel.com/content/dam/doc/reference-guide/efi-compatibility-support-module-specification-v097.pdf
 | title = Intel® Platform Innovation Framework for EFI
 | work = Compatibility Support Module Specification (revision 0.97)
 | date = 4 September 2007 | access-date = 6 October 2013
 | publisher = Intel
}}</ref> 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 connector|PS/2]] counterparts.<ref name="intel-csm-r097" />

In November 2017, Intel announced that it planned to phase out support CSM for client platforms by 2020.<ref>{{Cite news|url=https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-the-last-vestiges-of-the-ancient-pc-bios-by-2020/|title=The PC BIOS will be killed off by 2020 as Intel plans move to pure UEFI|work=Ars Technica|access-date=29 May 2018|language=en-us}}</ref>

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.<ref>{{Cite news|url=https://securelist.com/cosmicstrand-uefi-firmware-rootkit/106973/|title=CosmicStrand: the discovery of a sophisticated UEFI firmware rootkit | work=Securelist by Kaspersky | access-date=4 August 2022 | language=en-us}}</ref>

In August 2023, Intel announced that it planned to phase out support CSM for server platforms by 2024.<ref>{{Cite news|url=https://www.intel.com/content/www/us/en/content-details/630266/removal-of-legacy-boot-support-for-intel-platforms-technical-advisory.html|title=Removal of Legacy Boot Support for Intel Platforms Technical Advisory}}</ref>

Currently {{when|date=October 2024}} most computers based on Intel platforms do not support CSM.{{Citation needed|date=October 2024}}

==== Network booting ====
The UEFI specification includes support for booting over network via the [[Preboot eXecution Environment]] (PXE). PXE booting [[network protocol]]s include [[Internet Protocol]] ([[IPv4]] and [[IPv6]]), [[User Datagram Protocol]] (UDP), [[Dynamic Host Configuration Protocol]] (DHCP), [[Trivial File Transfer Protocol]] (TFTP) and [[iSCSI]].<ref name="uefi-spec-24" /><ref>{{cite web
 | url = https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-netboot-pxe-config-efi.html
 | title = Red Hat Enterprise Linux 6 Installation Guide
 | work = 30.2.2. Configuring PXE boot for EFI
 | access-date = 9 October 2013
 | publisher = [[Red Hat]]
}}</ref>

OS images can be remotely stored on [[storage area network]]s (SANs), with [[iSCSI|Internet Small Computer System Interface]] (iSCSI) and [[Fibre Channel over Ethernet]] (FCoE) as supported protocols for accessing the SANs.<ref name="uefi-spec-24" /><ref>{{cite web
 | url = http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf
 | title = Advances in Pre-OS Networking in UEFI 2.4
 | date = July 2013 | access-date = 29 May 2019
 | publisher = [[Hewlett-Packard]]
 | last = El-Haj-Mahmoud
 | first = Samer
}}</ref><ref>{{cite book
 | url = http://www.redbooks.ibm.com/redbooks/pdfs/sg247986.pdf
 | title = Storage and Network Convergence Using FCoE and iSCSI
 | edition = 2nd
 | first1 = Sangam
 | last1 = Racherla
 | first2 = Silvio
 | last2 = Erdenberger
 | first3 = Harish
 | last3 = Rajagopal
 | first4 = Kai
 | last4 = Ruth
 | date = January 2014 | access-date = 20 April 2022
 | publisher = IBM Redbooks }}</ref>

Version 2.5 of the UEFI specification adds support for accessing boot images over [[HTTP]].<ref>{{cite web
 | url = http://firmwaresecurity.com/2015/05/09/new-uefi-http-boot-support-in-uefi-2-5/
 | title = New UEFI HTTP Boot support in UEFI&nbsp;2.5
 | date = 9 May 2015 | access-date = 13 August 2015
 | website = firmwaresecurity.com
}}</ref>

==== {{Anchor|SECURE-BOOT}}Secure Boot ====
{{See also|#Secure Boot criticism|l1=Secure Boot criticism}}
[[File:REFInd 0.13.2 about menu screenshot.png|upright=1.4|thumb|Example of an active Secure Boot as detected by [[rEFInd]] 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 [[public-key cryptography|signed]] with an acceptable [[digital signature]]. The details of how these drivers are signed is specified in the [https://uefi.org/specs/UEFI/2.11/ UEFI Specification]<ref>{{Cite web |title=32. Secure Boot and Driver Signing — UEFI Specification 2.9A documentation |url=https://uefi.org/specs/UEFI/2.9_A/32_Secure_Boot_and_Driver_Signing.html |access-date=2025-04-15 |website=uefi.org}}</ref> 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.<ref name=uefi-secureboot>{{cite web
 | last = Edge | first = Jake
 | title = UEFI and "secure boot"
 | url = https://lwn.net/Articles/447381/
 | website = [[LWN.net]]
 | access-date = 9 September 2012
}}</ref> 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.<ref name=pcw-ueficontroversy>{{cite web
 | title = Windows 8 Secure Boot: The Controversy Continues
 | url = https://www.pcworld.com/article/248342/windows_8_secure_boot_the_controversy_continues.html
 | website = PC World
 | access-date = 9 September 2012}}</ref>

Secure Boot is supported by [[Windows 8]] and [[Windows 8.1|8.1]], [[Windows Server 2012]] and 2012 R2, [[Windows 10]], [[Windows Server 2016]], [[Windows Server 2019|2019]], and [[Windows Server 2022|2022]], and [[Windows 11]], VMware vSphere 6.5<ref>{{Cite news|url=https://blogs.vmware.com/vsphere/2017/05/secure-boot-esxi-6-5-hypervisor-assurance.html|title=Secure Boot for ESXi 6.5 - Hypervisor Assurance|date=4 May 2017|work=VMware vSphere Blog|access-date=18 August 2017}}</ref> and a number of [[Linux distribution]]s including [[Fedora Linux|Fedora]] (since version 18), [[openSUSE]] (since version 12.3), RHEL (since version 7), CentOS (since version 7<ref>[https://wiki.centos.org/HowTos/UEFI HowTos/UEFI - CentOS Wiki<!-- Bot generated title -->]</ref>), Debian (since version 10),<ref>{{cite web |url=https://www.phoronix.com/scan.php?page=news_item&px=Debian-UEFI-SecureBoot-2018 |title=Debian Making Progress on UEFI SecureBoot Support in 2018 |last=Larabel |first=Michael |date=30 April 2018 |website=Phoronix |publisher=Phoronix Media |access-date=23 May 2018}}</ref> [[Ubuntu]] (since version 12.04.2), [[Linux Mint]] (since version 21.3).,<ref>{{cite web |first=Matthew |last=Garrett |url=http://mjg59.dreamwidth.org/20522.html |title=Secure Boot distribution support |website=Mjg59.dreamwidth.org |date=27 December 2012 |access-date=20 March 2014}}</ref><ref>{{cite web|title=Linux Mint Secure boot|website=Linux Mint|access-date=12 January 2024|url=https://www.linuxmint.com/rel_virginia_whatsnew.php}}</ref> and [[AlmaLinux|AlmaLinux OS]] (since version 8.4<ref>{{Cite web |title=8.4 {{!}} AlmaLinux Wiki |url=https://wiki.almalinux.org/release-notes/8.4.html |access-date=2024-04-10 |website=wiki.almalinux.org}}</ref>). {{As of|2025|1}}, [[FreeBSD]] support is in a planning stage.<ref>{{cite web|title=SecureBoot|url=https://wiki.freebsd.org/SecureBoot|website=FreeBSD Wiki|publisher=FreeBSD|access-date=16 June 2015}}</ref>

=== {{Anchor|SHELL}}UEFI shell ===
[[File:UEFI shell 2.2 screenshot.png|thumb|upright=1.4|Example of a UEFI shell 2.2 session]]
UEFI provides a [[Shell (computing)|shell environment]], which can be used to execute other UEFI applications, including UEFI [[boot loader]]s.<ref name="arch-uefi-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 (<code>memmap</code>), modifying boot manager variables (<code>bcfg</code>), running partitioning programs (<code>diskpart</code>), loading UEFI drivers, and editing text files (<code>edit</code>).<ref name="arch-uefi-shell">{{cite web
 | url = https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Shell
 | title = Unified Extensible Firmware Interface
 | work = UEFI Shell
 | publisher = [[Arch Linux]]
 | access-date = 25 September 2013
}}</ref>{{unreliable source?|date=September 2013}}<ref name="EFI-Shells-and-Scripting">{{cite web
 | url = http://software.intel.com/en-us/articles/efi-shells-and-scripting/
 | title = EFI Shells and Scripting
 | publisher = [[Intel]]
 | access-date = 25 September 2013
}}</ref><ref name="uefi-shell-spec-2">{{cite web
 | url = http://www.uefi.org/specifications
 | title = UEFI Shell Specification Version 2.0, Errata A
 | format = PDF | publisher = Unified EFI, Inc.
 | date = May 2012 | access-date = 25 September 2013
}}</ref>

Source code for a UEFI shell can be downloaded from the [[Intel]]'s [[#Intel EFI|TianoCore]]{{Broken anchor|date=2025-04-15|bot=User:Cewbot/log/20201008/configuration|target_link=#Intel EFI|reason= The anchor (Intel EFI) [[Special:Diff/1115112177|has been deleted]].|diff_id=1115112177}} UDK/EDK2 project.<ref>{{cite web |title=EDK2: ShellPkg |url=https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg |website=GitHub |access-date=18 March 2020}}</ref> A pre-built ShellBinPkg is also available.<ref>{{cite web |title=tianocore/edk2: releases |url=https://github.com/tianocore/edk2/releases/ |website=GitHub |language=en}}</ref> 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.<ref name="arch-uefi-shell" /><ref>{{cite web
 | url = http://sourceforge.net/mailarchive/message.php?msg_id=28690732
 | title = Email Archive: edk2-devel
 | work = [edk2] Inclusion of UEFI shell in Linux distro iso
 | publisher = [[SourceForge]]
 | year = 2012 | access-date = 25 September 2013
}}</ref><ref>{{cite web
 | url = http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Shell_FAQ
 | title = TianoCore on SourceForge
 | work = Shell FAQ
 | publisher = [[Intel]]
 | access-date = 25 September 2013
}}</ref>

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 <code><EFI_SYSTEM_PARTITION>/SHELLX64.EFI</code>. Some other systems have an already embedded UEFI shell which can be launched by appropriate key press combinations.<ref name="arch-uefi-shell-launching">{{cite web
 | url = https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Launching_UEFI_Shell
 | title = Unified Extensible Firmware Interface
 | work = Launching UEFI Shell
 | publisher = [[Arch Linux]]
 | access-date = 25 September 2013
}}</ref>{{unreliable source?|date=September 2013}}<ref>{{cite web
 | url = http://download.intel.com/support/motherboards/server/sb/efi_whitepaper.pdf
 | title = Basic Instructions for Using EFI for Server Configuration on Intel® Server Boards and Intel® Server Systems
 | publisher = [[Intel]]
 | year = 2008 | access-date = 25 September 2013
}}</ref> For other systems, the solution is either creating an appropriate USB flash drive or adding manually (<code>bcfg</code>) a boot option associated with the compiled version of shell.<ref name="uefi-shell-spec-2" /><ref name="arch-uefi-shell-launching" /><ref>{{cite web
 | url = https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#bcfg
 | title = Unified Extensible Firmware Interface
 | work = bcfg
 | publisher = [[Arch Linux]]
 | access-date = 25 September 2013
}}</ref>{{unreliable source?|date=September 2013}}<ref>{{cite web
 | url = https://wiki.archlinux.org/index.php/GRUB_EFI_Examples#Asus
 | title = GRUB EFI Examples
 | work = Asus
 | publisher = [[Arch Linux]]
 | access-date = 25 September 2013
}}</ref>{{unreliable source?|date=September 2013}}

====Commands====
The following is a list of [[command (computing)|commands]] supported by the EFI shell.<ref name="EFI-Shells-and-Scripting" />

{{div col|colwidth=9em}}
* [[alias (EFI command)|alias]]
* [[attrib (EFI command)|attrib]]
* bcfg
* [[cd (EFI command)|cd]]
* [[cls (EFI command)|cls]]
* [[comp (EFI command)|comp]]
* [[cp (EFI command)|cp]]
* [[date (EFI command)|date]]
* dblk
* dh
* dmpstore
* [[echo (EFI command)|echo]]
* Edd30
* EddDebug
* edit
* err
* guid
* [[help (EFI command)|help]]
* load
* [[ls (EFI command)|ls]]
* map
* mem
* memmap
* [[mkdir (EFI command)|mkdir]]
* mm
* mode
* [[mount (EFI command)|mount]]
* pause
* pci
* reset
* [[rm (EFI command)|rm]]
* set
* stall
* [[time (EFI command)|time]]
* [[type (EFI command)|type]]
* unload
* [[ver (EFI command)|ver]]
* [[vol (EFI command)|vol]]
{{div col end}}

=== Extensions ===
Extensions to UEFI can be loaded from virtually any [[Non-volatile memory|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 [[Read-only memory|ROM]].

=== UEFI Capsule ===
UEFI Capsule defines a Firmware-to-OS firmware update interface, marketed as modern and secure.<ref>{{cite web |url=https://tianocore-docs.github.io/Understanding_UEFI_Secure_Boot_Chain/draft/secure_boot_chain_in_uefi/boot_chain__putting_it_all_together/signed-capsule-update|title=Signed Capsule Update|website=tianocore-docs.github.io}}</ref> [[Windows 8]], [[Windows 8.1]], [[Windows 10]],<ref>{{Cite web|last=barrygolden|title=Windows UEFI firmware update platform - Windows drivers|url=https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/windows-uefi-firmware-update-platform|access-date=2020-09-25|website=docs.microsoft.com|language=en-us}}</ref> and [[Fwupd]] for Linux each support the UEFI Capsule.

=== Hardware ===
Like [[BIOS]], UEFI initializes and tests system hardware components (e.g. memory training, PCIe link training, USB link training on typical x86 systems), and then loads the [[boot loader]] from a [[mass storage device]] or through a [[network booting|network connection]]. In [[x86]] systems, the UEFI firmware is usually stored in the [[NOR flash]] chip of the motherboard.<ref>{{Cite web|title=Getting Started {{!}} Microchip Technology|url=https://www.microchip.com/en-us/products/memory/serial-and-parallel-flash/getting-started|access-date=2020-12-24|website=www.microchip.com}}</ref><ref>{{cite web | url=https://github.com/FrameworkComputer/Framework-Laptop-16/blob/main/Mainboard/Mainboard_Interfaces_Schematic_Framework_Laptop_16_7040_Series.pdf | title=Framework-Laptop-16/Mainboard/Mainboard_Interfaces_Schematic_Framework_Laptop_16_7040_Series.PDF at main · FrameworkComputer/Framework-Laptop-16 | website=[[GitHub]] }}</ref> In some ARM-based Android and Windows Phone devices, the UEFI boot loader is stored in the [[eMMC]] or [[eUFS]] flash memory.

== Classes ==
UEFI machines can have one of the following classes, which were used to help ease the transition to UEFI:<ref>{{Cite book |last1=Barry |first1=Peter |url=https://www.worldcat.org/oclc/810455404 |title=Modern embedded computing : designing connected, pervasive, media-rich systems |last2=Crowley |first2=Patrick |date=2012 |publisher=[[Morgan Kaufmann Publishers]] |isbn=978-0-12-394407-8 |location=Waltham, MA |pages=169 |oclc=810455404}}</ref>

* 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, eg. 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.<ref>{{Cite web |title=Intel schrapt bios-compatibiliteit uefi in 2020 |url=https://tweakers.net/nieuws/131947/intel-schrapt-bios-compatibiliteit-uefi-in-2020.html |access-date=2022-12-30 |website=[[Tweakers]] |language=NL}}</ref>

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.{{Citation needed | date = December 2021}}

== 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 SRAM) 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.<ref>{{cite book | url=https://books.google.com/books?id=wylDDgAAQBAJ | title=Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition | isbn=978-1-5015-0569-0 | last1=Zimmer | first1=Vincent | last2=Rothman | first2=Michael | last3=Marisetty | first3=Suresh | date=2017 | publisher=Walter de Gruyter GmbH & Co KG }}</ref>

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.

==== PEI Foundation ====
After SEC phase hand off, platform responsibility is taken by PEI Foundation. it's responsibility is:
* Successful dispatch of PEIMs(pre-EFI Initialization modules).
* Initialization permanent memory(RAM).
* And handing over to next stage which is DXE.
* facilitate the communication of PEIMs called PPI.

==== PEI Dispatcher ====
This component is responsible for invoking PEIMs and managing there dependencies.

==== Pre-EFI Initialization modules ====
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.

==== PEIMs-to-PEIMs Interfaces ====
This is a [[ data structure | 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 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.<ref>{{cite book | url=https://books.google.com/books?id=wylDDgAAQBAJ | title=Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition | isbn=978-1-5015-0569-0 | last1=Zimmer | first1=Vincent | last2=Rothman | first2=Michael | last3=Marisetty | first3=Suresh | date=2017 | publisher=Walter de Gruyter GmbH & Co KG }}</ref>

=== BDS – Boot Device Select (Boot Manager)===
BDS is a part of the DXE.<ref>{{Cite web|url=https://github.com/tianocore/tianocore.github.io/wiki/PI-Boot-Flow|title=PI Boot Flow · tianocore/Tianocore.github.io Wiki|website=[[GitHub]]}}</ref><ref>{{Cite web|url=https://ami.com/en/?Aptio_V_Status_Codes.pdf|title = Engineering Services}}</ref> In this stage, boot devices are initialized, UEFI drivers or [[Option ROM]]s of PCI devices are executed according to architecturally defined variables called '''NVRAM'''.

=== 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 {{Mono|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. [[System Management Mode|SMM]] and [[Advanced Configuration and Power Interface|ACPI]].<ref>{{Cite web|title=The Unified Extensible Firmware Interface (UEFI)|publisher=The Linux Kernel documentation|url=https://www.kernel.org/doc/html/latest/arch/arm/uefi.html}}</ref>{{failed verification|date=November 2024}} A typical modern OS will prefer to use its own programs (such as [[kernel driver]]s) 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 ===
[[File:Surface UEFI.png|upright=1.4|thumb|[[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]].<ref name="TianoCoreboot">{{cite web|url=http://www.coreboot.org/TianoCore|title=TianoCore - coreboot|access-date=25 May 2012}}</ref>

[[Phoenix Technologies]]' implementation of UEFI is branded as SecureCore Technology (SCT).<ref name="PhoenixSecureCoreTiano">{{cite web|url=http://www.phoenix.com/pages/phoenix-securecore-tiano-tm|title=SecureCore Tiano™|publisher=Phoenix Technologies|access-date=14 September 2010|url-status=dead|archive-url=https://web.archive.org/web/20100906050148/http://www.phoenix.com/pages/phoenix-securecore-tiano-tm|archive-date=6 September 2010}}</ref> [[American Megatrends]] offers its own UEFI firmware implementation known as Aptio,<ref name="AMIAptio4">{{cite web |url=https://ami.com/ami_downloads/Aptio_4_Data_Sheet.pdf |title=Aptio®: The Complete UEFI Product Solution |publisher=American Megatrends, Inc |access-date=2 May 2018}}</ref> while [[Insyde Software]] offers InsydeH2O,<ref name="InsydeH2O">{{cite web |url=https://www.insyde.com/company/who-we-are/why-us |title=Why US? |publisher=Insyde Software Corp |access-date=2 May 2018}}</ref> and Byosoft offers ByoCore.

In December 2018, [[Microsoft]] released an open source version of its TianoCore EDK2-based UEFI implementation from the [[Microsoft Surface|Surface]] line, [[Project Mu]].<ref>{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-Project-Mu-UEFI|title=Microsoft Announces "Project Mu" For Open-Source UEFI Alternative To TianoCore |website=Phoronix|access-date=20 December 2018}}</ref>

An implementation of the UEFI API was introduced into the Universal Boot Loader ([[Das U-Boot]]) in 2017.<ref name="MarryingU-BootUEFIandGRUB">{{cite web|url=http://events17.linuxfoundation.org/sites/events/files/slides/Marrying%20U-Boot%2C%20UEFI%20and%20grub.pdf|title=Marrying U-Boot UEFI and GRUB|access-date=12 September 2018}}</ref> On the [[ARM architecture#AArch64|ARMv8]] architecture [[Linux]] distributions use the U-Boot UEFI implementation in conjunction with [[GNU GRUB]] for booting (e.g. [[SUSE Linux]]<ref name="SuseU-BootGRUB">{{cite web|url=https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf|title=UEFI on Top of U-Boot|access-date=12 September 2018|archive-date=11 September 2018|archive-url=https://web.archive.org/web/20180911081903/https://www.suse.com/media/article/UEFI_on_Top_of_U-Boot.pdf|url-status=dead}}</ref>), the same holds true for OpenBSD.<ref name="OpenBSD63onRPi3">{{cite web|url=https://bijanebrahimi.github.io/blog/installing-openbsd-63-on-raspberry-pi-3.html|title=Installing OpenBSD 6.3 on Raspberry 3|access-date=12 September 2018|archive-date=21 November 2018|archive-url=https://web.archive.org/web/20181121075131/http://bijanebrahimi.github.io/blog/installing-openbsd-63-on-raspberry-pi-3.html|url-status=dead}}</ref> For booting from iSCSI [[iPXE]] can be used as a UEFI application loaded by U-Boot.<ref name="UBootiPXE">{{cite web|url=https://u-boot.readthedocs.io/en/latest/uefi/iscsi.html|title=iSCSI booting with U-Boot and iPXE|access-date=18 May 2020|archive-date=31 July 2020|archive-url=https://web.archive.org/web/20200731050609/https://u-boot.readthedocs.io/en/latest/uefi/iscsi.html|url-status=dead}}</ref>

=== 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; they were able to boot [[Microsoft Windows|Windows]], [[Linux]], [[FreeBSD]] and [[HP-UX]]; [[OpenVMS]] added UEFI capability in June 2003.

In January 2006, [[Apple Inc.]] shipped its first [[Apple–Intel architecture|Intel-based Macintosh computers]]. These systems used EFI instead of [[Open Firmware]], which had been used on its previous PowerPC-based systems.<ref>Apple Computer. "[https://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_diffs/chapter_3_section_10.html Universal Binary Programming Guidelines, Second Edition: Extensible Firmware Interface (EFI)] {{webarchive |url=https://web.archive.org/web/20080724213607/http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_diffs/chapter_3_section_10.html |date=24 July 2008 }}"</ref> On 5 April 2006, Apple first released [[Boot Camp (software)|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.<ref>[http://www.mactech.com/articles/mactech/Vol.23/23.05/OpenFirmwareToEFI/index.html Apple's Transition from Open Firmware to Extensible Firmware Interface], mactech, 2007.</ref>

During 2005, more than one million Intel systems shipped with Intel's implementation of UEFI.<ref name="IntelFrameworkOverviewUEFI">{{cite web | url = http://www.intel.com/technology/framework/overview1.htm |title=Intel® Platform Innovation Framework for UEFI Overview |publisher=Intel |access-date=14 September 2010}}</ref>{{Failed verification|date=December 2020}} 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 system]]s based on [[XScale]] cores.<ref name="IntelFrameworkOverviewUEFI" />

The EDK (EFI Developer Kit) includes an NT32 target, which allows EFI firmware and EFI applications to run within a [[Microsoft Windows|Windows]] 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, [[Micro-Star International|MSI]] motherboards with ClickBIOS, HP EliteBook Notebook PCs.

In 2009, IBM shipped [[IBM System x|System x]] machines (x3550 M2, x3650 M2, iDataPlex dx360 M2) and [[IBM BladeCenter|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.<ref>{{citation | publisher = UEFI | url = http://www.uefi.org/news/uefi_industry/UEFIEvaluationPlatforms_2011_05.pdf | title = Evaluating UEFI using Commercially Available Platforms and Solutions | date = May 2011 | url-status = dead | archive-url = https://web.archive.org/web/20120322062159/http://www.uefi.org/news/uefi_industry/UEFIEvaluationPlatforms_2011_05.pdf | archive-date = 22 March 2012 | df = dmy-all }}</ref>

In 2011, major vendors (such as [[ASRock]], [[Asus]], [[Gigabyte Technology|Gigabyte]], and [[Micro-Star International|MSI]]) launched several consumer-oriented motherboards using the Intel [[List of Intel chipsets#5/6/7/8/9 Series chipsets|6-series]] [[LGA 1155]] chipset and AMD 9 Series [[Socket AM3+|AM3+]] chipsets with UEFI.<ref name="Asus Motherboard">[http://www.bit-tech.net/hardware/motherboards/2010/11/16/asus-lga1155-motherboard-preview/1 Asus P67 Motherboard Preview].</ref>

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 [[smartphone]]s, 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.<ref>{{cite web | publisher = Microsoft | url = http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx | title = Windows Hardware Certification Requirements for Client and Server Systems | date = January 2013 |quote=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.}}</ref><ref name=pcmag-connected>{{cite web|title=Microsoft: All You Need to Know About Windows 8 on ARM|url=https://www.pcmag.com/article2/0,2817,2400059,00.asp|work=PC Magazine|access-date=30 September 2013|archive-date=6 September 2013|archive-url=https://web.archive.org/web/20130906173044/http://www.pcmag.com/article2/0,2817,2400059,00.asp|url-status=dead}}</ref>

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.<ref>{{Cite web|url=http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf|title="Last Mile" Barriers to Removing Legacy BIOS|last=Richardson|first=Brian|date=30 October 2017|access-date=22 November 2017}}</ref> By 2019, all computers based on Intel platforms no longer have legacy PC BIOS support.

=== Operating systems ===
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 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 <code><EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI</code>, where short name of the machine type can be <code>IA32</code>, <code>X64</code>, <code>IA64</code>, <code>ARM</code> or <code>AA64</code>.<ref name="uefi-spec-24" /> 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 early 2000s,<ref>[http://sourceforge.net/mailarchive/forum.php?thread_name=1077918495.14506.1.camel%40raphael.fc.hp.com&forum_name=elilo-announce Announcement of release 3.5pre1] by maintainer Brett Johnson made on 27 February 2004.</ref> using the [[elilo]] EFI boot loader or, more recently, EFI versions of [[GNU GRUB|GRUB]].<ref name="debiangrubexample">{{citation | url = http://packages.debian.org/sid/grub-efi | title = EFI version of Grub | publisher = Debian GNU/Linux | access-date =1 May 2008}}</ref> Grub+Linux also supports booting from a GUID partition table without UEFI.<ref name="grub-bios-installation"/> The distribution [[Ubuntu]] added support for UEFI Secure Boot as of version 12.10.<ref name=h-ubuntusecureboot>{{cite web|title=Ubuntu will use GRUB 2 for its Secure Boot implementation|url=http://www.h-online.com/open/news/item/Ubuntu-will-use-GRUB-2-for-its-Secure-Boot-implementation-1714232.html|publisher=The H Online|access-date=28 October 2012}}</ref> Furthermore, the Linux kernel can be compiled with the option to run as an EFI bootloader on its own through the EFI boot stub feature.
* [[HP-UX]] has used (U)EFI as its boot mechanism on [[IA-64]] systems since 2002.
* [[OpenVMS]] has used EFI on IA-64 since its initial evaluation release in December 2003, and for production releases since January 2005.<ref>{{citation | url = http://h71000.www7.hp.com/openvms/os/openvms-release-history.html | publisher = HP | title = OpenVMS Release History | access-date = 16 September 2008 | url-status = dead | archive-url = https://web.archive.org/web/20090105052030/http://h71000.www7.hp.com/openvms/os/openvms-release-history.html | archive-date = 5 January 2009 | df = dmy-all }}</ref> OpenVMS on x86-64 also uses UEFI to boot the operating system.<ref>{{cite web|url=https://vmssoftware.com/pdfs/State_of_Port_20171006.pdf|access-date=2020-09-09|date=2017-10-06|website=vmssoftware.com|title=State of the Port to x86-64|archive-date=22 September 2020|archive-url=https://web.archive.org/web/20200922100900/https://vmssoftware.com/pdfs/State_of_Port_20171006.pdf|url-status=dead}}</ref>
* [[Apple Inc.|Apple]] uses EFI for its line of [[Apple–Intel architecture|Intel-based Macs]]. [[Mac OS X Tiger|Mac OS X v10.4]] Tiger and [[Mac OS X Leopard|Mac OS X v10.5]] Leopard implement EFI v1.10 in 32-bit mode even on newer 64-bit CPUs, but full support arrived with [[OS X Mountain Lion|OS X v10.8 Mountain Lion]].<ref name="appleuefiversion1">{{citation | url = http://refit.sourceforge.net/info/vista.html | title = rEFIt — Windows Vista and EFI | publisher = SourceForge | access-date = 31 May 2008 | archive-date = 5 September 2008 | archive-url = https://web.archive.org/web/20080905112841/http://refit.sourceforge.net/info/vista.html | url-status = dead }}</ref>
* The [[Itanium]] versions of [[Windows 2000]] (Advanced Server Limited Edition and Datacenter Server Limited Edition; based on the pre-release [[Windows Server 2003]] codebase) implemented EFI 1.10 in 2002. [[Windows XP 64-bit Edition]], [[Windows 2000]] Advanced Server Limited Edition (pre-release Windows Server 2003) and [[Windows Server 2003]] for [[IA-64]], all of which are for the Intel [[Itanium]] family of processors, implement EFI, a requirement of the platform through the [[DIG64]] specification.<ref>{{citation | publisher = Microsoft | title = Windows Server TechCenter | url = http://technet2.microsoft.com/WindowsServer/en/Library/6b03fad7-665e-49f3-8e7d-e1a6a5be9cf01033.mspx | contribution = Extensible Firmware Interface | url-status = dead | archive-url = https://web.archive.org/web/20060830101936/http://technet2.microsoft.com/WindowsServer/en/library/6b03fad7-665e-49f3-8e7d-e1a6a5be9cf01033.mspx | archive-date = 30 August 2006 | df = dmy-all }}</ref>
* Microsoft introduced UEFI for x64 Windows operating systems with [[Windows Vista SP1]]<ref>[http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e-84e1-b4085a80e34e/sys-t303_wh07.pptx Unified Extensible Firmware Interface (UEFI) Implementation Guidelines]</ref> and [[Windows Server 2008]] however only UGA (Universal Graphic Adapter) 1.1 or Legacy BIOS [[INT 10h]] is supported; Graphics Output Protocol (GOP) is not supported. Therefore, PCs running 64-bit versions of [[Windows Vista SP1]], [[Windows Vista SP2]], [[Windows 7]], [[Windows Server 2008]] and [[Windows Server 2008 R2]] are compatible with UEFI Class 2.<ref>{{cite web |last1=Ersek |first1=Laszlo |title=Open Virtual Machine Firmware (OVMF) Status Report |url=https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt |website=Linux KVM Project |access-date=2022-11-13 |date=January 2015}}</ref><ref>[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode Boot to UEFI Mode or legacy BIOS mode]</ref> 32-bit UEFI was originally not supported since vendors did not have any interest in producing native 32-bit UEFI firmware because of the mainstream status of [[64-bit computing]].<ref name="WindowsVistaUEFI">{{cite news |url= https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/930061 |title=Unified Extended Firmware Interface support in Windows Vista |publisher=Microsoft |date=26 October 2006 |access-date=12 June 2010 |quote= 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.}}</ref> [[Windows 8]] finally introduced further optimizations for UEFI systems, including Graphics Output Protocol (GOP) support,<ref>[https://docs.microsoft.com/en-us/windows-hardware/drivers/display/microsoft-basic-display-driver Microsoft Basic Display Driver]</ref> a faster startup, 32-bit UEFI support, and Secure Boot support.<ref>{{cite web | url=http://www.winsupersite.com/blog/supersite-blog-39/windows8/microsoft-touts-incredible-windows-8-boot-times-140515 | title=Microsoft Touts Incredible Windows 8 Boot Times | access-date=9 September 2011}}</ref><ref name="Windows8UEFISecureBoot">{{cite news |url=https://arstechnica.com/business/news/2011/09/windows-8-secure-boot-will-complicate-linux-installs.ars |title=Windows 8 secure boot could complicate Linux installs |first=Jon |last=Brodkin |publisher=Ars Technica |date=21 September 2011 |access-date=23 September 2011}}</ref> Since [[Windows 8]], the UEFI firmware with [[ACPI]] protocol is a mandatory requirement for ARM-based Microsoft Windows operating systems. Microsoft began requiring UEFI to run Windows with [[Windows 11]],<ref>{{cite web|url=https://www.microsoft.com/en-us/windows/windows-11-specifications|title=Find Windows 11 specs, features, and computer requirements|publisher=[[Microsoft]]}}</ref> with IoT Enterprise editions of Windows 11 since version 24H2 exempt from the requirement.<ref>{{Cite web|date=May 22, 2024 |title=Minimum System Requirements for Windows IoT Enterprise|url=https://learn.microsoft.com/en-gb/windows/iot/iot-enterprise/Hardware/System_Requirements?tabs=Windows11|access-date=June 7, 2024 |website=[[Microsoft Learn]]}}</ref>
* On 5 March 2013, the [[FreeBSD Foundation]] awarded a grant to a developer seeking to add UEFI support to the [[FreeBSD]] kernel and bootloader.<ref name=fbsd-uefi>{{cite web|title=FreeBSD to get UEFI support|url=http://www.h-online.com/open/news/item/FreeBSD-to-get-UEFI-support-1816670.html|publisher=The H|access-date=7 March 2013}}</ref> The changes were initially stored in a discrete branch of the FreeBSD source code, but were merged into the mainline source on 4 April 2014 (revision 264095); the changes include support in the installer as well.<ref name=fbsd-uefi-merge>{{cite web|title=UEFI - FreeBSD Wiki|url=https://wiki.freebsd.org/UEFI|publisher=FreeBSD.org|access-date=19 June 2014}}</ref> UEFI boot support for amd64 first appeared in FreeBSD 10.1 and for arm64 in FreeBSD 11.0.<ref>{{Cite web|title=uefi(8)|url=https://www.freebsd.org/cgi/man.cgi?query=uefi&sektion=8|access-date=2021-01-11|website=www.freebsd.org}}</ref>
* Oracle [[Solaris (operating system)|Solaris]] 11.1 and later support UEFI boot for x86 systems with UEFI firmware version 2.1 or later. [[GNU GRUB|GRUB]] 2 is used as the boot loader on x86.<ref name="solaris-uefi">{{cite web
 | url = http://www.oracle.com/technetwork/server-storage/solaris11/documentation/solaris11-1-whatsnew-1732377.pdf
 | title = Oracle Solaris 11.1 &mdash; What's New
 | access-date = 4 November 2013
 | publisher = oracle.com }}</ref>
* [[OpenBSD]] 5.9<ref>{{Cite web|url=http://www.openbsd.org/59.html|title=OpenBSD 5.9|website=www.openbsd.org|access-date=11 September 2016}}</ref> introduced UEFI boot support for 64-bit x86 systems using its own custom loader, OpenBSD 6.0 extended that support to include ARMv7.<ref>{{Cite web|url=http://www.openbsd.org/60.html|title=OpenBSD 6.0|website=www.openbsd.org|access-date=11 September 2016}}</ref>
* [[illumos]] added basic UEFI support in October 2017.<ref>{{Cite web|url=https://www.illumos.org/issues/8422|title=8422 uts: basic UEFI support for illumos|website=www.illumos.org|access-date=17 December 2024}}</ref>
* [[ArcaOS]] supports UEFI booting since the 5.1 release.<ref>{{Cite web|url=https://www.theregister.com/2023/09/04/arcaos_51/|title=ArcaOS 5.1 gives vintage OS/2 a UEFI facelift for the 21st century|first=Liam|last=Proven|date=2023-09-04|publisher=[[The Register]]|language=en|access-date=2023-09-04}}</ref> ArcaOS' UEFI support emulates specific [[BIOS]] functionality which the operating system depends on (particularly interrupts [[INT 10H]] and [[INT 13H]]).<ref>{{cite web|url=https://www.youtube.com/watch?v=X07tnbq8_sM|website=youtube.com|date=2019-08-08|access-date=2020-09-22|title=Booting ArcaOS on UEFI hardware (demonstration)}}</ref><ref>{{cite journal|url=https://www.techrepublic.com/article/modern-os2-distribution-arcaos-adds-support-for-booting-via-uefi/|archive-url=https://web.archive.org/web/20191021223549/https://www.techrepublic.com/article/modern-os2-distribution-arcaos-adds-support-for-booting-via-uefi/|archive-date=2019-10-21|date=2019-08-13|access-date=2023-09-04|first=James|last=Sanders|website=techrepublic.com|title=Modern OS/2 distribution ArcaOS adds support for booting via UEFI}}</ref>

=== With virtualization ===
* [[HP Integrity Virtual Machines]] provides UEFI boot on HP Integrity Servers. It also provides a virtualized UEFI environment for the guest UEFI-aware OSes.
* Intel hosts an Open Virtual Machine Firmware project on SourceForge.<ref>{{citation | url = http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF | publisher = SourceForge | title = Open Virtual Machine Firmware | url-status = dead | archive-url = https://web.archive.org/web/20111006173225/http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF | archive-date = 6 October 2011 | df = dmy-all }}</ref>
* [[VMware Fusion]] 3 software for Mac OS X can boot Mac OS X Server virtual machines using UEFI.
* [[VMware Workstation]] prior to version 11 unofficially supports UEFI, but is manually enabled by editing the .vmx file.<ref>{{cite web|url=https://communities.vmware.com/thread/420405 |title=VMWare Workstation EFI firmware &#124; VMware Communities |date=3 October 2012 |publisher=Communities.vmware.com |access-date=28 February 2014}}</ref> [[VMware Workstation]] version 11 and above supports UEFI, independently of whether the physical host system is UEFI-based. VMware Workstation 14 (and accordingly, Fusion 10) adds support for the [[#Secure Boot|Secure Boot]] feature of UEFI.<ref>{{cite web|url=https://communities.vmware.com/docs/DOC-28494 |title=Using EFI/UEFI firmware in a VMware Virtual Machine &#124; VMware Communities |date=6 December 2014 |publisher=Communities.vmware.com |access-date=18 January 2016}}</ref><ref>{{Cite news|url=https://blogs.vmware.com/workstation/2017/08/announcing-vmware-workstation-14.html|title=Announcing VMware Workstation 14 - VMware Workstation Zealot|date=22 August 2017|work=VMware Workstation Zealot|access-date=2 August 2018|language=en-US}}</ref>
* The [[VMware]] [[ESXi]] 5.0 hypervisor officially supports UEFI. Version 6.5 adds support for Secure Boot.<ref>{{cite web|url=https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-new-features.html |title=What's New in vSphere 5.0 |publisher=Vmware.com |access-date=28 February 2014}}</ref><ref>{{Cite web|url=https://pubs.vmware.com/Release_Notes/en/vsphere/65/vsphere-esxi-vcenter-server-65-release-notes.html|title=VMware vSphere 6.5 Release Notes|website=pubs.vmware.com|access-date=13 January 2017}}</ref>
* [[VirtualBox]] has implemented UEFI since 3.1,<ref>{{citation | url = http://www.virtualbox.org/wiki/Changelog-3.1 | publisher = VirtualBox | title = 3.1 Changelog | url-status = dead | archive-url = https://web.archive.org/web/20100928210932/http://www.virtualbox.org/wiki/Changelog-3.1 | archive-date = 28 September 2010 | df = dmy-all }}</ref> but is limited to Unix/Linux operating systems and Windows 8 and later (does not work with Windows Vista x64 and Windows 7 x64).<ref>{{citation | url = http://www.virtualbox.org/ticket/7702 | publisher = VirtualBox | title = Ticket 7702}}</ref><ref>{{citation | url = http://forums.virtualbox.org/viewtopic.php?f=1&p=183022#p114765 | publisher = VirtualBox | title = Forum | contribution = Statement by sr. software engineer at Oracle}}</ref>
* [[QEMU]]/[[Kernel-based Virtual Machine|KVM]] can be used with the Open Virtual Machine Firmware (OVMF) provided by [[#Intel EFI|TianoCore]]{{Broken anchor|date=2025-04-15|bot=User:Cewbot/log/20201008/configuration|target_link=#Intel EFI|reason= The anchor (Intel EFI) [[Special:Diff/1115112177|has been deleted]].|diff_id=1115112177}}.<ref>{{cite web|url=https://fedoraproject.org/wiki/Testing_secureboot_with_KVM |title=Testing secureboot with KVM |publisher=FedoraProject |access-date=28 February 2014}}</ref>
* The second generation of the Microsoft [[Hyper-V]] virtual machine supports virtualized UEFI.<ref>{{cite web|url=https://technet.microsoft.com/en-us/library/dn282278.aspx |title=What's New in Hyper-V for Windows Server 2012 R2 |publisher=MicrosoftTechNet |access-date=24 June 2013}}</ref>
* [[Google Cloud Platform]] Shielded VMs support virtualized UEFI to enable Secure Boot.<ref>{{cite web|url=https://cloud.google.com/shielded-vm?gclid=Cj0KCQiA7aPyBRChARIsAJfWCgLq4tbyWeZHT6RrfMxAP5_X6O52Dq64WfAS_3TupIV3_moxFlReSGUaAqz0EALw_wcB|title=Shielded VMs|access-date=16 February 2019}}</ref>

== {{Anchor|EADK}}Applications development ==
''EDK2 Application Development Kit'' (EADK) makes it possible to use [[C standard library|standard C library]] functions in UEFI applications. EADK can be freely downloaded from the [[Intel]]'s TianoCore UDK / EDK2 [[SourceForge]] project. As an example, a port of the [[Python (programming language)|Python]] interpreter is made available as a UEFI application by using the EADK.<ref>{{cite web
 | url = http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDKII_EADK
 | title = TianoCore on SourceForge: EDK2 Application Development Kit (EADK)
 | access-date = 25 September 2013
 | publisher = [[Intel]]
}}</ref> The development has moved to GitHub since UDK2015.<ref>{{cite web |title=Tianocore: UDK |url=https://github.com/tianocore/tianocore.github.io/wiki/UDK |website=GitHub |language=en}}</ref>

A minimalistic "[[hello, world]]" C program written using EADK looks similar to its [[C (programming language)#HELLOWORLD|usual C counterpart]]:

<syntaxhighlight lang="c">
#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>

EFI_STATUS EFIAPI ShellAppMain(IN UINTN Argc, IN CHAR16 **Argv)
{
    Print(L"hello, world\n");
    return EFI_SUCCESS;
}
</syntaxhighlight>

== Criticism ==
Numerous digital rights activists have protested UEFI.
[[Ronald G. Minnich]], a co-author of [[coreboot]], and [[Cory Doctorow]], a digital rights activist, have criticized UEFI as an attempt to remove the ability of the user to truly control the computer.<ref name="FosdemInterviewRonaldGMinnich">{{cite web | url = https://archive.fosdem.org/2007/interview/ronald%2bg%2bminnich.html |title = Interview: Ronald G Minnich | publisher = Fosdem | date = 6 February 2007 | access-date =14 September 2010}}</ref><ref>{{citation | url = http://boingboing.net/2011/12/27/the-coming-war-on-general-purp.html | title = The Coming War on General Purpose Computation | first = Cory | last = Doctorow | date = 27 December 2011 | access-date = 25 September 2013}}</ref> 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.<ref name="YouTubeCorebootFirmware">{{cite web |url = https://www.youtube.com/watch?v=X72LgcMpM9k | title = coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware |publisher=YouTube |date=31 October 2008 |access-date=14 September 2010 }}</ref>

Open-source project TianoCore also provides UEFIs.<ref>{{citation | chapter-url = http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome | publisher = SourceForge | title = TianoCore | chapter = Welcome | url-status = dead | archive-url = https://web.archive.org/web/20120423101551/http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome | archive-date = 23 April 2012 | df = dmy-all }}</ref> TianoCore lacks the specialized firmware drivers and modules that initialize chipset functions, but TianoCore is one of many payload options of [[coreboot]]. The development of coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.

=== {{Anchor|Secure Boot criticism}}Secure Boot ===
{{See also|Windows 8#Reception}}
[[File:Secure Boot keys example screenshot.png|upright=1.4|thumb|Examples of custom Secure Boot public keys]]
[[File:Shim MokManager screenshot.png|upright=1.4|thumb|MokManager, a part of shim bootloader used to enroll Machine Owner Key (MOK) to UEFI system]]
In 2011, Microsoft announced that computers certified to run its [[Windows 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.<ref>{{cite web | url=https://www.networkworld.com/article/738394/microsoft-subnet-next-gen-boot-spec-could-forever-lock-linux-off-windows-8-pcs.html | title=Next-gen boot spec could forever lock Linux off Windows 8 PCS }}</ref><ref>{{cite web | url=https://arstechnica.com/information-technology/2011/09/windows-8-secure-boot-will-complicate-linux-installs/ | title=Windows 8 secure boot could complicate Linux installs | date=21 September 2011 }}</ref> Following the announcement, the company was accused by critics and free software/open source advocates (including the [[Free Software Foundation]]) of trying to use the Secure Boot functionality of UEFI to [[Vendor lock-in|hinder or outright prevent]] the installation of alternative operating systems such as [[Linux]]. Microsoft denied that the Secure Boot requirement was intended to serve as a form of [[Vendor lock-in|lock-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 the [[ARM architecture]].<ref name=pcw-ueficontroversy/><ref name="cwuk-arm">{{cite web|url=http://www.computerworlduk.com/blogs/open-enterprise/is-microsoft-blocking-linux-booting-on-arm-hardware-3569162/ |title=Is Microsoft Blocking Linux Booting on ARM Hardware? |publisher=Computerworld UK |access-date=6 March 2012}}</ref> [[Windows 10]] allows [[original equipment manufacturer|OEM]]s to decide whether or not Secure Boot can be managed by users of their x86 systems.<ref name=arstechnica-securebootw10>{{cite web|title=Windows 10 to make the Secure Boot alt-OS lock out a reality|url=https://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/|website=Ars Technica|date=20 March 2015|access-date=21 March 2015}}</ref>

Other developers raised concerns about the legal and practical issues of implementing support for Secure Boot on Linux systems in general. Former [[Red Hat]] developer [[Matthew Garrett]] noted that conditions in the [[GNU General Public License#Version 3|GNU General Public License version 3]] may prevent the use of the [[GNU GRUB|GNU GRand Unified Bootloader]] without a distribution's developer disclosing the private key (however, the [[Free Software Foundation]] has since clarified its position, assuring that the responsibility to make keys available was held by the hardware manufacturer),<ref>{{cite web |title=Free Software Foundation recommendations for free operating system distributions considering Secure Boot — Free Software Foundation — working together for free software |url=https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web |website=Free Software Foundation |access-date=18 March 2020}}</ref><ref name=h-ubuntusecureboot/> and that it would also be difficult for advanced users to build custom [[Linux kernel|kernel]]s that could function with Secure Boot enabled without self-signing them.<ref name="cwuk-arm"/> 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.<ref name="ElReg1">{{cite news|url=https://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/|title=MS denies secure boot will exclude Linux|publisher=The Register|date=23 September 2011|access-date=24 September 2011}}</ref>

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.<ref>{{cite web|title=Shimming your way to Linux on Windows 8 PCs|url=https://www.zdnet.com/article/shimming-your-way-to-linux-on-windows-8-pcs/|publisher=ZDNet|access-date=26 February 2013}}</ref> [[Ubuntu (operating system)|Ubuntu 12.10]] uses an older version of shim{{Which|date=October 2017}} pre-configured for use with [[Canonical Ltd.|Canonical]]'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 the [[user 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 custom [[kernel module]]s as well, without the need to reconfigure the system.<ref name=h-ubuntusecureboot/><ref name=lwn-efilinux/><ref name=h-mscert>{{cite web|title=No Microsoft certificate support in Linux kernel says Torvalds|url=http://www.h-online.com/open/news/item/No-Microsoft-certificate-support-in-Linux-kernel-says-Torvalds-1811883.html|publisher=The H|access-date=26 February 2013}}</ref> 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{{emdash}}requiring both a Canonical key and a Microsoft key (for compatibility reasons) to be included in their firmware. [[Fedora (operating system)|Fedora]] also uses shim,{{Which|date=October 2017}} but requires that both the kernel and its modules be signed as well.<ref name=lwn-efilinux>{{cite web|title=Ubuntu details its UEFI Secure Boot plans|url=https://lwn.net/Articles/503803/|publisher=Linux Weekly News|access-date=11 September 2012}}</ref> shim has Machine Owner Key (MOK) that can be used to sign locally-compiled kernels and other software not signed by distribution maintainer.<ref>{{Cite web |last=Smith |first=Roderick W. |date=4 November 2012 |title=Managing EFI Boot Loaders for Linux: Dealing with Secure Boot (Using the Shim Program) |url=https://www.rodsbooks.com/efi-bootloaders/secureboot.html#shim |access-date=17 January 2025 |website=Roderick W. Smith's Web Page}}</ref>

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.<ref name=h-mscert/> 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 master [[X.509]] key embedded in [[Portable Executable|PE]] files signed by Microsoft. However, the proposal was criticized by Linux creator [[Linus Torvalds]], who attacked Red Hat for supporting Microsoft's control over the Secure Boot infrastructure.<ref name=ars-linus>{{cite web|title=Linus Torvalds: I will not change Linux to "deep-throat Microsoft"|date=26 February 2013|url=https://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/|publisher=Ars Technica|access-date=26 February 2013}}</ref>

On 26 March 2013, the [[Spain|Spanish]] free software development group Hispalinux filed a formal complaint with the [[European Commission]], contending that Microsoft's Secure Boot requirements on OEM systems were "obstructive" and [[anti-competitive practices|anti-competitive]].<ref name=reuters-hispalinuxuefi>{{cite news|title=Exclusive: Open software group files complaint against Microsoft to EU|url=https://www.reuters.com/article/us-microsoft-eu-idUSBRE92P0E120130326|publisher=Reuters|access-date=26 March 2013|date=26 March 2013}}</ref>

At the [[Black Hat Briefings|Black 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.<ref name=itworld-securebootexploit>{{cite web|title=Researchers demo exploits that bypass Windows 8 Secure Boot|url=http://www.itworld.com/endpoint-security/367583/researchers-demo-exploits-bypass-windows-8-secure-boot|work=IT World|access-date=5 August 2013|archive-date=5 August 2013|archive-url=https://web.archive.org/web/20130805113138/http://www.itworld.com/endpoint-security/367583/researchers-demo-exploits-bypass-windows-8-secure-boot|url-status=dead}}</ref>

In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems.<ref>{{cite news|last1=MENDELSOHN|first1=Tom|title=Secure Boot snafu: Microsoft leaks backdoor key, firmware flung wide open [Updated]|url=http://arstechnica.co.uk/security/2016/08/microsoft-secure-boot-firmware-snafu-leaks-golden-key/|access-date=12 August 2016|publisher=Ars Technica|date=12 August 2016}}</ref> 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 of [[rootkit]] and [[bootkit]] 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 in [[ARM architecture]] and [[Windows 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|date=October 2017}}

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”.<ref>{{cite web|last1=Smolár|first1=Martin|title=BlackLotus UEFI bootkit: Myth confirmed|url= https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/|access-date=1 March 2023|website=welivesecurity.com|date=1 March 2023}}</ref><ref>{{cite news|last1=Goodin|first1=Dan|title=Stealthy UEFI malware bypassing Secure Boot enabled by unpatchable Windows flaw|url= https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/|access-date=6 March 2023|publisher=Ars Technica|date=6 March 2023}}</ref>

In August 2024, the [[Windows 11]] and [[Windows 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 of [[Windows Boot Manager]] and shim, which refuse buggy or vulnerable intermediate bootloaders (usually older versions of Windows Boot Manager and [[GNU GRUB|GRUB]]) to load in the boot process. The change was reverted the next month.<ref> {{Cite web |last=WindowsCommunications |date=2024-08-26 |title=Windows 11, version 23H2 known issues and notifications |url=https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2 |access-date=2024-09-03 |website=learn.microsoft.com |language=en-us}}</ref>

Many [[Linux distributions]] support UEFI Secure Boot {{As of|2025|January|lc=y}}, such as [[RHEL]] (RHEL 7 and later), [[CentOS]] (CentOS 7 and later<ref>{{Cite web|title=HowTos/UEFI - CentOS Wiki|url=https://wiki.centos.org/HowTos/UEFI|access-date=2020-11-10|website=wiki.centos.org}}</ref>), [[Ubuntu]], [[Fedora (operating system)|Fedora]], [[Debian]] (Debian 10 and later<ref>{{Cite web|title=SecureBoot - Debian Wiki|url=https://wiki.debian.org/SecureBoot|access-date=2020-11-10|website=wiki.debian.org}}</ref>), [[OpenSUSE]], and [[SUSE Linux Enterprise]].<ref>{{Cite web |title=SUSE Linux Enterprise Server 15 SP5: Chapter 17. UEFI (Unified Extensible Firmware Interface) (Administration Guide) |url=https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-uefi.html |access-date=2025-01-12 |website=documentation.suse.com}}</ref>

=== Firmware problems ===
The increased prominence of UEFI firmware in devices has also led to a number of technical problems blamed on their respective implementations.<ref name=zdnet-linux8>{{cite web|title=Linux on Windows 8 PCs: Some progress, but still a nuisance|url=https://www.zdnet.com/article/linux-on-windows-8-pcs-some-progress-but-still-a-nuisance/|publisher=ZDNet|access-date=26 February 2013}}</ref>

Following the release of Windows 8 in late 2012, it was discovered that certain [[Lenovo]] 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.<ref name=p-lenovo>{{cite web|title=Lenovo UEFI Only Wants To Boot Windows, RHEL|url=https://www.phoronix.com/scan.php?page=news_item&px=MTIyOTg|publisher=Phoronix|access-date=26 February 2013}}</ref> Other problems were encountered by several [[Toshiba]] laptop models with Secure Boot that were missing certain certificates required for its proper operation.<ref name=zdnet-linux8/>

In January 2013, a bug surrounding the UEFI implementation on some [[Samsung]] laptops was publicized, which caused them to be [[Brick (electronics)|bricked]] 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.<ref name=theh-brickwindows>{{cite web|title=Samsung UEFI bug: Notebook bricked from Windows|url=http://www.h-online.com/open/news/item/Samsung-UEFI-bug-Notebook-bricked-from-Windows-1801439.html|publisher=The H|access-date=27 February 2013}}</ref><ref name=bittech-uefideath>{{cite web|title=Linux acquitted in Samsung laptop UEFI deaths|url=http://www.bit-tech.net/news/bits/2013/02/11/linux-samsung-deaths-2/1|publisher=Bit-tech|access-date=26 February 2013}}</ref><ref name=theh-samsungbrick>{{cite web|title=Booting Linux using UEFI can brick Samsung laptops|url=http://www.h-online.com/open/news/item/Booting-Linux-using-UEFI-can-brick-Samsung-laptops-1793958.html|publisher=The H|access-date=26 February 2013}}</ref>

== See also ==
* [[Bootloader]]
* [[OpenBIOS]]
* [[UEFI Platform Initialization]] (UEFI PI)
* [[ACPI]] (Advanced Configuration and Power Interface)
* [[System Management BIOS]] (SMBIOS)
* [[Trusted Platform Module]] (TPM)
* [[UEFITool]]
* [[MoonBounce]] 
* [https://github.com/tianocore/edk2-libc/blob/master/AppPkg/Applications/Python/Python-3.6.8/Py368ReadMe.txt Python Interpreter for UEFI Shell]

== Notes ==
{{Notelist}}

== References ==
{{reflist|30em}}

== Further reading ==
*{{cite web |last1=Zimmer |first1=Vincent |first2=Michael |last2=Rothman |first3=Robert |last3=Hale |title=EFI Architecture |url=http://www.drdobbs.com/embedded-systems/efi-architecture/199500688 |work=[[Dr. Dobb's Journal]] |publisher=[[UBM plc|UBM]] |access-date=12 October 2012 |date=10 May 2007}}
*{{cite web |first=Jonathan |last=de Boyne Pollard |url=http://jdebp.eu./FGA/efi-boot-process.html |title=The EFI boot process |work=Frequently Given Answers |date=11 July 2011 |access-date=12 October 2012}}
*{{cite web |first=Jonathan |last=de Boyne Pollard |url=http://jdebp.eu./FGA/windows-nt-6-boot-process.html |title=The Windows NT 6 boot process |work=Frequently Given Answers |date=8 December 2011 |access-date=12 October 2012}}
*{{cite web |first=Roderick W. |last=Smith |url=http://rodsbooks.com/bios2uefi/ |title=A BIOS to UEFI Transformation |work=Roderick W. Smith's Web Page |year=2011 |access-date=12 October 2012}}
*{{cite web |first=Rajiv |last=Kothari |url=http://www.hardwaresecrets.com/article/UEFI-Just-How-Important-It-Really-Is/1385 |title=UEFI – Just How Important It Really Is |work=Hardware Secrets |date=21 September 2011 |access-date=12 October 2012 |url-status=dead |archive-url=https://web.archive.org/web/20121025093125/http://www.hardwaresecrets.com/article/UEFI-Just-How-Important-It-Really-Is/1385 |archive-date=25 October 2012  }}
*{{cite journal |first=Doug |last=Fisher |url=http://noggin.intel.com/technology-journal/2011/151/uefi-today-bootstrapping-continuum |title=UEFI Today: Bootstrapping the Continuum |journal=Intel Technology Journal |publisher=Intel |volume=15 |issue=1 |year=2011 |isbn=9781934053430 |access-date=24 September 2013 |archive-date=27 September 2013 |archive-url=https://web.archive.org/web/20130927155448/http://noggin.intel.com/technology-journal/2011/151/uefi-today-bootstrapping-continuum |url-status=dead }}

== External links ==
{{Commons category|Extensible Firmware Interface}}
* {{Official website|https://uefi.org/}}
* [https://uefi.org/specifications UEFI Specifications]
* [https://www.tianocore.org/ Intel-sponsored open-source EFI Framework initiative]
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel EFI/UEFI portal]
* [https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh824898(v=win.10) Microsoft UEFI Support and Requirements for Windows Operating Systems]
* [https://www.techrepublic.com/blog/windows-and-office/how-windows-8-hybrid-shutdown-fast-boot-feature-works/ How Windows 8 Hybrid Shutdown / Fast Boot feature works]
* [https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process Securing the Windows 10 Boot Process]
* [https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/ LoJax: First UEFI rootkit found in the wild, courtesy of the Sednit group]

{{Firmware and booting}}

[[Category:Unified Extensible Firmware Interface| ]]
[[Category:Articles with example C code]]