> 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/edk-ii.md).

# EDK II

EDK II provides the underlying framework and reference implementation of UEFI

{% hint style="info" %}
Sylica is built on top of EDK II because it provides:

* Industry-standard UEFI compatibility
* Mature support for Intel TDX and AMD SEV-SNP
* Modular architecture suitable for security hardening
* Extensive ecosystem support
* A well-tested implementation used across major cloud providers

Rather than replacing EDK II, Sylica minimizes, hardens, and reproducibly builds it for confidential virtual machines.
{% endhint %}

## Overview

### TianoCore EDK II – The Reference Implementation

Modern x86 and Arm systems no longer boot through a traditional BIOS. Instead, they implement the **Unified Extensible Firmware Interface (UEFI)**, an industry standard that defines how firmware initializes hardware, establishes the platform trust chain, and transfers control to the operating system.

**TianoCore EDK II** is the open-source reference implementation of the UEFI and Platform Initialization (PI) specifications. Originally initiated by Intel and now maintained by the TianoCore community, EDK II forms the foundation of firmware for servers, laptops, embedded systems, cloud hypervisors, and confidential computing platforms. It provides both a firmware architecture and a modular development framework for building complete UEFI firmware images.

### Firmware Architecture

Unlike a monolithic BIOS, EDK II consists of hundreds of independent modules that cooperate through well-defined interfaces.

```
                     +---------------------------+
                     |      Hardware Reset       |
                     +-------------+-------------+
                                   |
                               SEC Phase
                                   |
                               PEI Phase
                                   |
                               DXE Phase
                                   |
                               BDS Phase
                                   |
                        UEFI Boot Manager
                                   |
                          OS Boot Loader
                                   |
                           Operating System
                                   |
                         Runtime Services
```

Each stage has a clearly defined responsibility and progressively enables additional platform functionality.

This staged architecture allows vendors such as Cobalt to replace, remove, or harden individual components without redesigning the complete firmware stack.

## Core Architecture

EDK II follows a package-based architecture.

```
Platform
│
├── Packages
│     ├── MdePkg
│     ├── MdeModulePkg
│     ├── UefiCpuPkg
│     ├── SecurityPkg
│     ├── NetworkPkg
│     └── OvmfPkg
│
├── Libraries
│
├── Drivers
│
├── UEFI Applications
│
└── Platform Configuration
```

Every firmware image is assembled from reusable modules:

* **Packages** define APIs, GUIDs, protocols, libraries, and interfaces.
* **Libraries** provide reusable implementations that are linked into firmware modules at build time.
* **Drivers** initialize hardware and expose UEFI protocols.
* **Applications** execute within the UEFI environment before the operating system starts.
* **Platform packages** describe how all components are combined into a complete firmware image.

This modular architecture enables vendors to customize firmware without modifying the core framework. The build system assembles the selected modules into one or more firmware volumes according to platform configuration files such as DSC, DEC, INF, and FDF.

## Major EDK II Packages

Although EDK II contains dozens of packages, only a small subset forms the core of most virtual machine firmware.

| Package          | Purpose                                                                                     |
| ---------------- | ------------------------------------------------------------------------------------------- |
| **MdePkg**       | Fundamental UEFI and PI definitions, protocols, GUIDs, data types, and libraries            |
| **MdeModulePkg** | Generic implementations of UEFI services, DXE Core, PEI Core, runtime services, and drivers |
| **UefiCpuPkg**   | CPU initialization and processor-specific functionality                                     |
| **SecurityPkg**  | Secure Boot, authenticated variables, TPM, cryptography, and security libraries             |
| **CryptoPkg**    | Cryptographic algorithms and OpenSSL integration                                            |
| **NetworkPkg**   | PXE, TCP/IP, HTTP Boot, DNS, DHCP                                                           |
| **FatPkg**       | FAT filesystem support                                                                      |
| **ShellPkg**     | UEFI Shell implementation                                                                   |
| **OvmfPkg**      | Virtual machine platform implementation for QEMU/KVM and cloud environments                 |

