UEFI (Unified Extensible Firmware Interface) is the firmware specification for starting a computer: it defines how motherboard firmware initializes hardware and hands control to an operating system. It replaces the legacy PC BIOS with a modular, 32-bit or 64-bit environment that understands modern disks, file systems, networks and security features.
In the boot process of operating systems, UEFI is the layer between the chipset, the processor and the boot loader. The specification is maintained by the UEFI Forum, while vendors build their firmware from implementations such as the open-source EDK II codebase. Features like Secure Boot, GPT disks and network boot all depend on it.
How UEFI boots a computer
UEFI firmware runs a defined sequence of boot phases under the Platform Initialization (PI) specification. Early phases set up the processor and memory, later phases load drivers and finally a boot manager selects and starts an operating system loader.
The table below shows the standard phases and what each one does. Understanding them helps diagnose boots that stop before the operating system appears.
| Phase | Full name | Main job |
|---|---|---|
| SEC | Security | Establish a root of trust and temporary memory in cache |
| PEI | Pre-EFI Initialization | Initialize the memory controller and DRAM |
| DXE | Driver Execution Environment | Load drivers for chipset, storage, USB and graphics |
| BDS | Boot Device Selection | Read boot entries and start the chosen loader |
| TSL / RT | Transient system load / runtime | Hand off to the OS, keep runtime services |
Boot targets are stored as NVRAM boot variables such as Boot0001 with a BootOrder list. Each entry points to an EFI executable on an EFI System Partition (ESP), a small FAT32 partition, typically 100 MB to 1 GB. Windows uses a path like \EFI\Microsoft\Boot\bootmgfw.efi, and Linux distributions place shim and GRUB or systemd-boot there.
UEFI services and key components
UEFI exposes two sets of functions to software. Boot services are available only until the operating system calls ExitBootServices, while runtime services remain usable afterward, for example to read and write variables or the real-time clock.
- Protocols: standardized interfaces, such as the Graphics Output Protocol and block I/O, that drivers publish and loaders consume.
- UEFI drivers and option ROMs: graphics cards and storage controllers ship their own EFI drivers instead of legacy 16-bit code.
- UEFI shell: an optional command environment for diagnostics, scripting and firmware updates.
- Setup interface: the graphical configuration screen, often still called the BIOS setup by habit.
Because the environment is modular, vendors add network boot over PXE or HTTP, firmware capsule updates and hardware diagnostics without rewriting the whole firmware.
UEFI compared with legacy BIOS
UEFI and BIOS solve the same problem, starting the computer, but UEFI removes the architectural limits of the original IBM PC design. The practical differences are summarized here.
| Aspect | Legacy BIOS | UEFI |
|---|---|---|
| Processor mode | 16-bit real mode | 32-bit or 64-bit protected mode |
| Partition scheme | MBR, practical limit 2 TiB | GPT, disks far beyond 2 TiB |
| Boot method | Code in the first disk sector | EFI files on the ESP |
| Primary partitions | 4 | 128 by default |
| Signed boot chain | Not supported | Secure Boot |
| Drivers | 16-bit option ROMs | Modular UEFI drivers |
For years most boards offered a Compatibility Support Module (CSM) that emulated BIOS behavior. Many current platforms have removed CSM entirely, so older operating systems and some legacy graphics cards no longer boot on them.
UEFI, Secure Boot and TPM
Secure Boot is a UEFI feature, not a separate system. The firmware holds signature databases and only executes boot loaders and drivers signed by a trusted key. A TPM is a separate security chip or firmware module that records measurements of the boot process, so the two complement each other.
| Element | Purpose | Who usually controls it |
|---|---|---|
| PK | Platform key, owns the configuration | Board manufacturer |
| KEK | Key exchange key, authorizes database updates | OS vendor and manufacturer |
| db | Allowed signatures and certificates | Updated through KEK |
| dbx | Revoked signatures | Updated after vulnerabilities |
Updates to dbx and to the trusted certificates are a normal maintenance task. Old certificates can expire or be revoked, and outdated firmware may refuse newly signed loaders, so firmware and OS updates should be kept in step.
Practical configuration and common problems
Most UEFI problems come from a mismatch between firmware mode and disk layout. An operating system installed in UEFI mode on a GPT disk will not start if the firmware is switched to CSM, and the reverse is also true.
| Symptom | Likely cause | Fix |
|---|---|---|
| No boot device found | MBR disk with CSM disabled | Convert to GPT or reinstall in UEFI mode |
| Secure Boot violation | Unsigned loader or revoked key | Use a signed loader or update keys |
| Missing boot entry | NVRAM entry lost after update | Recreate the entry from the ESP |
| Blank screen with old GPU | No UEFI GOP driver | Update GPU firmware or use another card |
Firmware updates deserve caution: a failed flash can leave a board unbootable, although many boards now offer dual firmware chips or a flashback feature. UEFI firmware has also been a target of bootkits, which is why vendors patch it regularly and why keeping it current is a security measure, not only a feature update.
The idea in brief
Before Windows, Linux or macOS appears, a small program built into the motherboard wakes up the hardware and decides what to start. UEFI is the modern version of that start-up program.
Compared with the old BIOS, it is like replacing a printed paper checklist with a smart assistant. It understands large disks, can show a mouse-driven menu and can check that the system software is genuine before letting it run.
A practical scenario
An IT technician moves a small office from aging PCs to new workstations and wants to clone an old system disk. The source disk uses the MBR layout from a BIOS-era installation, and the new motherboards have no CSM option, so the cloned disk does not boot.
The technician converts the disk to GPT with the operating system’s built-in conversion tool, which creates an EFI System Partition and a matching boot entry. Secure Boot is then enabled, the TPM is activated for disk encryption, and all ten workstations boot in UEFI mode with consistent security settings that can be managed centrally.