> 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-secure-boot.md).

# UEFI Secure Boot

Paving the ground for remotely attesting the Trusted Computing Base

## Why Secure Boot Matters

In a bare metal or virtual machine, the firmware is the **first software component that executes**. Every subsequent component—the bootloader, kernel, initramfs, and ultimately user space—depends on the integrity of the firmware and the chain of software it loads.

Without boot verification, an attacker who gains access to a VM image, cloud snapshot, or provisioning pipeline could replace the operating system kernel or bootloader with a modified version. Even if the VM runs inside a Trusted Execution Environment (TEE) such as **AMD SEV-SNP** or **Intel TDX**, the TEE only guarantees that the platform measures and isolates the workload— it does **not** inherently ensure that the workload itself is trusted.

UEFI Secure Boot establishes a **cryptographic chain of trust** by requiring every executable loaded during boot to be digitally signed by a trusted authority.

For confidential computing deployments, Secure Boot provides:

* Protection against unauthorized bootloaders and kernels
* Prevention of persistent bootkits and firmware-level malware
* Stronger software supply-chain integrity
* Enforcement of enterprise signing policies
* Foundation for trustworthy remote attestation

## Secure Boot vs. Measured Boot

Secure Boot and Measured Boot are often discussed together, but they solve different security problems.

| Secure Boot                         | Measured Boot                             |
| ----------------------------------- | ----------------------------------------- |
| Enforces what is allowed to execute | Records what actually executed            |
| Blocks unauthorized software        | Never blocks execution                    |
| Uses digital signature verification | Uses cryptographic hashing                |
| Maintains a trust policy            | Produces evidence for remote verification |
| Local decision                      | Remote decision                           |

Think of the two mechanisms as complementary:

```
             Secure Boot
          "May this execute?"

                    │
          Signature verification
                    │
              Allow / Reject

                    │

             Measured Boot
      "What actually executed?"

                    │
          Hash every component
                    │
        Extend measurements
                    │
       Remote Attestation
```

> Secure Boot **prevents** unauthorized software from loading.

> Measured Boot **proves** what software was loaded.

Confidential computing platforms rely heavily on Measured Boot because remote attestation depends on deterministic firmware and software measurements. Secure Boot complements this by ensuring that only trusted components can contribute to those measurements.

## Secure Boot Architecture

UEFI Secure Boot is based on a hierarchy of cryptographic keys stored inside UEFI variables.

```
            Platform Key (PK)
                    │
                    ▼
        Key Exchange Keys (KEK)
                    │
                    ▼
      Allowed Signature Database (db)
                    │
                    ▼
     Bootloader / UKI Signature Check
```

The main databases are:

| Variable | Purpose                                       |
| -------- | --------------------------------------------- |
| PK       | Platform owner                                |
| KEK      | Delegates authority to update trust databases |
| db       | Trusted certificates and executable hashes    |
| dbx      | Revoked certificates and binaries             |

When Secure Boot is enabled, every EFI executable must verify successfully against the trusted database (`db`). If verification fails, the firmware terminates the boot process.

## Secure Boot Boot Flow

### Option 1 — Unified Kernel Image (UKI)

A **Unified Kernel Image (UKI)** packages all boot components into a single signed EFI executable.

```
Firmware
     │
     ▼
 Verify UKI Signature
     │
     ▼
Execute UKI
     │
     ├── Linux Kernel
     ├── Initramfs
     ├── Kernel Command Line
     └── OS Release Metadata
```

The UKI contains:

* Linux kernel
* initramfs
* kernel command line
* OS metadata
* optional splash image

Because everything is bundled into one EFI binary, the firmware verifies only **one signature**.

#### Advantages

* Small attack surface
* Single artifact to sign
* Deterministic measurements
* No intermediate bootloader
* Simplified CI/CD pipelines
* Preferred for confidential VMs

For cloud-native confidential workloads, UKIs provide the simplest and most reproducible boot path.

### Option 2 — Shim + Bootloader

Many enterprise Linux distributions use Microsoft's third-party UEFI signing program.

The firmware trusts Microsoft's UEFI CA, which signs **shim**.

