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

# Sylica

Cloud-native VM firmware distribution with automatable and reproducible builts, published firmware hashes and attestable measurements for Confidential Computing platforms.

## Introduction

Before the operating system, kernel, or applications begin executing, the virtual machine firmware is the **first software loaded inside the protected virtual machine**. It initializes the virtual hardware, configures the execution environment, measures the software that follows, and transfers control to the operating system. In doing so, the firmware establishes the **root of trust** for the entire virtual machine.

> Every subsequent security guarantee—including secure boot, measured boot, remote attestation, and policy-based secret release—depends on the integrity of this firmware.

### Why Traditional Firmware Is Not Designed for Cloud Virtualization

Traditional UEFI firmware was designed around the requirements of physical PCs and servers. Over decades, it accumulated functionality needed to discover unpredictable hardware, support interchangeable peripherals, maintain compatibility with legacy operating systems, and provide rich pre-boot environments. These capabilities make sense when firmware must boot a wide range of physical machines. They are much less relevant when the "machine" is a virtual machine whose hardware configuration is created and controlled by a hypervisor.

A cloud VM typically exposes a small and predictable set of virtual devices. CPU topology, memory, storage, networking, entropy sources, and boot devices are defined by the virtualization platform before the VM starts. There is little reason for the firmware to carry broad support for hardware that can never appear inside that VM.

General-purpose firmware nevertheless often retains this functionality. The result can include drivers for unused devices, legacy boot mechanisms, compatibility protocols, network boot stacks, filesystems, configuration interfaces, and other services that exist primarily because conventional UEFI needs to support many different deployment environments.

For cloud virtualization, this creates several disadvantages:

* **Larger trusted computing base.** Every firmware component executing before the operating system potentially becomes part of the VM's trusted computing base. Code that provides no functionality required by the workload still contributes implementation complexity and potential attack surface.
* **Unnecessary attack surface.** Parsers, device drivers, network protocols, filesystem implementations, and compatibility layers process potentially complex inputs. Removing components that cannot be used by the VM eliminates entire classes of code paths rather than attempting to secure functionality that is unnecessary in the first place.
* **More complex measurements.** In confidential computing, firmware is not merely boot code—it contributes to the cryptographic identity of the VM. AMD SEV-SNP and Intel TDX allow relying parties to reason about the initial state of a confidential VM through measurements. A smaller and more deterministic firmware image makes that state easier to reproduce, publish, verify, and include in attestation policies.
* **Poorer reproducibility and auditability.** Large general-purpose firmware builds contain many components, dependencies, configuration options, and generated artifacts. Reducing the firmware to the functionality required for a defined cloud VM profile makes it easier to understand what was built, reproduce the binary, review changes, and determine why a measurement changed between releases.
* **Features optimized for physical machines rather than ephemeral VMs.** Physical firmware traditionally has a lifecycle tied to a server or motherboard. Cloud VMs are created, destroyed, migrated, rebuilt, and upgraded through automated infrastructure. Their firmware should fit this operational model as a versioned and immutable infrastructure artifact rather than behaving like motherboard firmware.

### Why a minimal Trusted Computing Base matters

Every line of firmware code becomes part of the Trusted Computing Base (TCB)—the collection of components that must operate correctly to preserve the confidentiality and integrity of the workload.

General-purpose UEFI firmware distributions often include thousands of files, numerous device drivers, networking components, legacy hardware support, and functionality that is unnecessary for cloud-hosted virtual machines. While valuable for physical systems, these components increase firmware complexity, enlarge the attack surface, and make security auditing significantly more difficult.

### Why Confidential Computing starts with trusted firmware

Confidential computing protects workloads by executing them inside hardware-enforced Trusted Execution Environments (TEEs), such as **AMD SEV-SNP**, **Intel TDX** and (soon) **ARM CCA** . These technologies encrypt and isolate the memory of a virtual machine, preventing cloud operators, hypervisors, and other privileged software from accessing the workload. However, confidential computing is only as trustworthy as the firmware that establishes the execution environment.

{% hint style="danger" %}
If the firmware cannot be trusted, neither can the measurements nor the attestation report derived from it.
{% endhint %}

