UEFI

with both UEFI and BIOS support -based flash memory located on the motherboard. Various I/O protocols can be used, SPI being the most common. Unified Extensible Firmware Interface or UEFI is a specification for the firmware architecture of a computing platform. When a computer is powered on, the UEFI implementation typically runs first, before the operating system or any other program is loaded. Examples include AMI Aptio, Phoenix SecureCore, TianoCore EDK II, and InsydeH2O. UEFI replaces the BIOS that was present in the boot ROM of all personal computers that are IBM PC compatible, although it can provide backwards compatibility with the BIOS using CSM booting. Unlike the BIOS, which was originally developed by IBM as a proprietary architecture, the UEFI specification is managed by an industry consortium. Most production firmware implementations for both remain 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 is used for the reference implementation TianoCore EDKII.

with both UEFI and BIOS support]] -based flash memory located on the motherboard. Various I/O protocols can be used, SPI being the most common.]] Unified Extensible Firmware Interface or UEFI is a specification for the firmware architecture of a computing platform. When a computer is powered on, the UEFI implementation typically runs first, before the operating system or any other program is loaded. Examples include AMI Aptio, Phoenix SecureCore, TianoCore EDK II, and InsydeH2O. UEFI replaces the BIOS that was present in the boot ROM of all personal computers that are IBM PC compatible, although it can provide backwards compatibility with the BIOS using CSM booting. Unlike the BIOS, which was originally developed by IBM as a proprietary architecture, the UEFI specification is managed by an industry consortium. Most production firmware implementations for both remain 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 is used for the reference implementation TianoCore EDKII.

Processor compatibility

UEFI supports processor architectures that are 32-bit or higher. However, only processors with a little-endian mode are supported. The UEFI specification, version 2.11, has official documentation for the following processor architectures: x86 (IA-32, x86-64) Itanium (IA-64) ARM (AArch32, AArch64) RISC-V (32-bit, 64-bit, 128-bit) LoongArch (32-bit, 64-bit) Unofficial UEFI support is under development for POWERPC64 by implementing TianoCore EDK II on top of OPAL, the OpenPOWER abstraction layer, running in little-endian mode. For MIPS, there also exists an unofficial project, based on the original EDK. However, both projects have since been abandoned as of November 2016 and September 2015 respectively. UEFI only allows executing UEFI applications that match the firmware's bit-width, even if the processor supports smaller or larger bit-widths. For example, a 64-bit UEFI firmware may only execute 64-bit UEFI applications, even if the processor has a 32-bit processor mode. Some low-end computers have been shipped with 32-bit UEFI firmware running on 64-bit CPUs. Once a UEFI application ends the boot services, and gets granted full control over the system, it becomes possible to change the processor execution mode. However, calling runtime services requires shortly changing back to the original processor mode, as runtime services may only be called from the same processor mode as the firmware implementation. The Linux kernel added support for booting 64-bit kernels on 32-bit UEFI firmware implementations with x86-64 CPUs since version 3.15, requiring the UEFI boot loader to support the EFI handover protocol. The EFI handover protocol allows UEFI boot loaders to defer the UEFI initialization to the kernel's EFI boot stub, so that only the kernel does the UEFI initialization.

Disk device compatibility

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 per disk) are relaxed. More specifically, GPT allows for a maximum disk and partition size of 8 ZiB with 512 byte sectors. The UEFI specification only supports FAT12/16/32 partitions that are on GPT or MBR disks as well as El Torito-formatted optical discs. Although GPT is a part of the UEFI standard, it may also be usable by BIOS PCs to boot an operating system off of.

Services

