Unified Extensible Firmware Interface - ISpillMyDrink/UEFI-Repair-Guide GitHub Wiki

To understand what the Unified Extensible Firmware Interface (UEFI) is, we firstly need to take a step back and take a look at UEFI's direct predecessor, the Basic Input/Output System (BIOS).

The BIOS is firmware used to perform hardware initialization of a computer system before any operating system or software can run on the machine. The BIOS instructions are mapped into physical memory and executed by the main CPU. The BIOS runs the power-on self-test (POST) in which all the components of the system, such as drives, video cards, etc., are identified, tested and initialized. After POST has finished, the BIOS attempts to locate a boot loader from any storage device and executes it.

In 2002 Intel released its Extensible Firmware Interface (EFI) specification, which describes a standardized interface between a system's firmware and the operating system running on it. The EFI specification introduced the concept of firmware drivers and applications, allowing for further modularization and reusability of firmware implementations.

In 2004 Intel released their EFI implementation Foundation Core, which later evolved into the EFI Development Kit (EDK).

Nowadays the de-facto reference implementation for UEFI is the open source TianoCore EFI Development Kit II (EDKII), which is forked and extended by so-called Independent BIOS Vendors (IBVs) like American Megatrends International (AMI) or Insyde Software to suit the needs of Original Equipment Manufacturers (OEMs) like ASUS, Acer, etc. which in turn also make their own modifications.

The BIOS Boot Process

TODO

The UEFI Boot Process

All x86 processors begin executing instructions from the so-called Reset Vector (logical memory location 0xFFFF:FFF0; on most devices the top of logical memory map to the SPI ROM on power-on, meaning the Reset Vector is executed directly from the ROM).

This is actually not true for most modern systems for a couple of reasons; on Intel machines the ME will power on the x86 but only release it from reset after the ME bringup is completed and the CPU has undergone a Microcode update (see Firmware Interface Table). Similar is true for AMD's PSP. The reset vector is no longer the entry point to the system but rather is executed early in the sequence (see Bootguard). On some systems the SPI ROM contents are also not directly read but rather mirrored on a separate SRAM (for example the TXE internal SRAM), which is then mapped to the top of logical memory before execution.

The UEFI boot process is split up in 3 distinct phases, that are executed consecutively. One of the first instructions to be executed after the Reset Vector will be a jump instruction to the beginning of the Security Phase instructions.

Security Phase (SEC)

When the SEC is executed the entire system is in a fully unconfigured state, the CPU is still in 16-bit mode and DRAM is not set up yet. The job of the SEC phase is to configure the system far enough for the PEI phase to be validated and executed. Therefore one of the first things to happen in the SEC phase is the transition to 32-bit mode (though that might also happen as late as the PEI phase), initialization of temporary memory (for example by using Cache-as-RAM), and mapping of the full contents of the SPI ROM to the top of logical memory, if that hasn't happened up to this point. At that point the PEI phase will be validated and control transferred to it.

Pre-EFI Initialization Phase (PEI)

One of the first things to happen in the PEI is the transfer of ROM-based data to early memory (e.g. CPU cache). At that point a series of PEI modules (PEIM) is executed in order of dependencies (modules with no dependencies are executed first) until all are run. PEIMs include modules to setup CPU-related functions such as cache interface and frequency selection, modules to initialize the Memory Controller and I/O Hub, and modules to complete the initialization of DRAM for use in the DXE phase. The PEI ends with the check for the current boot mode. When the system is in S3 boot mode, control is transferred to the S3 Boot Script and subsequently to the OS Resume Vector. If not, control is transferred to the DXE entry point.

Driver Execution Environment (DXE) / Boot Device Select (BDS)

The DXE phase begins with the discovery of DXE drivers in the available firmware volumes, determining whether their respective conditions for running are met, and executing them until all are run. Most of the high level functionality of a platform is implemented in the form of DXE drivers, that includes components such as I/O drivers, network drivers, and other platform specific drivers. Once all drivers have been dispatched, control is transferred to the Boot Device Select (BDS) driver. The BDS determines the necessary devices connected for the given boot path and invokes the selected boot target.

The S3 Boot Script

TODO

Security Implications

TODO

Secure Boot

Secure Boot is a feature defined by the UEFI specification, creating a mechanism for verification of UEFI executables such as Bootloaders and Option ROMs through a firmware-backed image database. Its function is to assure that only certified code may be executed by the UEFI and it's intended to protect the platform from bootkits.

UEFI Secure Boot defines four databases: the Authorized Image Database (db), the Forbidden Image Database (dbx), the Timestamp Database (dbt), and the Recovery Database (dbr). The db contains the public key information for allowed UEFI executables, the dbx contains public key information for disallowed UEFI executables.

Advanced Configuration and Power Interface (ACPI)

TODO

Differentiated System Description Table (DSDT)

TODO