Unified Extensible Firmware Interface
AbbreviationUEFI
StatusPublished
Year started2006[a]
Latest version2.10
August 29, 2022
OrganizationUEFI Forum
Related standardsACPI, UEFI Platform Initialization
PredecessorBIOS
DomainFirmware
Websiteuefi.org
Boot order selection menu on a Lenovo ThinkPad T470 with UEFI
The UEFI implementation is usually stored on a NOR-based EEPROM that is located on the mainboard. They can use different I/O protocols, but SPI is the most common.

Unified Extensible Firmware Interface (UEFI, /ˈjuːɪfaɪ/ or as an acronym)[b] is a specification that defines the architecture of the platform firmware used for booting the computer hardware and its interface for interaction with the operating system. Examples of firmware that implement the specification are AMI Aptio, Phoenix SecureCore, TianoCore EDK II, InsydeH2O. UEFI replaces the BIOS which was present in the boot ROM of all personal computers that are IBM PC compatible,[1][2] although it can provide backwards compatibility with the BIOS using CSM booting. Intel developed the original Extensible Firmware Interface (EFI) specification. Some of the EFI's practices and data formats mirror those of Microsoft Windows.[3][4] In 2005, UEFI deprecated EFI 1.10 (the final release of EFI).

UEFI is independent of platform and programming language, but C is used for the reference implementation TianoCore EDKII.

Contrary to 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.

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 MB addressable memory space,[5] assembly language programming, and PC AT hardware) had become too restrictive for the larger server platforms Itanium was targeting.[6] The effort to address these concerns began in 1998 and was initially called Intel Boot Initiative.[7] It was later renamed to Extensible Firmware Interface (EFI).[8][9]

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

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.[6][13]

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 Arm ServerReady, a compliance certification program for landing the generic off-the-shelf operating systems and hypervisors on Arm-based servers. The program requires the system firmware to comply with Server Base Boot Requirements (SBBR). SBBR requires UEFI, ACPI and SMBIOS compliance. In October 2020, Arm announced the extension of the program to the edge and IoT market. The new program name is Arm SystemReady. Arm SystemReady defined the Base Boot Requirements (BBR) specification that currently provides three recipes, two of which are related to UEFI: 1) SBBR: which requires UEFI, ACPI and SMBIOS compliance suitable for enterprise level operating environments such as Windows, Red Hat Enterprise Linux, and VMware ESXi; and 2) EBBR: which requires compliance to a set of UEFI interfaces as defined in the Embedded Base Boot Requirements (EBBR) suitable for embedded environments such as Yocto. Many Linux and BSD distros can support both recipes.

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

The latest UEFI specification, version 2.10, was published in August 2022.[15]

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:[16]

Compatibility

Processor compatibility

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

Standard PC BIOS is limited to a 16-bit processor mode and 1 MB of addressable memory space, resulting from the design based on the IBM 5150 that used a 16-bit Intel 8088 processor.[6][26] 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).[6][27] 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.[28]

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).[29]: sections 2.3.2 and 2.3.4  As of version 3.15, the Linux kernel supports 64-bit kernels to be booted on 32-bit UEFI firmware implementations running on x86-64 CPUs, with UEFI handover support from a UEFI boot loader as the requirement.[30] UEFI handover protocol deduplicates the UEFI initialization code between the kernel and UEFI boot loaders, leaving the initialization to be performed only by the Linux kernel's UEFI boot stub.[31][32]

Disk device compatibility

See also: GPT § Operating systems support, and Protective MBR

In addition to the standard PC disk partition scheme that uses a master boot record (MBR), UEFI also works with the GUID Partition Table (GPT) partitioning scheme, which is free from many of the limitations of MBR. In particular, the MBR limits on the number and size of disk partitions (up to four primary partitions per disk, and up to 2 TB (2 × 240 bytes) per disk) are relaxed.[33] More specifically, GPT allows for a maximum disk and partition size of 8 ZiB (8 × 270 bytes).[34][35]

Linux

See also: EFI System partition § Linux

Support for GPT in Linux is enabled by turning on the option CONFIG_EFI_PARTITION (EFI GUID Partition Support) during kernel configuration.[36] 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.[37][unreliable source?] As GPT incorporates the protective MBR, a BIOS-based computer can boot from a GPT disk using a GPT-aware boot loader stored in the protective MBR's bootstrap code area.[35] In the case of GRUB, such a configuration requires a BIOS boot partition for GRUB to embed its second-stage code due to absence of the post-MBR gap in GPT partitioned disks (which is taken over by the GPT's Primary Header and Primary Partition Table). Commonly 1 MB in size, this partition's Globally Unique Identifier (GUID) in GPT scheme is 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.[17][35][37]

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.[38][39][40][unreliable source?] Such a setup is usually referred to as UEFI-GPT, while ESP is recommended to be at least 512 MB in size and formatted with a FAT32 filesystem for maximum compatibility.[35][37][41][unreliable source?]