EFI defines two types of services: boot services and runtime services. Boot services are available only while the firmware owns the platform (i.e., before the ExitBootServices() call), and they include text and graphical consoles on various devices, and bus, block and file services. Runtime services are still accessible while the operating system is running; they include services such as date, time and NVRAM access. Each service exposes one or more interface functions. Graphics Output Protocol (GOP) services The Graphics Output Protocol (GOP) provides runtime services; see also Graphics features section below. The operating system is permitted to directly write to the framebuffer and BLT provided by GOP during runtime mode. UEFI memory map services This boot service allows the bootloader to obtain information on how the memory is laid out. SMM services The SMM ("ring -2") is an x86 mode that provides secure code execution isolated from all lower rings. Modern UEFI generalizes the concept to Management Mode (MM) to also encompass alternative technologoies such as TrustZone. One common use of the MM/SMM services is as a secure store of variables. ACPI services SMBIOS services Devicetree services (for RISC processors) These runtime services allow the operating system to obtain information about the installed hardware and how to make use of them. Variable services UEFI variables store non-volatile data. The variable storage is conceptually divided into namespaces identified by GUIDs. Each namespace can contain any number of variable entries, which are key/value pairs (Unicode string key, variable-length byte-array value). Each entry also carries an attributes bitfield, which can restrict its access to only boot or run-time (among other, more advanced, uses). Some UEFI variables are shared between platform firmware and operating systems. For example, the OS may set the and variables under the namespace to influence the UEFI boot manager's future choices. Other variables may be private to one side. For example, UEFI variables can be used by an OS to keep crash messages in NVRAM after a crash for the operating system to retrieve after a reboot. 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. On machines using a PC-AT real-time clock, Microsoft Windows does not use the EFI time zone and DST fields, and expects the hardware clock to provide local time like traditional BIOS-based Windows did. As a result the HW clock cannot be set to UTC unless using recent versions and an entry in the Windows registry is set to indicate the use of UTC. In addition to standard instruction set architecture-specific device drivers, EFI allows the use of drivers written in EFI byte code (EBC). An interpreter in the system firmware executes the code. 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. A compiler used to be available for generating EBC from C source code and its discontinuation by Intel had rendered EBC defunct.

UEFI booting

Unlike the legacy PC BIOS, UEFI does not rely on boot sectors on the computer's data storage, defining instead a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager checks the boot configuration and, based on its settings, then executes the specified OS boot loader or operating system kernel. The boot configuration is defined by variables stored in the computer's persistent NVRAM storage, including variables that indicate the file system paths to OS loaders or OS kernels. OS boot loaders can be automatically detected by UEFI, which enables easy booting from removable devices such as USB flash drives. This automated detection relies on standardized file paths to the OS boot loader, with the path varying depending on the computer architecture. The format of the file path is defined as ; for example, the file path to the OS loader on an x86-64 system is , and on ARM64 architecture. Booting UEFI systems from GPT-partitioned disks is commonly called UEFI-GPT booting. The alternative is to boot from an EFI System Partition on MBR-partitioned disks, commonly called UEFI-MBR. UEFI-MBR capability is required by the UEFI specification, but some UEFI firmware implementations immediately switch to BIOS-based CSM booting depending on the type of the boot disk's partition table, effectively preventing it from occurring. It is also common for a boot manager to have a textual user interface to allow the user to select the desired OS (or setup utility) from a list of available boot options. On PC platforms, firmware supporting UEFI boot is often referred to as a "UEFI BIOS", though some newer x86 platforms exclude CSM support entirely.

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. The Compatibility Support Module allows some legacy operating systems and some legacy option ROMs that do not support UEFI to still be used. It also provides required legacy System Management Mode (SMM) functionality (CompatibilitySmm) in addition to features provided by the UEFI SMM. An example of such a legacy SMM functionality is providing USB legacy support for keyboard and mouse, by emulating their classic PS/2 counterparts. In November 2017, Intel announced that it planned to phase out support CSM for client platforms by 2020, because of the low security and high complexity of CSM. In July 2022, Kaspersky Labs published information regarding a Rootkit designed to chain boot malicious code on machines using Intel's H81 chipset and the Compatibility Support Module of affected motherboards. In August 2023, Intel announced that it planned to phase out CSM support for server platforms by 2024, because of the low security and high complexity of CSM.

Secure Boot

boot manager]] The UEFI specification defines a Secure Boot that can secure the boot process by preventing the loading of UEFI drivers or OS boot loaders that are not signed with an acceptable digital signature. When Secure Boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "platform key" (PK) to be written to the firmware. Once the key is written, Secure Boot enters "User" mode, where only UEFI drivers and OS boot loaders signed with the platform key can be loaded by the firmware. Additional "key exchange keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the platform key. Secure Boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key. Secure Boot is supported by Windows 8 and 8.1, Windows Server 2012 and 2012 R2, Windows 10, Windows Server 2016, 2019, and 2022, and Windows 11, VMware vSphere 6.5 and several Linux distributions including Fedora (since version 18), openSUSE (since version 12.3), RHEL (since version 7), CentOS (since version 7 ), Debian (since version 10), Ubuntu (since version 12.04.2), Linux Mint (since version 21.3), and AlmaLinux OS (since version 8.4 ). , FreeBSD support is in its planning stage.

