Unified Extensible Firmware Interface
This article uses too much jargon, which needs explaining or simplifying. (February 2022)
The English used in this article or section may not be easy for everybody to understand.
The Unified Extensible Firmware Interface (UEFI) is in the boot sequence before the operating system and after the firmware. UEFI replaces the legacy BIOS firmware interface found in all IBM computers. Most UEFI implementations are backwards-compatible to the legacy BIOS. UEFI supports remote diagnostics and repairing of computers, even when there isn't an operating system.
History[change | change source]
Creation[change | change source]
The motivation for EFI came during early development of the first Intel–HP Itanium systems in the mid-1990s. Limitations had become too restrictive for the server platforms Itanium was looking for. The effort to address these restrictions began in 1998 and was first called the Intel Boot Initiative. It was renamed to Extensible Firmware Interface (EFI).
In July 2005, Intel discontinued its development of the EFI specification at version 1.10, and gave 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.
Versions[change | change source]
The latest UEFI specification, version 2.9, was released in March 2021.
Open source[change | change source]
Advantages[change | change source]
UEFI firmware provides several technical advantages over a traditional BIOS system:
- Being able to boot a disk containing large partitions (over 2 TB) with a GUID Partition Table (GPT)[a]
- Flexible pre-OS environment, including network capabilities, a GUI, and multi language support
- 32-bit (for example IA-32) or 64-bit (for example x64) pre-OS environment
- C language programming
- Modular design
- Backward and forward compatibility with the Legacy BIOS
Features[change | change source]
Services[change | change source]
- Graphics Output Protocol (GOP) services
- The Graphics Output Protocol (GOP) gives runtime services; see also Graphics features below. The operating system is allowed to write to the framebuffer provided by GOP during runtime mode.
- 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 get after a reboot.
- Time services
- UEFI provides time services. Time services include support for someone's time zone and daylight saving fields, which allow the hardware's real-time clock to be set to local time or UTC. On machines using a PC-AT real-time clock, by default the hardware clock still has to be set to local time for compatibility with BIOS-based Windows, unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC.
Applications[change | change source]
Beyond loading an OS, UEFI can run UEFI applications, which stay as files on the EFI System Partition. They can be executed from the UEFI Shell, by the firmware's boot manager, or by other UEFI apps. UEFI apps can be developed and installed independently of the original equipment manufacturers (OEMs).
A type of UEFI application is an OS boot loader such as GRUB, rEFInd, Gummiboot, and Windows Boot Manager; which loads some OS files into memory and executes them. Also, an OS boot loader can provide a user interface to allow the selection of another UEFI application to run. Utilities like the UEFI Shell are also UEFI applications.
Protocols[change | change source]
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.
Graphics features[change | change source]
UEFI 2.1 defined a "Human Interface Infrastructure" (HII) to manage user input, localized strings, fonts, and forms (in the HTML sense). These enable original equipment manufacturers (OEMs) or independent BIOS vendors (IBVs) to design graphical interfaces for pre-boot configuration.
Most early UEFI firmware implementations were console-based. Today many UEFI firmware implementations are GUI-based.
Boot stages[change | change source]
SEC – Security Phase[change | change source]
This is the first stage of the UEFI boot but may have platform specific code. It is built as code written in assembly language for the specific architecture. It initializes temporary memory (often CPU cache as RAM) and serves as the system's software root of trust.
PEI – Pre-EFI Initialization[change | change source]
The second stage of UEFI contains of a dependency-aware dispatcher that loads and runs PEI modules (PEIMs) to handle hardware tasks such as main memory initialization and firmware recovery operations. It's also responsible for the discovery of the boot mode and handling many ACPI S0ix/ACPI S3 operations. In the case of ACPI S0ix/ACPI S3 resume, it is responsible for restoring many hardware registers to a pre-sleep state. PEI also uses CPU cache as RAM.
DXE – Driver Execution Environment[change | change source]
This stage are made of C modules and a dependency-aware dispatcher. With main memory now available, CPU, chipset, mainboard and boot devices are initialized in DXE and BDS.
BDS – Boot Device Select[change | change source]
BDS is a part of the DXE. In this stage, boot devices are initialized, UEFI drivers or Option ROMs of PCI devices are executed according to system configuration, and boot options are processed.
TSL – Transient System Load[change | change source]
This is the stage between boot device selection and hand-off to the OS. At this point one may enter UEFI shell, or execute an UEFI application such as the OS boot loader.
RT – Runtime[change | change source]
The UEFI hands off to the operating system (OS) after ExitBootServices() is executed. A UEFI compatible OS is now responsible for exiting boot services triggering the firmware to unload all no longer needed code and data, leaving only runtime services code/data, e.g. SMM and ACPI. A typical modern OS will prefer to use its own programs (such as kernel drivers) to control hardware devices.
When a legacy OS is used, CSM will handle this call making sure that the system is compatible with legacy BIOS expectations.
Criticism[change | change source]
Many digital rights activists have protested against UEFI. Some experts have blamed UEFI as an attempt to remove the ability of the user to control the computer. 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.
Open-source project TianoCore also provides UEFI interfaces. TianoCore doesn't have the specialized drivers that initialize functions, which are instead provided by coreboot, of which TianoCore is one of many payload options. The development of coreboot requires cooperation from CPU manufacturers to provide the specifications needed to develop initialization drivers.
Secure Boot[change | change source]
In 2011, Microsoft announced that computers certified to run its Windows 8 operating system had to release with Microsoft's public key enrolled and Secure Boot enabled.[source?] Following the announcement, Microsoft 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 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 lock-in. They also clarified its requirements by stating that 32-bit-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. Windows 10 allows OEMs to decide whether or not Secure Boot can be changed by users of their 32-bit systems.
Concerns[change | change source]
Other developers concerned about the 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 may prevent the use of the 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), and that it would also be difficult for advanced users to build custom kernels that could function with Secure Boot enabled without self-signing them. 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.
Other implementations[change | change source]
Several major Linux distributions have made different implementations for Secure Boot. Garrett himself made a minimal bootloader that allows the user to individually trust keys provided by Linux distributions. Ubuntu 12.10 uses an older version of shim[which?] pre-configured for use with 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 modules as well, without the need to reconfigure the system. Canonical also maintains its own private key to sign installations of Ubuntu pre-loaded on certified OEM computers that run the operating system, and also plans to enforce a Secure Boot requirement as well—requiring both a Canonical key and a Microsoft key (for compatibility reasons) to be included in their firmware. Fedora also uses shim,[which?] but requires that both the kernel and its modules be signed as well.
Disputes[change | change source]
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. In Windows, only the WHQL kernel driver is allowed if Secure Boot is enabled. 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 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.
On 26 March 2013, the Spanish free software development group Hispalinux filed a formal complaint with the European Commission．It said that Microsoft's Secure Boot requirements on OEM systems were "obstructive" and anti-competitive.
Reports[change | change source]
In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems. Technically, no key was exposed. However, an exploitable binary signed by the key was exposed. 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 problem 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.[source?]
Support[change | change source]
Firmware problems[change | change source]
The increased prominence of UEFI firmware in devices has also led to a number of technical problems blamed on their respective implementations.
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. Other problems were encountered by several Toshiba laptop models with Secure Boot that were missing certain certificates required for its proper operation.
In January 2013, a bug surrounding the UEFI implementation on some Samsung laptops went public, which caused them to be bricked after installing Linux 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, triggering the bug.
Notes[change | change source]
References[change | change source]
- Pronounced as an acronym or as //.
- Kinney, Michael (1 September 2000). "Solving BIOS Boot Issues with EFI" (PDF). pp. 47–50. Archived from the original (PDF) on 23 January 2007. Retrieved 14 September 2010.
- "MS denies secure boot will exclude Linux". The Register. 23 September 2011. Retrieved 24 September 2011.
- "The 30-year-long Reign of BIOS is Over: Why UEFI W... - Input Output". HP.com. Archived from the original on 26 June 2013. Retrieved 6 March 2012.
- IBM PC Real Time Clock should run in UT. Cl.cam.ac.uk. Retrieved on 30 October 2013.
- Garrett, Matthew (19 January 2012). "EFI and Linux: The Future Is Here, and It's Awful". linux.conf.au 2012. Archived from the original on 13 November 2021. Retrieved 2 April 2012.
- "Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems" (PDF). Emulex. Retrieved 14 September 2010.
- Extensible Firmware Interface (EFI) and Unified EFI (UEFI), Intel, archived from the original on 5 January 2010
- Wei, Dong (2006), "foreword", Beyond BIOS, Intel Press, ISBN 978-0-9743649-0-2
- "1.10 Specification overview", Extensible Firmware Interface, Intel
- About, Unified EFI Forum,
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
- "Unified Extensible Firmware Interface (UEFI) Specification Version 2.9" (PDF). www.uefi.org. March 2021. Retrieved 23 May 2021.
- "GitHub - tianocore/Edk: Git mirror of EDK". GitHub. 19 March 2019.
- "GitHub - tianocore/Tianocore.github.io: Tianocore website". GitHub. 8 August 2019.
- "What is TianoCore?".
- "UEFI and Windows". Microsoft. 15 September 2009. Retrieved 14 September 2010.
- "Installation". 3.4 BIOS installation. GNU GRUB. Retrieved 25 September 2013.
- "Non-boot disks can use a GPT partition table even with no UEFI bios".
- "What is efifb? — The Linux Kernel documentation". www.kernel.org. Retrieved 24 November 2020.
- "Samsung UEFI bug: Notebook bricked from Windows". The H. Retrieved 27 February 2013.
- UEFI specification, section 7.3
- "Intel Embedded Graphics Drivers FAQ: BIOS and firmware". Intel. Retrieved 19 May 2014.
- "PI Boot Flow · tianocore/Tianocore.github.io Wiki". GitHub.
- "Engineering Services" (PDF).
- "The Unified Extensible Firmware Interface (UEFI) — The Linux Kernel documentation". www.kernel.org. Retrieved 7 November 2020.
- "Interview: Ronald G Minnich". Fosdem. 6 February 2007. Retrieved 14 September 2010.
- Doctorow, Cory (27 December 2011), The Coming War on General Purpose Computation, retrieved 25 September 2013
- "coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware". YouTube. 31 October 2008. Retrieved 14 September 2010.
- "Welcome", TianoCore, SourceForge, archived from the original on 23 April 2012
- "Windows 8 Secure Boot: The Controversy Continues". PC World. Retrieved 9 September 2012.
- "Is Microsoft Blocking Linux Booting on ARM Hardware?". Computerworld UK. Retrieved 6 March 2012.
- "Windows 10 to make the Secure Boot alt-OS lock out a reality". Ars Technica. Retrieved 21 March 2015.
- "Free Software Foundation recommendations for free operating system distributions considering Secure Boot — Free Software Foundation — working together for free software". Free Software Foundation. Retrieved 18 March 2020.
- "Ubuntu will use GRUB 2 for its Secure Boot implementation". The H Online. Retrieved 28 October 2012.
- "Shimming your way to Linux on Windows 8 PCs". ZDNet. Retrieved 26 February 2013.
- "Ubuntu details its UEFI Secure Boot plans". Linux Weekly News. Retrieved 11 September 2012.
- "No Microsoft certificate support in Linux kernel says Torvalds". The H. Retrieved 26 February 2013.
- "Linus Torvalds: I will not change Linux to "deep-throat Microsoft"". Ars Technica. Retrieved 26 February 2013.
- "Exclusive: Open software group files complaint against Microsoft to EU". Reuters. 26 March 2013. Retrieved 26 March 2013.
- "Researchers demo exploits that bypass Windows 8 Secure Boot". IT World. Retrieved 5 August 2013.
- MENDELSOHN, Tom (12 August 2016). "Secure Boot snafu: Microsoft leaks backdoor key, firmware flung wide open [Updated]". Ars Technica. Retrieved 12 August 2016.
- "HowTos/UEFI - CentOS Wiki". wiki.centos.org. Retrieved 10 November 2020.
- "SecureBoot - Debian Wiki". wiki.debian.org. Retrieved 10 November 2020.
- "SUSE Linux Enterprise Server 15 SP1: Chapter 13. UEFI (Unified Extensible Firmware Interface) (Administration Guide)". documentation.suse.com. Retrieved 10 November 2020.
- "Linux on Windows 8 PCs: Some progress, but still a nuisance". ZDNet. Retrieved 26 February 2013.
- "Lenovo UEFI Only Wants To Boot Windows, RHEL". Phoronix. Retrieved 26 February 2013.
- "Linux acquitted in Samsung laptop UEFI deaths". Bit-tech. Retrieved 26 February 2013.
- "Booting Linux using UEFI can brick Samsung laptops". The H. Retrieved 26 February 2013.
Further reading[change | change source]
- Zimmer, Vincent; Rothman, Michael; Hale, Robert (10 May 2007). "EFI Architecture". Dr. Dobb's Journal. UBM. Retrieved 12 October 2012.
- de Boyne Pollard, Jonathan (11 July 2011). "The EFI boot process". Frequently Given Answers. Retrieved 12 October 2012.
- de Boyne Pollard, Jonathan (8 December 2011). "The Windows NT 6 boot process". Frequently Given Answers. Retrieved 12 October 2012.
- Smith, Roderick W. (2011). "A BIOS to UEFI Transformation". Roderick W. Smith's Web Page. Retrieved 12 October 2012.
- Kothari, Rajiv (21 September 2011). "UEFI – Just How Important It Really Is". Hardware Secrets. Archived from the original on 25 October 2012. Retrieved 12 October 2012.
- Fisher, Doug (2011). "UEFI Today: Bootstrapping the Continuum". Intel Technology Journal. Intel. 15 (1). ISBN 9781934053430. Archived from the original on 27 September 2013. Retrieved 24 September 2013.
Other websites[change | change source]
|Wikimedia Commons has media related to Extensible Firmware Interface.|
- Official website
- UEFI Specifications
- Intel-sponsored open-source EFI Framework initiative
- Intel EFI/UEFI portal
- Microsoft UEFI Support and Requirements for Windows Operating Systems
- How Windows 8 Hybrid Shutdown / Fast Boot feature works
- Securing the Windows 10 Boot Process
- LoJax: First UEFI rootkit found in the wild, courtesy of the Sednit group