For backward compatibility, some UEFI implementations also support booting from MBR-partitioned disks through the Compatibility Support Module (CSM) that provides legacy BIOS compatibility.[42] In that case, booting Linux on UEFI systems is the same as on legacy BIOS-based systems.

Microsoft Windows

The 64-bit versions of Windows Vista SP1 and later and 64-bit versions of Windows 8, 8.1, and 10 can boot from a GPT disk that is larger than 2 TB.

Features

Services

Example of UEFI variables

EFI defines two types of services: boot services and runtime services. Boot services are available only while the firmware owns the platform (i.e., before the ExitBootServices() call), and they include text and graphical consoles on various devices, and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access.

Graphics Output Protocol (GOP) services
The Graphics Output Protocol (GOP) provides runtime services; see also Graphics features section below. The operating system is permitted to directly write to the framebuffer provided by GOP during runtime mode.[43]
UEFI Memory map services
SMM services
ACPI services
SMBIOS services
Devicetree services (for RISC processors)
Variable services
UEFI variables provide a way to store data, in particular non-volatile data. Some UEFI variables are shared between platform firmware and operating systems. Variable namespaces are identified by GUIDs, and variables are key/value pairs. For example, UEFI variables can be used to keep crash messages in NVRAM after a crash for the operating system to retrieve after a reboot.[44]
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.[45] 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,[4] unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC.

Applications

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, or by other UEFI applications. UEFI applications can be developed and installed independently of the original equipment manufacturers (OEMs).

A type of UEFI application is an OS boot loader such as GRUB, rEFInd, Gummiboot, and Windows Boot Manager, which loads some OS files into memory and executes them. Also, an OS boot loader can provide a user interface to allow the selection of another UEFI application to run. Utilities like the UEFI Shell are also UEFI applications.

Protocols

EFI defines protocols as a set of software interfaces used for communication between two binary modules. All EFI drivers must provide services to others via protocols. The EFI Protocols are similar to the BIOS interrupt calls.

Device drivers

In addition to standard instruction set architecture-specific device drivers, EFI provides for a ISA-independent device driver stored in non-volatile memory as EFI byte code or EBC. System firmware has an interpreter for EBC images. In that sense, EBC is analogous to Open Firmware, the ISA-independent firmware used in PowerPC-based Apple Macintosh and Sun Microsystems SPARC computers, among others.

Some architecture-specific (non-EFI Byte Code) EFI drivers for some device types can have interfaces for use by the OS. This allows the OS to rely on EFI for drivers to perform basic graphics and network functions before, and if, operating-system-specific drivers are loaded.

In other cases, the EFI driver can be filesystem drivers that allow for booting from other types of disk volumes. Examples include efifs for 37 file systems (based on GRUB2 code),[46] used by Rufus for chain-loading NTFS ESPs.[47]

Graphics features

The EFI 1.0 specification defined a UGA (Universal Graphic Adapter) protocol as a way to support graphics features. UEFI did not include UGA and replaced it with GOP (Graphics Output Protocol).[48]

UEFI 2.1 defined a "Human Interface Infrastructure" (HII) to manage user input, localized strings, fonts, and forms (in the HTML sense). These enable original equipment manufacturers (OEMs) or independent BIOS vendors (IBVs) to design graphical interfaces for pre-boot configuration. UEFI uses UTF-16 to encode strings by default.

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

EFI system partition

Main article: EFI system partition

An EFI system partition, often abbreviated to ESP, is a data storage device partition that is used in computers adhering to the UEFI specification. Accessed by the UEFI firmware when a computer is powered up, it stores UEFI applications and the files these applications need to run, including operating system boot loaders. Supported partition table schemes include MBR and GPT, as well as El Torito volumes on optical discs.[29]: 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.[29]: section 12.3 [49][50][51] The ESP also provides space for a boot sector as part of the backward BIOS compatibility.[42]

Booting

UEFI booting

Unlike the legacy PC BIOS, UEFI does not rely on boot sectors, defining instead a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager checks the boot configuration and, based on its settings, then executes the specified OS boot loader or operating system kernel (usually boot loader[52]). 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 drives. This automated detection relies on standardized file paths to the OS boot loader, with the path varying depending on the computer architecture. The format of the file path is defined as <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOT<MACHINE_TYPE_SHORT_NAME>.EFI; for example, the file path to the OS loader on an x86-64 system is \efi\boot\bootx64.efi,[29] and \efi\boot\bootaa64.efi on ARM64 architecture.

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,[29] 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.[42] 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.

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.[42]

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 ROMs that do not support UEFI to still be used.[53] It also provides required legacy System Management Mode (SMM) functionality, called CompatibilitySmm, as an addition to features provided by the UEFI SMM. An example of such a legacy SMM functionality is providing USB legacy support for keyboard and mouse, by emulating their classic PS/2 counterparts.[53]

