UEFI BIOS Explained: Architecture, Boot Flow, and Secure Boot

UEFI BIOS Explained: Architecture, Boot Flow, and Secure Boot

UEFI (Unified Extensible Firmware Interface) defines the standardized interface between platform firmware and the operating system’s boot environment. It provides services for hardware discovery, device access, bootloader execution, and selected runtime operations, forming the foundation of modern PC startup.

Although people commonly use the terms BIOS and UEFI BIOS interchangeably, UEFI differs substantially from traditional PC BIOS in its execution environment, driver model, boot configuration, and extensibility.

Understanding these differences is essential for firmware engineers, operating-system developers, system architects, and anyone working with motherboard initialization, bootloaders, or platform security.

This guide covers the transition from legacy BIOS to UEFI, the underlying architecture, the EFI System Partition, NVRAM variables, the Platform Initialization (PI) boot phases, Secure Boot, and practical firmware development tools.

🔮 What Is UEFI?

#

UEFI is a specification that defines interfaces and services used by platform firmware, UEFI drivers, applications, and operating-system loaders. It is designed to provide a standardized pre-OS environment without requiring the operating system to depend directly on motherboard-specific initialization details.

The specification defines how software interacts with firmware through interfaces such as Boot Services, Runtime Services, protocols, and system tables.

The current implementation of these interfaces depends on the hardware platform and the firmware vendor.

Traditional BIOS

#

The original Basic Input/Output System (BIOS) emerged with early IBM-compatible PCs in the 1980s. It initialized essential hardware and provided low-level services used to start an operating system.

Legacy BIOS commonly begins execution in 16-bit real mode and follows established boot conventions involving firmware interrupts and boot-sector code.

Although this model worked well for early PCs, its interfaces and execution assumptions became increasingly restrictive as processor architectures, storage capacities, and hardware complexity evolved.

The term BIOS is also used more broadly today to describe motherboard firmware, including implementations that actually use UEFI internally.

Why UEFI replaced the legacy boot model

#

UEFI introduces a more modular software environment with standardized interfaces and support for executable EFI images.

Its primary architectural advantages include:

• Modular drivers and applications: Firmware functionality can be organized into components that use defined interfaces.
• Modern processor execution environments: UEFI implementations can operate in the execution mode appropriate to their target architecture.
• File-based booting: The firmware can load EFI applications and operating-system bootloaders from supported filesystems.
• Structured device discovery: Drivers expose protocols through which other firmware components can access hardware.
• Persistent boot configuration: NVRAM variables store boot entries, boot order, and security configuration.
• Extensible platform services: Firmware can expose standardized interfaces to bootloaders and supported operating systems.

UEFI does not eliminate platform-specific firmware development. Instead, it provides a standardized environment that separates much of the operating system’s boot logic from individual motherboard implementations.

⚠️ Legacy BIOS Limitations and the UEFI Advantage

#

The transition to UEFI addressed several limitations associated with conventional legacy boot workflows.

Execution environment and memory access

#

Traditional PC BIOS begins executing in 16-bit real mode, an environment with significant restrictions on direct memory access and processor capabilities.

Modern UEFI firmware can execute using the native mode of its target processor architecture. On contemporary x86-64 systems, for example, 64-bit firmware can use the processor’s 64-bit execution environment during appropriate boot stages.

This creates a more flexible foundation for complex hardware initialization and firmware applications.

The distinction should not be interpreted as meaning that every UEFI implementation is 64-bit. UEFI also defines architecture-specific implementations for other execution environments.

Storage capacity and partitioning

#

The familiar 2.2 TB boot-disk limitation is primarily associated with the conventional 32-bit LBA addressing scheme used by MBR partitioning.

UEFI systems commonly use the GUID Partition Table (GPT), which supports substantially larger disks and a more flexible partition layout.

The distinction is important: UEFI and GPT are closely associated in modern systems, but UEFI is a firmware interface, while GPT is a disk partitioning format. Actual boot compatibility also depends on firmware capabilities and operating-system support.