### Why reproducible firmware is essential

Remote attestation allows a relying party to verify the software executing inside a confidential virtual machine before releasing secrets or granting access to protected services.

This verification depends on firmware measurements. Yet a measurement is only meaningful if it can be independently reproduced and verified.

Without reproducible builds, organizations must trust that a distributed firmware binary actually corresponds to its published source code. There is no practical way to determine whether the binary contains undocumented modifications, compiler differences, supply-chain compromises, or unintended changes.

## Verifiable Firmware for Virtual Machines

Sylica is a source-available, enterprise-grade UEFI firmware distribution for virtual machines, engineered for confidential and non-confidential computing environments. Sylica is designed around a different principle:

> **Only include the firmware components required to establish a secure virtual machine.**

By removing unnecessary functionality, Sylica delivers:

* a substantially smaller Trusted Computing Base;
* reduced firmware attack surface;
* faster security review and vulnerability assessment;
* fewer dependencies on rarely used code paths;
* more stable firmware measurements for remote attestation.

Sylica enables organizations to establish an independent **root of trust for virtual machines**.

Rather than extending trust to firmware distributed by a cloud provider or virtualization platform, Sylica allows platform operators to build, verify, measure, and distribute firmware through their own controlled software supply chain.

The result is a firmware foundation that is:

* **Minimal and purpose-built** — only the components required for confidential virtual machines.
* **Measurable** — deterministic firmware measurements suitable for attestation.
* **Reproducible** — independently verifiable from source.
* **Auditable** — transparent build inputs and release process.
* **Attestable** — prove remotely which firmware version paves the ground for the (confidential) execution environment.
* **Enterprise-ready** — maintained through continuous vulnerability monitoring, security updates, and a controlled release lifecycle.

For organizations adopting confidential computing, the firmware is not simply another software component—it is the foundation upon which every subsequent trust decision is built. Cobalt provides that foundation.

### Key Features

<table data-view="cards"><thead><tr><th></th></tr></thead><tbody><tr><td>Minimal trusted computing base</td></tr><tr><td>Automatable reproducible firmware builds</td></tr><tr><td>Deterministic measurements</td></tr><tr><td>UEFI compatible firmware for any VM</td></tr><tr><td>Source available and auditable</td></tr><tr><td>Enterprise vulnerability lifecycle</td></tr><tr><td>Reduced boot time and memory fingerprint</td></tr><tr><td>AMD SEV, Intel TDX and ARM CCA distributions</td></tr><tr><td>Controlled firmware supply chain</td></tr></tbody></table>

## Getting started

{% content-ref url="/pages/BnJnGdDK7URsbZ0UsbWH" %}
[Documentation](/sylica/documentation.md)
{% endcontent-ref %}

{% content-ref url="/pages/XfQpQhlkb7LU2AiGwleg" %}
[Tutorials](/sylica/tutorials.md)
{% endcontent-ref %}

{% content-ref url="/pages/KGADD8pYX3extNt0kYKZ" %}
[Knowledge Base](/sylica/knowledge-base.md)
{% endcontent-ref %}

## Learn more

<table data-view="cards"><thead><tr><th data-type="content-ref"></th><th></th></tr></thead><tbody><tr><td><a href="https://docs.enclaive.cloud/enclaive-multi-cloud-platform/">Enclaive Multi Cloud Platform</a></td><td>Confidential Multi Cloud Platform</td></tr><tr><td><a href="https://docs.enclaive.cloud/virtual-hsm/">Virtual HSM</a></td><td>Hardware graded key, identity and workload access management</td></tr><tr><td><a href="https://docs.enclaive.cloud/vault/">Vault</a></td><td>Key, identity and access management</td></tr><tr><td><a href="https://docs.enclaive.cloud/nitride/">Nitride</a></td><td>Workload identity and access management</td></tr><tr><td><a href="broken://spaces/JCiJp92CK5rDzO9DECIa">Broken link</a></td><td>Confidential virtualisation</td></tr><tr><td><a href="broken://spaces/2TGGyMVhS5NRcNQJhHpN">Broken link</a></td><td>Confidential kubernetes</td></tr></tbody></table>