In November 2017, Intel announced that it planned to phase out support CSM for client platforms by 2020.[54]

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.[55]

In August 2023, Intel announced that it planned to phase out support CSM for server platforms by 2024.[56]

Network booting

The UEFI specification includes support for booting over network via the Preboot eXecution Environment (PXE). PXE booting network protocols include Internet Protocol (IPv4 and IPv6), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) and iSCSI.[29][57]

OS images can be remotely stored on storage area networks (SANs), with Internet Small Computer System Interface (iSCSI) and Fibre Channel over Ethernet (FCoE) as supported protocols for accessing the SANs.[29][58][59]

Version 2.5 of the UEFI specification adds support for accessing boot images over the HTTP.[60]

Secure Boot

See also: Secure Boot criticism
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 signed with an acceptable digital signature. The mechanical details of how precisely these drivers are to be signed are not specified.[61] 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.[62] 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.[63]

Secure Boot is supported by Windows 8 and 8.1, Windows Server 2012 and 2012 R2, Windows 10, Windows Server 2016, 2019, and 2022, and Windows 11, VMware vSphere 6.5[64] and a number of Linux distributions including Fedora (since version 18), openSUSE (since version 12.3), RHEL (since version 7), CentOS (since version 7[65]), Debian (since version 10),[66] Ubuntu (since version 12.04.2), Linux Mint (since version 21.3).[67][68], and AlmaLinux OS (since version 8.4[69]). As of January 2024, FreeBSD support is in a planning stage.[70]

UEFI shell

Example of an UEFI shell 2.2 session

UEFI provides a shell environment, which can be used to execute other UEFI applications, including UEFI boot loaders.[40] Apart from that, commands available in the UEFI shell can be used for obtaining various other information about the system or the firmware, including getting the memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading UEFI drivers, and editing text files (edit).[71][unreliable source?][72][73]

Source code for a UEFI shell can be downloaded from the Intel's TianoCore UDK/EDK2 project.[74] A pre-built ShellBinPkg is also available.[75] 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.[71][76][77]

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 <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Some other systems have an already embedded UEFI shell which can be launched by appropriate key press combinations.[78][unreliable source?][79] For other systems, the solution is either creating an appropriate USB flash drive or adding manually (bcfg) a boot option associated with the compiled version of shell.[73][78][80][unreliable source?][81][unreliable source?]

Commands

The following is a list of commands supported by the EFI shell.[72]

Extensions

Extensions to UEFI can be loaded from virtually any 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 ROM.

UEFI Capsule

UEFI Capsule defines a Firmware-to-OS firmware update interface, marketed as modern and secure.[82] Windows 8, Windows 8.1, Windows 10,[83] 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), and then loads the boot loader from a mass storage device or through a network connection. In x86 systems, the UEFI firmware is usually stored in the NOR flash chip of the motherboard.[84]

Classes

UEFI machines can have one of the following classes, which were used to help ease the transition to UEFI:[85]

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]

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, or SoC on-chip SRAM, CAR) and serves as the system's software root of trust with the option of verifying PEI before hand-off.

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

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.

BDS – Boot Device Select

BDS is a part of the DXE.[87][88] 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

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

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.[89] 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 ensuring the system is compatible with legacy BIOS expectations.

Usage

Implementations

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.[90]

Phoenix Technologies' implementation of UEFI is branded as SecureCore Technology (SCT).[91] American Megatrends offers its own UEFI firmware implementation known as Aptio,[92] while Insyde Software offers InsydeH2O,[93] and Byosoft offers ByoCore.

In December 2018, Microsoft released an open source version of its TianoCore EDK2-based UEFI implementation from the Surface line, Project Mu.[94]

An implementation of the UEFI API was introduced into the Universal Boot Loader (Das U-Boot) in 2017.[95] On the ARMv8 architecture Linux distributions use the U-Boot UEFI implementation in conjunction with GNU GRUB for booting (e.g. SUSE Linux[96]), the same holds true for OpenBSD.[97] For booting from iSCSI iPXE can be used as a UEFI application loaded by U-Boot.[98]

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 Windows, Linux, FreeBSD and HP-UX; OpenVMS added UEFI capability in June 2003.

In January 2006, Apple Inc. shipped its first Intel-based Macintosh computers. These systems used EFI instead of Open Firmware, which had been used on its previous PowerPC-based systems.[99] On 5 April 2006, Apple first released 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.[100]

During 2005, more than one million Intel systems shipped with Intel's implementation of UEFI.[101][failed verification] New mobile, desktop and server products, using Intel's implementation of UEFI, started shipping in 2006. For instance, boards that use the Intel 945 chipset series use Intel's UEFI firmware implementation.

Since 2005, EFI has also been implemented on non-PC architectures, such as embedded systems based on XScale cores.[101]

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