UEFI shell

The UEFI standards include a specification for a shell environment. The shell is a UEFI application that can be used to execute other UEFI applications, including UEFI boot loaders. It also includes built-in commands 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 ). It implements a scripting language with support for if-statements, for-loops, and environment variables. The UEFI shell is not a mandatory component of the firmware. It tends to be pre-loaded into server motherboards, which allows it to be launched by appropriate key press combinations. Some other motherboards provide a direct option in firmware setup for launching, e.g. compiled x86-64 version of the shell needs to be made available as /SHELLX64.EFI . For other systems, the solution is either creating an appropriate USB flash drive (as BOOTxxxx.efi , making use of boot loader auto-detection) or adding manually ( bcfg ) a boot option associated with the compiled version of shell. Source code for a UEFI shell can be downloaded from the Intel's TianoCore UDK/EDK2 project. A pre-built ShellBinPkg is also available. Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems.

Commands

The following is a list of commands supported by the EFI shell v1. alias attrib bcfg cd cls comp cp date dblk dh dmpstore echo Edd30 EddDebug edit err guid help load ls map mem memmap mkdir mm mode mount pause pci reset rm set stall time type unload ver vol The shell v2 includes a much broader set of features in its default build. For example, there is a new for showing a tree of devices.

Vulnerabilities

UEFI implementation flaws have been exploited to gain persistence, the ability to maintain malicious access to a compromised system even after system reboot, operating system reinstallation, and even partial physical part replacement, such as of corrupted PCI persistent flash storage. In 2022, a vulnerbility in an old version of the Windows Boot Manager (WBM) was exploited by a malware called BlackLotus, which exploits a bug in the WBM to run malicious code before the OS starts. Although Microsoft provided a fixed version of the WBM soon afterwards, it did not revoke the signature on the old WBM. As a result, the old WBM may still be loaded, leading to the malware being run if present.

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. The development has moved to GitHub since .UDK2015.

Secure Boot

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. Following the announcement, critics and free-software/open-source advocates, including the Free Software Foundation, expressed concern that Microsoft might use the Secure Boot functionality of UEFI to restrict 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. Windows 10 allows OEMs to decide whether or not Secure Boot can be managed by users of their x86 systems. 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), 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. boot manager, using shim and Machine Owner Key (MOK) for Secure Boot support]] 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. Ubuntu 12.10 uses an older version of shim 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, but requires that both the kernel and its modules be signed as well. shim has Machine Owner Key (MOK) that can be used to sign locally compiled kernels and other software not signed by distribution maintainer, without changing the Secure Boot mode to setup mode. 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, 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 argued that Red Hat was accommodating 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, contending that Microsoft's Secure Boot requirements on OEM systems were "obstructive" and anti-competitive. 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. 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, but an exploitable binary signed by the key was. This allows software to execute as though it were signed by Microsoft, presenting potential risks for rootkit and bootkit attacks. This also complicates remediation efforts, since a patch can potentially be downgraded by replacing it with the signed exploitable binary. Microsoft stated that the vulnerability only affects ARM architecture and Windows RT devices and released two updates; however, reports noted that these updates do not completely prevent exploitation because fully resolving the vulnerability would require key replacements in end-user firmware. On 1 March 2023, researchers from ESET reported discovering "BlackLotus", described as the first active UEFI bootkit capable of bypassing UEFI Secure Boot by exploiting the limitations of the previous security updates. 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 GRUB) to load in the boot process. The change was reverted the next month. In June 2025, LWN.net reported that the Microsoft UEFI CA 2011 certificate will be expired on June 24, 2026, which may refuse some Linux to load if Secure Boot is enabled. However, in TianoCore EDK II as well as many commercial UEFI implementations (such as AMI Aptio), time/date check for Secure Boot certificate is usually disabled by default. Many Linux distributions support UEFI Secure Boot , such as RHEL (RHEL 7 and later), CentOS (CentOS 7 and later ), Ubuntu, Fedora, Debian (Debian 10 and later ), OpenSUSE, and SUSE Linux Enterprise. 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 Python Interpreter for UEFI Shell

Text derived from https://en.wikipedia.org/w/index.php?oldid=1378309562 under CC BY-SA 4.0; modifications have been made.