> For the complete documentation index, see [llms.txt](https://docs.enclaive.cloud/sylica/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enclaive.cloud/sylica/knowledge-base/uefi.md).

# UEFI

The Unified Extensible Firmware Interface is an industry standard for firmware, and paves the ground for the Syrica CVMF distribution

## Introduction

UEFI stands for **Unified Extensible Firmware Interface**. It is the modern software on a computer's motherboard that replaces the old BIOS. It checks your hardware and starts your operating system when you turn on your PC.\
\
UEFI is a modern replacement for BIOS. It connects your computer's firmware and operating system (OS). UEFI manages startup before the operating system loads.

## Key differences between UEFI and BIOS

* **Modern interface**: UEFI often has a graphical interface. BIOS uses text-based menus.
* **Storage support**: UEFI supports GUID Partition Table (GPT). GPT supports drives larger than 2 TB.
* **Flexible design**: UEFI supports features such as Secure Boot.

UEFI can improve hardware compatibility and security.

Here is a more accurate and technically grounded explanation.

## How UEFI Works

UEFI, the Unified Extensible Firmware Interface, is the firmware environment that starts a computer or virtual machine and prepares it to run an operating system.

It sits between the hardware and the operating system:

```
Hardware or virtual machine
        ↓
UEFI firmware
        ↓
Bootloader or Unified Kernel Image
        ↓
Operating system kernel
```

UEFI does much more than simply search for an operating system. It initializes the platform, loads firmware drivers, applies security policy, selects a boot target, and hands control to the operating system.

### 1. System reset

When the computer is powered on, or a virtual machine is started, the processor begins executing code at a predefined reset address.

This initial code is stored in the firmware image.

At this point:

* normal system memory may not yet be available;
* no operating system is running;
* most devices have not been initialized;
* only a very small execution environment exists.

The firmware establishes the minimum CPU and memory state required to continue.

In EDK2-based firmware, this begins with the reset vector and the SEC phase.

### 2. Early platform initialization

The firmware initializes the basic platform environment.

Typical tasks include:

* initializing the CPU;
* establishing temporary memory;
* discovering or initializing RAM;
* detecting the virtual or physical platform;
* identifying available processors;
* determining the memory layout;
* detecting confidential-computing features such as AMD SEV-SNP or Intel TDX.

In EDK2, most of this work happens during the SEC and PEI phases.

The firmware records the discovered platform state and passes it to later phases.

### 3. Hardware and platform discovery

UEFI discovers the devices and interfaces required for booting.

These may include:

* PCI devices;
* storage controllers;
* VirtIO devices;
* NVMe disks;
* graphics devices;
* serial consoles;
* TPMs;
* network interfaces;
* virtual devices provided by a hypervisor.

On traditional computers, this process is often loosely described as POST, or Power-On Self-Test.

However, modern UEFI firmware does not necessarily perform one single monolithic POST procedure. Instead, initialization and validation are distributed across multiple firmware phases and drivers.

In a virtual machine, many physical hardware checks are unnecessary because the devices are emulated or paravirtualized.

### 4. The UEFI driver environment

After memory has been initialized, UEFI starts its main driver environment that provide services such as:

* access to disks;
* PCI enumeration;
* filesystem support;
* console output;
* ACPI table generation;
* SMBIOS information;
* UEFI variable storage;
* cryptography;
* Secure Boot;
* TPM support.

Drivers communicate through standardized interfaces called UEFI protocols.

For example:

```
Storage driver
    provides block access
        ↓
Partition driver
    finds disk partitions
        ↓
Filesystem driver
    reads files
        ↓
Boot Manager
    loads an EFI executable
```

This modular architecture allows UEFI firmware to support different hardware and boot configurations.

### 5. UEFI configuration and variables

UEFI stores configuration information in non-volatile variables.

These variables may include:

* boot order;
* individual boot entries;
* the next one-time boot target;
* Secure Boot keys;
* allowed and revoked certificates;
* firmware configuration;
* platform policy.

Important boot variables include:

```
BootOrder
Boot0000
Boot0001
BootNext
```

A boot entry normally contains:

* a description;
* the path to an EFI executable;
* a device path;
* optional boot parameters.

On physical systems, the variables are typically stored in flash-backed non-volatile memory.

In virtual machines, they may be stored in a separate variable-store image or file.

UEFI variables are not simply a replacement for the old BIOS configuration screen. They are part of the firmware-to-operating-system interface and may remain accessible after the operating system starts.

### 6. Boot device selection

Once the required drivers and services are available, the UEFI Boot Manager selects what to boot.

This is commonly called the BDS, or Boot Device Selection, phase.

The Boot Manager may:

* process the configured `BootOrder`;
* inspect available disks;
* access an EFI System Partition;
* load a bootloader;
* load a Unified Kernel Image;
* start a recovery environment;
* boot from the network;
* use a hypervisor-provided direct-kernel boot configuration.

A typical disk-based boot path looks like this:

```
UEFI Boot Manager
        ↓
EFI System Partition
        ↓
EFI bootloader
        ↓
Operating system kernel
```

The EFI System Partition is normally formatted with FAT and contains EFI executables such as:

```
\EFI\BOOT\BOOTX64.EFI
\EFI\Microsoft\Boot\bootmgfw.efi
\EFI\systemd\systemd-bootx64.efi
```

UEFI does not normally “process the operating system” itself. It loads an EFI executable and transfers control to it.

That executable may be:

* GRUB;
* systemd-boot;
* Windows Boot Manager;
* a Linux EFI-stub kernel;
* a Unified Kernel Image.

### 7. Secure Boot verification

Before executing an EFI image, UEFI may apply Secure Boot policy.

Secure Boot checks whether the image is signed by an approved key and whether the image or signer has been revoked.

The main Secure Boot databases are:

* `PK`: Platform Key;
* `KEK`: Key Exchange Key database;
* `db`: allowed certificates and signatures;
* `dbx`: revoked certificates and signatures.

The simplified process is:

```
UEFI loads an EFI image
        ↓
UEFI checks the image signature
        ↓
Signer is trusted by db
        ↓
Image or signer is not revoked by dbx
        ↓
Image is allowed to execute
```

Secure Boot answers:

> Is this image authorized to run?

It does not prove that the image is free of vulnerabilities.

### 8. Measured Boot

UEFI may also measure firmware components and boot images.

Measurements are cryptographic hashes recorded in TPM Platform Configuration Registers or in another trusted measurement mechanism.

Measured components may include:

* firmware code;
* firmware configuration;
* Secure Boot state;
* boot variables;
* bootloaders;
* kernels;
* initrds;
* kernel command lines.

Measured Boot answers:

> What actually ran?

This information can later be evaluated through **remote attestation**.

### 9. Loading the operating system

The selected EFI bootloader prepares the operating system.

It may:

* load the kernel;
* load an initial RAM filesystem;
* provide the kernel command line;
* allocate memory;
* obtain the final firmware memory map;
* prepare operating-system data structures.

A Unified Kernel Image can package several of these components into one signed EFI executable:

```
Unified Kernel Image
├── Linux kernel
├── initrd
├── embedded command line
├── OS metadata
└── signature
```

This can simplify Secure Boot and measured-boot policy because the firmware verifies one combined artifact.

### 10. ExitBootServices

While the bootloader is running, UEFI Boot Services remain available.

These services include:

* memory allocation;
* protocol discovery;
* file access;
* image loading;
* event handling;
* device connection.

When the operating system is ready to take control, the bootloader calls:

```
ExitBootServices()
```

After this call:

* UEFI Boot Services stop;
* the operating system takes ownership of memory;
* the operating system initializes its own drivers;
* most firmware drivers are no longer used;
* only selected UEFI Runtime Services remain.

This is the principal handover point between firmware and the operating system.

### 11. Runtime Services

A small part of UEFI may remain available after the operating system starts.

These Runtime Services may provide:

* reading and writing UEFI variables;
* system reset;
* time services;
* firmware-update capsule functions;
* access to Secure Boot configuration.

Runtime firmware remains highly privileged and therefore remains part of the system’s Trusted Computing Base.

### Complete boot sequence

The complete process can be summarized as follows:

```
1. Power-on or virtual-machine start

2. Processor begins at the firmware reset vector

3. SEC establishes minimal execution state

4. PEI initializes memory and discovers the platform

5. DXE loads firmware drivers and creates UEFI services

6. The Boot Manager evaluates boot configuration

7. Secure Boot verifies the selected EFI image

8. Measured Boot records the firmware and boot state

9. The EFI bootloader or UKI starts

10. The kernel and initrd are prepared

11. The loader calls ExitBootServices()

12. The operating system takes control

13. Only limited UEFI Runtime Services remain
```

### Physical system versus virtual machine

The general UEFI architecture is the same in both environments, but the initialization differs.

#### Physical system

UEFI initializes real hardware such as:

* DRAM controllers;
* chipsets;
* PCI devices;
* storage controllers;
* graphics hardware.

#### Virtual machine

Virtual-machine firmware initializes a virtual platform provided by QEMU, KVM, a cloud platform, or another hypervisor.

It may rely on:

* VirtIO devices;
* QEMU firmware configuration;
* virtual PCI devices;
* virtual TPMs;
* confidential-computing interfaces.

In a confidential VM, the hypervisor is not automatically trusted. Firmware must validate host-provided data and correctly separate private guest memory from shared memory used for communication.

### Security perspective

UEFI is security-critical because it executes before the operating system and decides what code receives control next.

The most important security properties are:

* authentic and measured firmware;
* minimal firmware modules;
* restrictive boot policy;
* protected Secure Boot keys;
* validated host and device input;
* reproducible builds;
* rollback protection;
* minimal Runtime Services;
* continuous vulnerability management.

UEFI should therefore not be treated merely as startup code. It is a privileged execution environment and an essential part of the platform’s root of trust.