In 2009, IBM shipped System x machines (x3550 M2, x3650 M2, iDataPlex dx360 M2) and 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.[102]

In 2011, major vendors (such as ASRock, Asus, Gigabyte, and MSI) launched several consumer-oriented motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series AM3+ chipsets with UEFI.[103]

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 smartphones, 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.[104][105]

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.[106] 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 <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI, where short name of the machine type can be IA32, X64, IA64, ARM or AA64.[29] Some operating systems vendors may have their own boot loaders. They may also change the default boot location.

With virtualization

Applications development

EDK2 Application Development Kit (EADK) makes it possible to use 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 interpreter is made available as a UEFI application by using the EADK.[143] The development has moved to GitHub since UDK2015.[144]

A minimalistic "hello, world" C program written using EADK looks similar to its usual C counterpart: 

#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;
}

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.[145][146] 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.[147]

Open-source project TianoCore also provides UEFIs.[148] TianoCore lacks the specialized drivers that initialize chipset functions, which are instead provided by coreboot, of which TianoCore is one of many payload options. The development of coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.

Secure Boot

See also: Windows 8 § Reception
Examples of custom Secure Boot public keys
MokManager, a part of Shim bootloader

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. 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 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 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.[63][149] Windows 10 allows OEMs to decide whether or not Secure Boot can be managed by users of their x86 systems.[150]

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 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),[151][109] 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.[149] 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.[2]

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.[152] 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.[109][153][154] 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.[153]

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.[154] 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 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.[155]

On 26 March 2013, the 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.[156]

At the 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.[157]

In August 2016 it was reported that two security researchers had found the "golden key" security key Microsoft uses in signing operating systems.[158] 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]

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”.[159][160]

Many Linux distributions support UEFI Secure Boot now, such as RHEL (RHEL 7 and later), CentOS (CentOS 7 and later[161]), Ubuntu, Fedora, Debian (Debian 10 and later[162]), OpenSUSE, SUSE Linux.[163]

Firmware problems

The increased prominence of UEFI firmware in devices has also led to a number of technical problems blamed on their respective implementations.[164]

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.[165] Other problems were encountered by several Toshiba laptop models with Secure Boot that were missing certain certificates required for its proper operation.[164]

In January 2013, a bug surrounding the UEFI implementation on some Samsung laptops was publicized, which caused them to be 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.[44][166][167]

See also

Notes

  1. ^ Originally started in 1998 as Intel Boot Initiative and later as Extensible Firmware Interface (EFI), which was deprecated in 2005 and replaced by UEFI.
  2. ^ Historically also written as Unified EFI, when UEFI was the newly introduced successor to EFI.
  3. ^ Large disk support and features such as Advanced Configuration and Power Interface (ACPI) and System Management BIOS (SMBIOS) were subsequently implemented in BIOS-based systems.