Driver model and extensibility

#

Legacy BIOS relies heavily on established firmware interfaces and hardware-specific initialization routines. Extending these environments can be difficult when new devices require functionality beyond what the original design anticipated.

UEFI provides a protocol-based driver model that allows components to expose services through standardized interfaces.

For example, a storage driver can expose block-level access to a device, allowing other firmware components to discover and use the storage without directly implementing every hardware-specific detail.

BIOS versus UEFI comparison

#

UEFI’s advantages come from the overall architecture rather than from a graphical setup interface alone. Both legacy BIOS and UEFI implementations can provide different types of setup interfaces.

🏗️ UEFI Architecture and Core Concepts

#

UEFI separates platform initialization from the standardized environment used by bootloaders and firmware applications.

The Platform Initialization (PI) specification defines a framework commonly used to organize firmware initialization, while the UEFI specification defines the interfaces and services exposed to UEFI-compatible software.

EFI System Partition (ESP)

#

The EFI System Partition is a dedicated partition used to store EFI boot applications and related files required for booting.

On typical PCs, the ESP uses a FAT filesystem, commonly FAT32. Its size varies by operating system, vendor, and deployment requirements; there is no single mandatory size for every installation.

Typical contents include:

• Operating-system bootloaders, such as Windows Boot Manager or GRUB EFI binaries.
• EFI applications and supported firmware utilities.
• Bootloader configuration files and supporting resources.
• Additional boot files required by particular operating systems.

A common x86-64 removable-media fallback path is:

\EFI\BOOT\BOOTX64.EFI

Installed operating systems may use vendor-specific directories and firmware boot entries instead.

The firmware does not normally store the UEFI firmware image itself in the ESP. Platform firmware is stored in nonvolatile firmware storage, while the ESP provides a filesystem from which boot applications can be loaded.

EFI variables and NVRAM

#

UEFI uses variables to preserve configuration across power cycles. Firmware implementations typically store these variables in nonvolatile storage commonly referred to as NVRAM.

Important variables include:

• BootOrder: Determines the preferred ordering of boot options.
• Boot0000, Boot0001, and related variables: Store individual boot entries, including device and EFI application information.
• BootNext: Specifies a one-time boot option for the next boot, when supported and configured.
• Secure Boot variables: Store or reference the keys and signature databases used for image authentication.

The operating system can access supported variables through UEFI Runtime Services, subject to platform security policies and operating-system permissions.

These variables allow firmware to manage boot configuration without embedding every possible boot choice into fixed firmware code.

UEFI System Table and firmware services

#

When a UEFI application starts, the firmware provides access to a system table containing pointers to important firmware interfaces.

The system table exposes several components, including:

• Boot Services: Interfaces for memory allocation, events, protocol discovery, device access, and EFI image management during the boot-services period.
• Runtime Services: Interfaces that remain available after the operating-system loader exits Boot Services.
• Configuration tables: References to firmware-provided data structures, such as ACPI tables and other platform information.

UEFI drivers and applications interact with hardware through protocols installed on firmware handles. This allows components to discover available services dynamically rather than relying exclusively on fixed hardware-specific entry points.

The official UEFI Specification documents these interfaces and their expected behavior.

🔄 The UEFI Boot Process: From SEC to the Operating System

#

The boot sequence on many UEFI platforms follows the PI architecture, which organizes initialization into several phases. The exact implementation and responsibilities vary by firmware platform.

A simplified flow is:

CPU Reset
    |
    v
SEC - Security Phase
    |
    v
PEI - Pre-EFI Initialization
    |
    v
DXE - Driver Execution Environment
    |
    v
BDS - Boot Device Selection
    |
    v
UEFI OS Loader
    |
    v
ExitBootServices()
    |
    v
Operating System
    |
    v
UEFI Runtime Services

SEC: Security Phase

#