{% hint style="info" %}
Sylica primarily builds upon **OvmfPkg**, while replacing or hardening selected components to reduce the trusted computing base (TCB).
{% endhint %}

## Platform Initialization Boot Process

EDK II implements the **Platform Initialization (PI)** specification, which divides firmware execution into distinct phases.

### 1. SEC — Security Phase

The **Security (SEC)** phase is the very first code executed after CPU reset.

Responsibilities include:

* processor initialization
* temporary memory setup
* establishing the initial root of trust
* locating the firmware image
* transferring execution to PEI

At this stage only minimal CPU functionality is available. No DRAM has been initialized yet, so execution relies on temporary memory.

### 2. PEI — Pre-EFI Initialization

PEI initializes the hardware required for the remainder of the firmware.

Typical responsibilities include:

* DRAM initialization
* CPU feature discovery
* chipset initialization
* TPM discovery
* firmware volume discovery
* loading the DXE Core

PEI consists of many small **PEIMs (PEI Modules)**, each responsible for a specific initialization task.

Because PEI runs before the full firmware environment exists, modules communicate using lightweight **PPIs (PEI-to-PEI Interfaces)** rather than full UEFI protocols.

### 3. DXE — Driver Execution Environment

DXE is the largest and most feature-rich firmware phase.

Once DRAM is available, the DXE Core loads numerous DXE drivers that initialize platform functionality such as:

* PCI
* USB
* NVMe
* SATA
* network adapters
* graphics
* ACPI generation
* Secure Boot
* TPM support
* runtime services
* variable storage

Drivers communicate through dynamically published **UEFI Protocols**, which provide a service-oriented architecture rather than static device tables.

Most firmware complexity resides in DXE, making it the largest contributor to the firmware's attack surface.

### 4. BDS — Boot Device Selection

After all required drivers are loaded, the **Boot Device Selection (BDS)** phase determines which operating system should be started.

Responsibilities include:

* enumerating boot devices
* processing BootOrder variables
* launching UEFI boot applications
* loading EFI boot managers
* supporting PXE or HTTP Boot
* invoking the operating system loader

In cloud environments, this phase typically launches the EFI boot loader located on the VM's virtual disk.

### 5. Runtime Services

After the operating system calls **ExitBootServices()**, firmware relinquishes control of most hardware resources.

Only a limited set of runtime functionality remains available:

* variable services
* time services
* capsule updates
* runtime memory map
* selected security services

Boot Services are permanently disabled at this point, significantly reducing the firmware's active code during normal system operation.

## Module Communication

EDK II is intentionally designed as a loosely coupled system.

Different initialization phases use different communication mechanisms:

| Phase   | Communication                |
| ------- | ---------------------------- |
| SEC     | Handoff structures           |
| PEI     | PPIs (PEI-to-PEI Interfaces) |
| DXE     | UEFI Protocols               |
| Runtime | Runtime Services             |

This separation allows modules to be developed, tested, and replaced independently while preserving interoperability.

## Security Perspective

From a security standpoint, EDK II provides a flexible but feature-rich firmware framework. Its modularity enables broad hardware compatibility, but it also introduces a substantial trusted computing base. Numerous optional drivers, protocols, and services may be present even when they are unnecessary for a specific deployment.

For confidential virtual machines, this creates two primary concerns:

* **Attack surface:** Additional firmware modules increase the amount of privileged code executed before the operating system.
* **Measurement stability:** Changes in firmware components affect cryptographic measurements used by remote attestation.

{% hint style="info" %}
Sylica addresses these challenges by treating EDK II as a secure foundation rather than a finished product. It removes unnecessary components, minimizes the firmware footprint, hardens security-critical paths, and produces deterministic, reproducible builds. The result is a smaller, more predictable firmware image that preserves UEFI compatibility while reducing both the trusted computing base and measurement variability—properties that are essential for confidential computing deployments.
{% endhint %}