References

  1. ^ 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.
  2. ^ a b "MS denies secure boot will exclude Linux". The Register. 23 September 2011. Retrieved 24 September 2011.
  3. ^ IBM PC Real Time Clock should run in UT. Cl.cam.ac.uk. Retrieved on 30 October 2013.
  4. ^ a b 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.
  5. ^ "Memory Map (x86) - OSDev Wiki". wiki.osdev.org. Retrieved 11 December 2020.
  6. ^ a b c d "Emulex UEFI Implementation Delivers Industry-leading Features for IBM Systems" (PDF). Emulex. Retrieved 14 September 2010.
  7. ^ Extensible Firmware Interface (EFI) and Unified EFI (UEFI), Intel, archived from the original on 5 January 2010
  8. ^ Wei, Dong (2006), "foreword", Beyond BIOS, Intel Press, ISBN 978-0-9743649-0-2
  9. ^ "1.10 Specification overview", Extensible Firmware Interface, Intel
  10. ^ "GitHub - tianocore/Edk: Git mirror of EDK". GitHub. 19 March 2019.
  11. ^ "GitHub - tianocore/Tianocore.github.io: Tianocore website". GitHub. 8 August 2019.
  12. ^ "What is TianoCore?".
  13. ^ 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
  14. ^ "Microsoft announces Project Mu, an open-source release of the UEFI core". 20 December 2018.
  15. ^ "Unified Extensible Firmware Interface (UEFI) Specification Version 2.10" (PDF). www.uefi.org. August 2022. Retrieved 16 January 2023.
  16. ^ "UEFI and Windows". Microsoft. 15 September 2009. Retrieved 14 September 2010.
  17. ^ a b c "Installation". 3.4 BIOS installation. GNU GRUB. Retrieved 25 September 2013.
  18. ^ "Non-boot disks can use a GPT partition table even with no UEFI bios".
  19. ^ UEFI Specification 2.4, section 2.3
  20. ^ UEFI specification 2.3.1, section 1.8.1.
  21. ^ "GitHub - andreiw/ppc64le-edk2: TianoCore UEFI for OPAL/PowerNV (PPC64/PowerPC64 Little-Endian)". GitHub. 3 May 2021.
  22. ^ "Tianocore for OpenPOWER". Firmware Security. 12 October 2015.
  23. ^ kontais (3 September 2015). "EFI-MIPS". SourceForge.
  24. ^ "lowRISC · lowRISC".
  25. ^ "Unified Extensible Firmware Interface Specification, Version 2.7" (PDF). May 2017.
  26. ^ Hardwidge, Ben (1 June 2010). "LBA explained — Solving the 3TB Problem?". bit-tech. Retrieved 18 June 2010.
  27. ^ Richardson, Brian (10 May 2010). "Ask a BIOS Guy: "Why UEFI"". Intel Architecture Blog. Archived from the original on 9 October 2010. Retrieved 18 June 2010.
  28. ^ Simpson, Gary. "UEFI Momentum — The AMD perspective". AMD. Archived from the original (PPTX) on 4 January 2014. Retrieved 20 September 2014.
  29. ^ a b c d e f g h "UEFI Specifications (version 2.4 and older)" (PDF). Unified EFI, Inc. June 2013. Retrieved 25 September 2013.
  30. ^ "Linux kernel 3.15, Section 1.3. EFI 64-bit kernels can be booted from 32-bit firmware". kernelnewbies.org. 8 June 2014. Retrieved 15 June 2014.
  31. ^ "x86, efi: Handover Protocol". LWN.net. 19 July 2012. Retrieved 15 June 2014.
  32. ^ "Linux kernel documentation: Documentation/efi-stub.txt". kernel.org. 1 February 2014. Retrieved 15 June 2014.
  33. ^ "FAQ: Drive Partition Limits" (PDF). UEFI Forum. Retrieved 5 December 2019.
  34. ^ "FAQ: Drive Partition Limits" (PDF). UEFI Forum. Archived from the original (PDF) on 22 March 2013. Retrieved 9 June 2010.
  35. ^ a b c d Smith, Roderick W. (3 July 2012). "Make the most of large drives with GPT and Linux". IBM. Retrieved 25 September 2013.
  36. ^ "block/partitions/Kconfig (3.11.1)". CONFIG_EFI_PARTITION (line #247). kernel.org. Retrieved 25 September 2013.
  37. ^ a b c "GRUB". BIOS systems. Arch Linux. Retrieved 25 September 2013.
  38. ^ "GRUB and the boot process on UEFI-based x86 systems". redhat.com. Retrieved 14 November 2013.
  39. ^ "UEFI Booting 64-bit Redhat Enterprise Linux 6". fpmurphy.com. September 2010. Retrieved 14 November 2013.
  40. ^ a b "UEFI Bootloaders". archlinux.org. Retrieved 25 September 2013.
  41. ^ "Unified Extensible Firmware Interface: EFI System Partition". archlinux.org. Retrieved 25 September 2013.
  42. ^ a b c d "UEFI system booting from MBR partition table and GRUB legacy". Arch Linux Forums. June 2012. Archived from the original on 8 December 2023. Retrieved 6 October 2013.
  43. ^ "What is efifb? — The Linux Kernel documentation". www.kernel.org. Retrieved 24 November 2020.
  44. ^ a b "Samsung UEFI bug: Notebook bricked from Windows". The H. Retrieved 27 February 2013.
  45. ^ UEFI specification, section 7.3
  46. ^ "Free Software EFI Drivers".
  47. ^ Batard, Pete (13 March 2020). "pbatard/uefi-ntfs". GitHub.
  48. ^ "Intel Embedded Graphics Drivers FAQ: BIOS and firmware". Intel. Retrieved 19 May 2014.
  49. ^ "UEFI Specification Version 2.5, Section 12.3 File System Format" (PDF). uefi.org. April 2015. pp. 536, 537. Retrieved 29 May 2015. 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.
  50. ^ "Technical Note TN2166: Secrets of the GPT". developer.apple.com. 6 November 2006. Retrieved 6 May 2015.
  51. ^ "UEFI - OSDev Wiki". wiki.osdev.org. Retrieved 26 September 2020.
  52. ^ "EFISTUB - ArchWiki". wiki.archlinux.org. Retrieved 27 October 2020.
  53. ^ a b "Intel® Platform Innovation Framework for EFI" (PDF). Compatibility Support Module Specification (revision 0.97). Intel. 4 September 2007. Retrieved 6 October 2013.
  54. ^ "The PC BIOS will be killed off by 2020 as Intel plans move to pure UEFI". Ars Technica. Retrieved 29 May 2018.
  55. ^ "CosmicStrand: the discovery of a sophisticated UEFI firmware rootkit". Securelist by Kaspersky. Retrieved 4 August 2022.
  56. ^ "Removal of Legacy Boot Support for Intel Platforms Technical Advisory".
  57. ^ "Red Hat Enterprise Linux 6 Installation Guide". 30.2.2. Configuring PXE boot for EFI. Red Hat. Retrieved 9 October 2013.
  58. ^ El-Haj-Mahmoud, Samer (July 2013). "Advances in Pre-OS Networking in UEFI 2.4" (PDF). Hewlett-Packard. Retrieved 29 May 2019.
  59. ^ Racherla, Sangam; Erdenberger, Silvio; Rajagopal, Harish; Ruth, Kai (January 2014). Storage and Network Convergence Using FCoE and iSCSI (PDF) (2nd ed.). IBM Redbooks. Retrieved 20 April 2022.
  60. ^ "New UEFI HTTP Boot support in UEFI 2.5". firmwaresecurity.com. 9 May 2015. Retrieved 13 August 2015.
  61. ^ "Secure Boot Overview". Microsoft. 10 December 2014. Retrieved 18 February 2016.
  62. ^ Edge, Jake. "UEFI and "secure boot"". LWN.net. Retrieved 9 September 2012.
  63. ^ a b "Windows 8 Secure Boot: The Controversy Continues". PC World. Retrieved 9 September 2012.
  64. ^ "Secure Boot for ESXi 6.5 - Hypervisor Assurance". VMware vSphere Blog. 4 May 2017. Retrieved 18 August 2017.
  65. ^ HowTos/UEFI - CentOS Wiki
  66. ^ Larabel, Michael (30 April 2018). "Debian Making Progress on UEFI SecureBoot Support in 2018". Phoronix. Phoronix Media. Retrieved 23 May 2018.
  67. ^ Garrett, Matthew (27 December 2012). "Secure Boot distribution support". Mjg59.dreamwidth.org. Retrieved 20 March 2014.
  68. ^ "Linux Mint Secure boot". Linux Mint. Retrieved 12 January 2024.
  69. ^ "8.4 | AlmaLinux Wiki". wiki.almalinux.org. Retrieved 10 April 2024.
  70. ^ "SecureBoot". FreeBSD Wiki. FreeBSD. Retrieved 16 June 2015.
  71. ^ a b "Unified Extensible Firmware Interface". UEFI Shell. Arch Linux. Retrieved 25 September 2013.
  72. ^ a b "EFI Shells and Scripting". Intel. Retrieved 25 September 2013.
  73. ^ a b "UEFI Shell Specification Version 2.0, Errata A" (PDF). Unified EFI, Inc. May 2012. Retrieved 25 September 2013.
  74. ^ "EDK2: ShellPkg". GitHub. Retrieved 18 March 2020.
  75. ^ "tianocore/edk2: releases". GitHub.
  76. ^ "Email Archive: edk2-devel". [edk2] Inclusion of UEFI shell in Linux distro iso. SourceForge. 2012. Retrieved 25 September 2013.
  77. ^ "TianoCore on SourceForge". Shell FAQ. Intel. Retrieved 25 September 2013.
  78. ^ a b "Unified Extensible Firmware Interface". Launching UEFI Shell. Arch Linux. Retrieved 25 September 2013.
  79. ^ "Basic Instructions for Using EFI for Server Configuration on Intel® Server Boards and Intel® Server Systems" (PDF). Intel. 2008. Retrieved 25 September 2013.
  80. ^ "Unified Extensible Firmware Interface". bcfg. Arch Linux. Retrieved 25 September 2013.
  81. ^ "GRUB EFI Examples". Asus. Arch Linux. Retrieved 25 September 2013.
  82. ^ "Signed Capsule Update". tianocore-docs.github.io.
  83. ^ barrygolden. "Windows UEFI firmware update platform - Windows drivers". docs.microsoft.com. Retrieved 25 September 2020.
  84. ^ "Getting Started | Microchip Technology". www.microchip.com. Retrieved 24 December 2020.
  85. ^ Barry, Peter; Crowley, Patrick (2012). Modern embedded computing : designing connected, pervasive, media-rich systems. Waltham, MA: Morgan Kaufmann Publishers. p. 169. ISBN 978-0-12-394407-8. OCLC 810455404.
  86. ^ "Intel schrapt bios-compatibiliteit uefi in 2020". Tweakers (in Dutch). Retrieved 30 December 2022.
  87. ^ "PI Boot Flow · tianocore/Tianocore.github.io Wiki". GitHub.
  88. ^ "Engineering Services" (PDF).
  89. ^ "The Unified Extensible Firmware Interface (UEFI) — The Linux Kernel documentation". www.kernel.org. Archived from the original on 25 October 2020. Retrieved 7 November 2020.
  90. ^ "TianoCore - coreboot". Retrieved 25 May 2012.
  91. ^ "SecureCore Tiano™". Phoenix Technologies. Archived from the original on 6 September 2010. Retrieved 14 September 2010.
  92. ^ "Aptio®: The Complete UEFI Product Solution" (PDF). American Megatrends, Inc. Retrieved 2 May 2018.
  93. ^ "Why US?". Insyde Software Corp. Retrieved 2 May 2018.
  94. ^ "Microsoft Announces "Project Mu" For Open-Source UEFI Alternative To TianoCore". Phoronix. Retrieved 20 December 2018.
  95. ^ "Marrying U-Boot UEFI and GRUB" (PDF). Retrieved 12 September 2018.
  96. ^ "UEFI on Top of U-Boot" (PDF). Archived from the original (PDF) on 11 September 2018. Retrieved 12 September 2018.
  97. ^ "Installing OpenBSD 6.3 on Raspberry 3". Archived from the original on 21 November 2018. Retrieved 12 September 2018.
  98. ^ "iSCSI booting with U-Boot and iPXE". Archived from the original on 31 July 2020. Retrieved 18 May 2020.
  99. ^ Apple Computer. "Universal Binary Programming Guidelines, Second Edition: Extensible Firmware Interface (EFI) Archived 24 July 2008 at the Wayback Machine"
  100. ^ Apple's Transition from Open Firmware to Extensible Firmware Interface, mactech, 2007.
  101. ^ a b "Intel® Platform Innovation Framework for UEFI Overview". Intel. Retrieved 14 September 2010.
  102. ^ Evaluating UEFI using Commercially Available Platforms and Solutions (PDF), UEFI, May 2011, archived from the original (PDF) on 22 March 2012
  103. ^ Asus P67 Motherboard Preview.
  104. ^ "Windows Hardware Certification Requirements for Client and Server Systems". Microsoft. January 2013. 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.
  105. ^ "Microsoft: All You Need to Know About Windows 8 on ARM". PC Magazine. Archived from the original on 6 September 2013. Retrieved 30 September 2013.
  106. ^ Richardson, Brian (30 October 2017). ""Last Mile" Barriers to Removing Legacy BIOS" (PDF). Retrieved 22 November 2017.
  107. ^ Announcement of release 3.5pre1 by maintainer Brett Johnson made on 27 February 2004.
  108. ^ EFI version of Grub, Debian GNU/Linux, retrieved 1 May 2008
  109. ^ a b c "Ubuntu will use GRUB 2 for its Secure Boot implementation". The H Online. Retrieved 28 October 2012.
  110. ^ OpenVMS Release History, HP, archived from the original on 5 January 2009, retrieved 16 September 2008
  111. ^ "State of the Port to x86-64" (PDF). vmssoftware.com. 6 October 2017. Archived from the original (PDF) on 22 September 2020. Retrieved 9 September 2020.
  112. ^ rEFIt — Windows Vista and EFI, SourceForge, archived from the original on 5 September 2008, retrieved 31 May 2008
  113. ^ "Extensible Firmware Interface", Windows Server TechCenter, Microsoft, archived from the original on 30 August 2006
  114. ^ Unified Extensible Firmware Interface (UEFI) Implementation Guidelines
  115. ^ Ersek, Laszlo (January 2015). "Open Virtual Machine Firmware (OVMF) Status Report". Linux KVM Project. Retrieved 13 November 2022.
  116. ^ Boot to UEFI Mode or legacy BIOS mode
  117. ^ "Unified Extended Firmware Interface support in Windows Vista". Microsoft. 26 October 2006. Retrieved 12 June 2010. 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.
  118. ^ Microsoft Basic Display Driver
  119. ^ "Microsoft Touts Incredible Windows 8 Boot Times". Retrieved 9 September 2011.
  120. ^ Brodkin, Jon (21 September 2011). "Windows 8 secure boot could complicate Linux installs". Ars Technica. Retrieved 23 September 2011.
  121. ^ "Find Windows 11 specs, features, and computer requirements". Microsoft.
  122. ^ "FreeBSD to get UEFI support". The H. Retrieved 7 March 2013.
  123. ^ "UEFI - FreeBSD Wiki". FreeBSD.org. Retrieved 19 June 2014.
  124. ^ "uefi(8)". www.freebsd.org. Retrieved 11 January 2021.
  125. ^ "Oracle Solaris 11.1 — What's New" (PDF). oracle.com. Retrieved 4 November 2013.
  126. ^ "OpenBSD 5.9". www.openbsd.org. Retrieved 11 September 2016.
  127. ^ "OpenBSD 6.0". www.openbsd.org. Retrieved 11 September 2016.
  128. ^ Proven, Liam (4 September 2023). "ArcaOS 5.1 gives vintage OS/2 a UEFI facelift for the 21st century". The Register. Retrieved 4 September 2023.
  129. ^ "Booting ArcaOS on UEFI hardware (demonstration)". youtube.com. 8 August 2019. Retrieved 22 September 2020.
  130. ^ Sanders, James (13 August 2019). "Modern OS/2 distribution ArcaOS adds support for booting via UEFI". techrepublic.com. Archived from the original on 21 October 2019. Retrieved 4 September 2023.
  131. ^ Open Virtual Machine Firmware, SourceForge, archived from the original on 6 October 2011
  132. ^ "VMWare Workstation EFI firmware | VMware Communities". Communities.vmware.com. 3 October 2012. Retrieved 28 February 2014.
  133. ^ "Using EFI/UEFI firmware in a VMware Virtual Machine | VMware Communities". Communities.vmware.com. 6 December 2014. Retrieved 18 January 2016.
  134. ^ "Announcing VMware Workstation 14 - VMware Workstation Zealot". VMware Workstation Zealot. 22 August 2017. Retrieved 2 August 2018.
  135. ^ "What's New in vSphere 5.0". Vmware.com. Retrieved 28 February 2014.
  136. ^ "VMware vSphere 6.5 Release Notes". pubs.vmware.com. Retrieved 13 January 2017.
  137. ^ 3.1 Changelog, VirtualBox, archived from the original on 28 September 2010
  138. ^ Ticket 7702, VirtualBox
  139. ^ "Statement by sr. software engineer at Oracle", Forum, VirtualBox
  140. ^ "Testing secureboot with KVM". FedoraProject. Retrieved 28 February 2014.
  141. ^ "What's New in Hyper-V for Windows Server 2012 R2". MicrosoftTechNet. Retrieved 24 June 2013.
  142. ^ "Shielded VMs". Retrieved 16 February 2019.
  143. ^ "TianoCore on SourceForge: EDK2 Application Development Kit (EADK)". Intel. Retrieved 25 September 2013.
  144. ^ "Tianocore: UDK". GitHub.
  145. ^ "Interview: Ronald G Minnich". Fosdem. 6 February 2007. Retrieved 14 September 2010.
  146. ^ Doctorow, Cory (27 December 2011), The Coming War on General Purpose Computation, retrieved 25 September 2013
  147. ^ "coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware". YouTube. 31 October 2008. Retrieved 14 September 2010.
  148. ^ "Welcome", TianoCore, SourceForge, archived from the original on 23 April 2012
  149. ^ a b "Is Microsoft Blocking Linux Booting on ARM Hardware?". Computerworld UK. Retrieved 6 March 2012.
  150. ^ "Windows 10 to make the Secure Boot alt-OS lock out a reality". Ars Technica. 20 March 2015. Retrieved 21 March 2015.
  151. ^ "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.
  152. ^ "Shimming your way to Linux on Windows 8 PCs". ZDNet. Retrieved 26 February 2013.
  153. ^ a b "Ubuntu details its UEFI Secure Boot plans". Linux Weekly News. Retrieved 11 September 2012.
  154. ^ a b "No Microsoft certificate support in Linux kernel says Torvalds". The H. Retrieved 26 February 2013.
  155. ^ "Linus Torvalds: I will not change Linux to "deep-throat Microsoft"". Ars Technica. 26 February 2013. Retrieved 26 February 2013.
  156. ^ "Exclusive: Open software group files complaint against Microsoft to EU". Reuters. 26 March 2013. Retrieved 26 March 2013.
  157. ^ "Researchers demo exploits that bypass Windows 8 Secure Boot". IT World. Archived from the original on 5 August 2013. Retrieved 5 August 2013.
  158. ^ MENDELSOHN, Tom (12 August 2016). "Secure Boot snafu: Microsoft leaks backdoor key, firmware flung wide open [Updated]". Ars Technica. Retrieved 12 August 2016.
  159. ^ Smolár, Martin (1 March 2023). "BlackLotus UEFI bootkit: Myth confirmed". welivesecurity.com. Retrieved 1 March 2023.
  160. ^ Goodin, Dan (6 March 2023). "Stealthy UEFI malware bypassing Secure Boot enabled by unpatchable Windows flaw". Ars Technica. Retrieved 6 March 2023.
  161. ^ "HowTos/UEFI - CentOS Wiki". wiki.centos.org. Retrieved 10 November 2020.
  162. ^ "SecureBoot - Debian Wiki". wiki.debian.org. Retrieved 10 November 2020.
  163. ^ "SUSE Linux Enterprise Server 15 SP1: Chapter 13. UEFI (Unified Extensible Firmware Interface) (Administration Guide)". documentation.suse.com. Retrieved 10 November 2020.
  164. ^ a b "Linux on Windows 8 PCs: Some progress, but still a nuisance". ZDNet. Retrieved 26 February 2013.
  165. ^ "Lenovo UEFI Only Wants To Boot Windows, RHEL". Phoronix. Retrieved 26 February 2013.
  166. ^ "Linux acquitted in Samsung laptop UEFI deaths". Bit-tech. Retrieved 26 February 2013.
  167. ^ "Booting Linux using UEFI can brick Samsung laptops". The H. Retrieved 26 February 2013.

Further reading

External links

Wikimedia Commons has media related to Extensible Firmware Interface.
Firmware and booting
Category