```
Firmware
     │
Verify shim
     │
     ▼
shim
     │
Verify GRUB
     │
     ▼
GRUB
     │
Verify Linux Kernel
     │
     ▼
Operating System
```

Shim contains its own trusted certificate database (Machine Owner Keys, MOK), allowing organizations to boot custom kernels without replacing the firmware trust store.

Typical trust chain:

```
Firmware
    │
Microsoft Certificate
    │
shim
    │
MOK
    │
GRUB
    │
Linux Kernel
```

#### Advantages

* Compatible with standard Linux distributions
* Enterprise key enrollment
* MOK support
* Easy integration with existing Linux tooling

#### Disadvantages

* Additional boot stage
* Larger trusted computing base (TCB)
* More signatures to manage
* Less deterministic measurements
* Increased attack surface

## UKI vs. Shim

| Feature                          | UKI       | Shim + GRUB                                      |
| -------------------------------- | --------- | ------------------------------------------------ |
| Boot stages                      | 1         | Multiple                                         |
| EFI executables                  | One       | Several                                          |
| TCB size                         | Small     | Larger                                           |
| Boot speed                       | Faster    | Slower                                           |
| Deterministic measurements       | Excellent | Good                                             |
| Enterprise compatibility         | Good      | Excellent                                        |
| Recommended for confidential VMs | ✓         | Only when distribution compatibility is required |

### Booting a UKI with QEMU

A UKI can be started directly as the EFI boot target when placed on an EFI System Partition (ESP) or when using a firmware boot entry that points to the UKI.

**Example**:

```bash
qemu-system-x86_64 \
  -machine q35,accel=kvm \
  -cpu host \
  -m 8G \
  -drive if=pflash,format=raw,readonly=on,file=CODE.fd \
  -drive if=pflash,format=raw,file=VARS.fd \
  -drive file=disk.qcow2,if=virtio
```

The firmware's `Boot####` variable in `VARS.fd` should reference the UKI (for example, `\EFI\Linux\linux.efi`) on the EFI System Partition. This approach mirrors how physical UEFI systems boot and keeps the launch process firmware-driven rather than relying on QEMU-specific kernel loading options.

### Booting with Shim

When using shim, install the standard EFI binaries on the ESP:

```
EFI/
 ├── BOOT/
 │     BOOTX64.EFI      (shim)
 │
 ├── ubuntu/
 │     shimx64.efi
 │     grubx64.efi
 │
 └── Linux/
       vmlinuz
```

QEMU configuration is essentially identical.

**Example**:

```bash
qemu-system-x86_64 \
  -machine q35,accel=kvm \
  -cpu host \
  -m 8G \
  -drive if=pflash,format=raw,readonly=on,file=CODE.fd \
  -drive if=pflash,format=raw,file=VARS.fd \
  -drive file=disk.qcow2,if=virtio
```

The firmware follows its configured boot entry to `shimx64.efi`, which verifies GRUB. GRUB then verifies and loads the Linux kernel according to its Secure Boot policy.

> **Note:** The `-kernel` and `-initrd` QEMU command-line options bypass the UEFI boot manager and Secure Boot verification. They are useful for development and testing but should not be used when validating Secure Boot behavior or reproducing production boot flows.

## Secure Boot in Sylica

Sylica fully supports the standard UEFI Secure Boot architecture while enabling deterministic and reproducible firmware builds. It can boot either directly into a signed UKI or through a shim-based boot chain, allowing operators to balance simplicity with distribution compatibility.

Sylica fully supports the standard UEFI Secure Boot architecture while enabling deterministic and reproducible firmware builds. It can boot either directly into a signed UKI or through a shim-based boot chain, allowing operators to balance simplicity with distribution compatibility.

For confidential computing deployments, Sylica recommends:

* **Direct boot into a signed UKI** for minimal TCB, reproducible measurements, and simpler operations.
* **Shim-based boot** only when compatibility with distribution-managed Secure Boot keys or existing enterprise workflows is required.

{% hint style="info" %}
Combined with measured boot and remote attestation of Sylica, Secure Boot helps establish an end-to-end chain of trust from firmware to operating system, ensuring that confidential workloads start only from verified software and that their integrity can be demonstrated to relying services.
{% endhint %}