SEC is the earliest PI phase and establishes the initial execution environment after processor reset.

Responsibilities typically include:

• Establishing the initial processor state.
• Providing temporary execution resources.
• Establishing an initial trust and control boundary for subsequent firmware stages.
• Locating and transferring control to the PEI phase.

The exact mechanisms used for temporary storage and hardware setup depend on the platform implementation.

SEC provides the foundation from which more extensive memory and chipset initialization can proceed.

PEI: Pre-EFI Initialization

#

The PEI phase prepares the platform for the more extensive driver environment that follows.

Its primary responsibilities typically include:

• Initializing system memory, including DRAM.
• Performing essential processor and chipset initialization.
• Discovering early platform configuration information.
• Producing Hand-Off Blocks (HOBs) that communicate initialization results to later phases.
• Transferring control to the DXE Foundation.

PEI modules are commonly called PEIMs. They use the PEI services and interfaces available at this stage, which are more limited than those provided during DXE.

Memory initialization is especially important because subsequent firmware components require usable system memory for their execution and data structures.

DXE: Driver Execution Environment

#

DXE is a major phase in which the firmware establishes the services and drivers needed to operate the platform.

The DXE Foundation dispatches drivers and supports the installation of protocols used by later firmware components.

Typical activities include:

• Loading and dispatching DXE drivers.
• Discovering storage, networking, graphics, and other devices.
• Installing device protocols and exposing hardware services.
• Creating system tables and configuration tables.
• Preparing the environment required by the firmware boot manager.

By the end of the relevant DXE initialization work, the firmware has established most of the standardized interfaces needed to locate and launch an operating-system loader.

Drivers may be dispatched according to protocol dependencies, platform policies, and firmware implementation details rather than through one universal fixed sequence.

BDS: Boot Device Selection

#

The Boot Device Selection phase determines which boot option should be executed.

The firmware boot manager evaluates persistent boot configuration, including variables such as BootOrder and individual Boot#### entries.

Depending on configuration and platform support, it may:

• Load the selected EFI operating-system loader.
• Display a boot-selection interface.
• Attempt another boot option after a failure.
• Launch a firmware application or diagnostic utility.
• Support removable-media boot options.

The boot manager loads the selected EFI image and transfers control to it.

For example, a Windows installation may launch Windows Boot Manager, while a Linux installation may launch GRUB or another EFI-compatible bootloader.

TSL: Transient System Load

#

The TSL phase describes the period during which the operating-system loader operates within the firmware-provided boot environment.

At this stage, the loader can use UEFI Boot Services to perform tasks such as allocating memory, reading files, discovering firmware information, and preparing the operating system.

The critical transition occurs when the loader has prepared the system sufficiently to assume control of platform resource management.

It then calls ExitBootServices() to end the Boot Services environment.

This is the formal handoff boundary, not merely the moment an EFI executable begins running.

RT: Runtime phase

#

After the operating system has taken control, UEFI Runtime Services may remain available.

Supported services can include:

• Reading or updating permitted firmware variables.
• Accessing system time.
• Resetting the platform.
• Invoking other standardized runtime operations, depending on firmware support.

Runtime Services differ from Boot Services because the operating system must preserve the relevant runtime environment and memory mappings when using them.

Many firmware drivers and services are no longer available after ExitBootServices(). The operating system is responsible for managing hardware and resources outside the interfaces that remain available through Runtime Services.

🔐 UEFI Secure Boot and the Chain of Trust

#

Secure Boot is a UEFI security mechanism designed to prevent unauthorized EFI images from executing during the boot process.

It uses cryptographic signatures and firmware-maintained trust databases to determine whether an EFI image is trusted under the platform’s current security policy.

Secure Boot keys and signature databases

#

A typical Secure Boot configuration includes several key and signature databases:

• Platform Key (PK): Establishes the platform owner’s authority over key-management configuration.
• Key Exchange Keys (KEK): Authorize updates to the allowed and revoked signature databases.
• Allowed signature database (db): Contains trusted certificates or signatures that can authorize EFI images.
• Revocation database (dbx): Contains signatures, hashes, or other entries that identify images that must not be trusted.

These databases allow the platform to manage trusted boot software and reject certain known-compromised or unauthorized images.

The exact key hierarchy and enrollment policy depend on how the system is configured.

How Secure Boot verifies EFI images

#

When Secure Boot is enabled, firmware image-loading mechanisms evaluate the EFI image against the relevant trust and revocation databases.

The objective is to prevent unauthorized pre-OS software, including malicious bootloaders, from running before the operating system’s own security controls become active.

A typical boot chain may involve:

1. Firmware authenticates the operating-system bootloader.
2. The bootloader applies its own verification policy to subsequent components.
3. The operating system enforces its own rules for kernel modules, drivers, and other privileged code.

The second and third steps are not automatically guaranteed by UEFI Secure Boot itself. They depend on the bootloader and operating system implementing their own verification mechanisms.

Secure Boot also does not guarantee that all signed software is free from vulnerabilities. Its primary role is to enforce trust decisions for boot images, not to prove that trusted code is inherently secure.

🛠️ UEFI Firmware Development Tools

#

Firmware engineers can develop and validate UEFI applications and drivers using open-source development frameworks and virtualized test environments.

EDK II

#

EDK II, maintained by the TianoCore project, is a widely used open-source UEFI firmware development environment.

It provides infrastructure for building UEFI applications, drivers, libraries, and platform firmware. It also includes reusable packages and implementations of many standard firmware interfaces.

The project is useful for understanding firmware architecture, developing custom modules, and studying real implementations of UEFI and PI concepts.

QEMU

#

QEMU is a system emulator that can run virtual machines with different hardware configurations.

For firmware development, it provides a controlled environment for testing UEFI images, experimenting with boot configurations, and investigating initialization problems without requiring a physical development board for every iteration.

QEMU can also be combined with debugging tools to inspect early boot execution and diagnose firmware or operating-system loader issues.

OVMF

#

OVMF (Open Virtual Machine Firmware) provides UEFI firmware for virtual machines and is commonly used with QEMU.

It is based on EDK II and supplies a practical UEFI environment for testing EFI applications, bootloaders, and operating systems.

OVMF is particularly useful for reproducing boot failures, validating firmware-facing software, and testing changes to UEFI applications before moving to physical hardware.

Working with UEFI disk protocols

#

UEFI provides protocols for discovering and accessing storage devices. Understanding these interfaces is useful when building boot utilities, firmware diagnostics, or custom device-management applications.

For a practical example, see KAD’s guide to retrieving disk information in UEFI using disk protocols, which covers Block I/O, Disk I/O, and Disk Info.

🎯 Conclusion: Why UEFI Matters for Modern Firmware Engineering

#

UEFI represents a major architectural evolution in PC firmware, replacing the conventional legacy boot interface with a standardized, modular pre-OS environment.

Its protocol-based driver model, EFI applications, persistent boot variables, and standardized services provide the foundation for modern hardware initialization and operating-system booting.

The PI architecture organizes firmware initialization into phases, commonly progressing through SEC, PEI, DXE, and boot-device selection before the OS loader assumes control. After ExitBootServices(), the operating system manages the platform while retaining access to supported UEFI Runtime Services.

Secure Boot adds a cryptographic mechanism for authenticating EFI images, helping protect the system before the operating system’s full security controls are active.

For firmware engineers, understanding these mechanisms is essential when developing drivers, debugging boot failures, implementing platform security, or maintaining vendor-specific firmware.

Tools such as EDK II, QEMU, and OVMF make it possible to study these interfaces and validate implementations in reproducible development environments.

Ultimately, UEFI is not simply a replacement for legacy BIOS menus. It is a standardized firmware architecture that enables modern processors, storage systems, security mechanisms, and operating systems to work together through well-defined interfaces.