> 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/documentation/what-is-sylica.md). # What is Sylica? **Sylica** is a security-focused UEFI firmware distribution for virtual machines. It provides **CVMF (Cloud-native Virtual Machine Firmware)**, a hardened and reduced firmware derived from EDK2/OVMF for: * conventional x86 virtual machines * AMD SEV-SNP confidential virtual machines * Intel TDX confidential virtual machines Sylica is designed for environments where VM firmware is considered part of the security-critical computing base and therefore needs to be **minimal, reproducible, measurable, and independently verifiable**. Compared with the corresponding general-purpose OVMF configuration, CVMF reduces the firmware code base by **up to approximately 23.7%**, depending on the platform and build configuration. This reduction removes functionality that is unnecessary for Sylica's supported virtual-machine environments and reduces the amount of privileged pre-OS code that must be trusted, maintained, and reviewed. ### Why VM Firmware Matters Before an operating system kernel executes, the virtual machine firmware initializes the environment in which it will run. A typical boot chain is: ``` Physical CPU │ ▼ Hypervisor / VMM │ ▼ UEFI firmware │ ▼ Bootloader / UKI │ ▼ Guest kernel │ ▼ Operating system │ ▼ Application ``` UEFI firmware executes with extensive privilege and before most operating-system security controls exist. It is responsible for functions such as: * early CPU initialization; * memory initialization and discovery; * virtual-device initialization; * ACPI configuration; * UEFI Boot Services; * UEFI Runtime Services; * firmware variables; * boot-device selection; * loading EFI executables; * Secure Boot; * confidential-computing initialization. The firmware is therefore part of the VM's **Trusted Computing Base (TCB)**. For confidential VMs this becomes particularly important. SEV-SNP and TDX protect a VM from a potentially untrusted host, but firmware executes **inside that protected VM**. ``` Untrusted host Hypervisor / QEMU │ ═══════════════════╪═══════════════════ Hardware confidentiality boundary ═══════════════════╪═══════════════════ │ CVMF │ ▼ Boot workload │ ▼ Guest OS │ ▼ Application ``` Confidential computing therefore changes the firmware security question. Instead of only asking: > Can the host protect the VM? an operator must also ask: > What code is executing inside the protected VM before the operating system starts? Sylica addresses this second question. ### Sylica and CVMF Sylica and CVMF describe two related but distinct concepts. **Sylica** is the complete firmware distribution and lifecycle: ``` Sylica │ ├── CVMF source ├── pinned EDK2 ├── platform configurations ├── build environment ├── reproducible build process ├── verification tooling ├── expected measurements ├── release packages └── release provenance ``` **CVMF** is the firmware artifact produced by Sylica: ``` CVMF.fd ``` CVMF is the binary supplied to a virtual-machine runtime such as QEMU. Conceptually: ``` Sylica │ ┌────────┼────────┐ │ │ │ ▼ ▼ ▼ Source Build Verification │ │ │ └────────┼────────┘ ▼ CVMF.fd │ ▼ Virtual Machine ``` Sylica therefore provides more than a customized OVMF binary. It defines how the firmware is configured, built, reproduced, distributed, measured, and verified. ### Relationship to EDK2 and OVMF CVMF is based on **EDK2**, the open-source UEFI firmware framework. OVMF is the EDK2 platform traditionally used to provide UEFI firmware for x86 virtual machines. The relationship is: ``` EDK2 │ ├── MdePkg ├── MdeModulePkg ├── UefiCpuPkg ├── OvmfPkg └── ... │ ▼ OVMF │ │ specialized and reduced ▼ CVMF │ ▼ Sylica ``` Sylica retains the mature EDK2 firmware framework while controlling the platform configuration and selecting the components required for its supported VM environments. The objective is not to replace UEFI or reimplement EDK2. Instead, Sylica takes the existing EDK2/OVMF architecture and constrains it to a smaller and explicitly defined virtual-machine firmware profile. ### Reduced Firmware Computing Base General-purpose OVMF is designed to support a broad range of virtual-machine configurations, devices, boot methods, compatibility requirements, and development scenarios. That flexibility has a security cost. Every firmware component contributes to some combination of: * executable privileged code; * attack surface; * host-controlled input processing; * parser complexity; * dependency exposure; * maintenance effort; * vulnerability exposure; * security-review effort. Sylica follows a different principle: > Firmware functionality that is not required by the supported deployment model should not be part of the firmware computing base. CVMF therefore removes or replaces unnecessary OVMF functionality. Depending on the platform and build configuration, CVMF reduces the corresponding OVMF firmware code base by **up to approximately 30%**. Conceptually: ``` General-purpose OVMF ┌────────────────────────────────────────────┐ │ │ │ Core UEFI │ │ VM platform support │ │ broad device support │ │ multiple boot paths │ │ compatibility functionality │ │ optional firmware services │ │ development functionality │ │ additional libraries and drivers │ │ │ └────────────────────────────────────────────┘ Sylica CVMF ┌───────────────────────────────┐ │ │ │ Required UEFI core │ │ Required VM platform support │ │ Required virtual devices │ │ Controlled boot path │ │ Security services │ │ SEV-SNP / TDX integration │ │ │ └───────────────────────────────┘ up to ~23.7% less firmware code ``` The exact reduction depends on what is compared: SEV-SNP and TDX require different EDK2 components and therefore have different firmware configurations. The **23.7%** figure should consequently be understood as a **platform-dependent reduction relative to the corresponding OVMF configuration**, not as a universal reduction for every EDK2 build. ### Why Reducing the Code Base Matters Code-size reduction is not itself a security guarantee. A smaller firmware binary is not automatically more secure than a larger one. The security benefit comes from reducing the amount of **security-critical functionality** that participates in VM initialization. #### Smaller attack surface Firmware consumes input controlled by the virtual-machine environment, including: ``` Hypervisor / VMM │ ├── virtual devices ├── PCI configuration ├── MMIO ├── ACPI-related state ├── fw_cfg ├── boot media └── boot parameters │ ▼ CVMF ``` For a confidential VM, much of this data can originate from an infrastructure layer that is deliberately outside the guest's trust boundary. Removing unnecessary firmware components reduces the number of interfaces that process such input. #### Smaller TCB Every firmware module that executes before the guest kernel potentially becomes part of the VM TCB. Reducing the number of modules reduces the amount of firmware code that an operator must trust. #### Easier security review A constrained firmware configuration makes it easier to answer: * Which drivers are present? * Which host interfaces are consumed? * Which EFI applications can execute? * Which boot paths exist? * Which UEFI services remain enabled? * Which libraries contribute to the firmware? * Which components affect the VM measurement? This makes architectural review and threat modelling more tractable. #### Reduced maintenance surface A component that is not included cannot introduce a runtime vulnerability into that firmware image. Removing unnecessary functionality therefore also reduces the set of upstream vulnerabilities that need to be evaluated for applicability to a CVMF release. This does **not** mean that CVEs affecting EDK2 can automatically be ignored. Applicability must still be established from the actual CVMF dependency and module graph. ### Platform Variants Sylica provides CVMF for three primary environments. | Platform | Target | Confidential computing | | ---------------- | --------------------- | ---------------------- | | `sylica-x86` | Conventional x86 VM | No | | `sylica-sev-oss` | AMD confidential VM | AMD SEV-SNP | | `sylica-tdx-oss` | Intel confidential VM | Intel TDX | #### Conventional x86 `sylica-x86` runs on conventional x86 virtual machines. ``` x86 host │ ▼ KVM/QEMU │ ▼ CVMF │ ▼ Guest OS ``` It does not provide memory confidentiality against the host. Its security benefit is instead the use of the same controlled, reduced, reproducibly built firmware architecture used by Sylica's confidential-computing platforms. This makes the reduced firmware computing base useful even when confidential-computing hardware is not required. #### AMD SEV-SNP `sylica-sev-oss` targets AMD SEV-SNP. ``` AMD CPU │ ▼ SEV-SNP │ ▼ Confidential VM │ ▼ CVMF │ ▼ Guest OS ``` AMD SEV-SNP establishes hardware-backed memory confidentiality and integrity properties against the host. CVMF executes inside that boundary and participates in establishing the initial VM state. The resulting launch state can be verified through SEV-SNP attestation. #### Intel TDX `sylica-tdx-oss` targets Intel TDX. ``` Intel CPU │ ▼ TDX │ ▼ Trust Domain │ ▼ CVMF │ ▼ Guest OS ``` TDX establishes the hardware-backed Trust Domain boundary. CVMF provides the UEFI environment inside the TD and contributes to its measured initial state. The firmware state can subsequently be evaluated using TDX attestation evidence. ### Firmware Architecture CVMF follows the standard EDK2 execution model. A simplified boot sequence is: ``` VM reset │ ▼ SEC │ ▼ PEI / early initialization │ ▼ DXE │ ├── CPU ├── devices ├── ACPI ├── variables └── security services │ ▼ BDS │ ▼ Sylica boot policy │ ▼ EFI workload / UKI │ ▼ ExitBootServices() │ ▼ Guest OS ``` AMD SEV-SNP and Intel TDX differ in their early initialization, firmware-volume organization, and confidential-computing integration. They converge on the common UEFI environment used to boot the guest workload. See [Architecture](/sylica/tutorials/understand-the-architecture.md) for the detailed CVMF architecture. ### Reproducible Builds Reducing the firmware computing base answers: > How much firmware do I need to trust? Reproducibility answers a different question: > Does the firmware binary correspond to the source code I reviewed? Sylica builds CVMF using controlled inputs: ``` Sylica source revision + pinned EDK2 revision + pinned build environment + exact tool versions + deterministic build settings │ ▼ CVMF.fd ``` The same inputs are intended to produce a bit-identical firmware artifact. An independent party can therefore rebuild the firmware: ``` Official build Independent build │ │ ▼ ▼ CVMF.fd CVMF.fd │ │ ▼ ▼ SHA-256 SHA-256 │ │ └──────────────┬─────────────────┘ ▼ compare ``` A matching artifact provides evidence that the released firmware corresponds to the declared source and build environment. Reproducibility does not prove that the source code is free of vulnerabilities. It makes the source-to-binary relationship independently verifiable. ### Firmware Measurements For confidential computing, knowing the firmware binary is only part of the problem. An operator also needs to determine whether the expected firmware is represented in the state of a running confidential VM. Sylica therefore publishes: ``` measurements.json ``` with its platform packages. Conceptually: ``` CVMF.fd │ ├────────────► firmware SHA-256 │ └────────────► expected launch measurement │ ▼ measurements.json ``` For AMD SEV-SNP, the expected state can be compared with the applicable `MEASUREMENT` from SNP attestation evidence. For Intel TDX, the corresponding firmware measurement can be evaluated against the applicable TDX measurement state such as `MRTD`. This extends verification from the artifact to the running VM: ``` Source │ ▼ Reproducible CVMF │ ▼ Expected measurement │ ▼ Hardware attestation │ ▼ Measurement comparison │ ▼ Policy decision ``` ### Secure Boot Hardware attestation and UEFI Secure Boot provide different security properties. Confidential-computing attestation can establish information about the hardware-protected VM and its measured state. Secure Boot authenticates subsequent EFI executables. ``` Hardware │ ▼ SEV-SNP / TDX │ ▼ CVMF │ │ signature verification ▼ Authorized EFI workload │ ▼ Kernel ``` A deployment may therefore combine: * reproducible firmware; * known CVMF measurements; * hardware attestation; * Secure Boot; * signed Unified Kernel Images; * workload-level verification. These mechanisms form complementary layers rather than substitutes for each other. ### Release Provenance Sylica distributes CVMF as versioned platform packages through GitHub Releases. A release contains: ``` Sylica vX.Y.Z │ ├── platform-sylica-x86-*.tar.zst ├── platform-sylica-sev-oss-*.tar.zst ├── platform-sylica-tdx-oss-*.tar.zst │ ├── sha256sums ├── b2sums └── attestation.json ``` Each platform package contains: ``` CVMF.fd sha256sums b2sums measurements.json tools-manifest.txt license information ``` This creates a verification hierarchy: ``` Source revision │ ▼ Release workflow │ ▼ Build provenance │ ▼ Release checksums │ ▼ Platform package │ ▼ CVMF.fd │ ▼ Expected measurement ``` The release version can therefore serve as a unit of firmware deployment and attestation-policy management. ### Security Model Sylica deliberately separates the security responsibilities of the different layers. | Layer | Security responsibility | | ----------------------- | ------------------------------------------- | | AMD SEV-SNP / Intel TDX | Hardware-backed VM isolation | | CVMF | Controlled and reduced firmware environment | | Reproducible build | Source-to-binary verification | | Release provenance | Artifact origin and integrity | | Hardware measurement | Representation of VM launch state | | Attestation | Authenticated evidence about that state | | Attestation policy | Decide whether the state is approved | | Secure Boot | Authenticate subsequent EFI executables | | Guest OS | Runtime operating-system security | | Application | Workload-level security | This distinction is important. CVMF does not create the SEV-SNP or TDX hardware security boundary. Similarly, a valid CVMF hash does not prove that the firmware is running inside a particular VM. Instead, the complete trust chain combines several independent mechanisms: ``` Reviewed source │ ▼ Reproducible build │ ▼ Verified CVMF.fd │ ▼ Expected measurement │ ▼ Hardware-protected launch │ ▼ Attestation evidence │ ▼ Policy verification │ ▼ Authenticated boot workload ``` ### What Sylica Does Not Provide Sylica should not be interpreted as providing security guarantees outside its firmware role. In particular, Sylica does not by itself provide: * protection against denial of service by the host; * application isolation; * protection from a compromised guest kernel; * secure application software; * protection from vulnerabilities in the underlying CPU security architecture; * automatic trust in every valid SEV-SNP or TDX VM; * automatic rollback prevention; * proof that source code contains no vulnerabilities. These properties must be provided or evaluated by other layers of the system. ### Security Benefits The Sylica model combines three major security properties. #### 1. Minimize what must be trusted CVMF reduces the corresponding OVMF code base by up to approximately 30%. ``` Less firmware functionality │ ▼ smaller privileged code base │ ▼ smaller attack and review surface ``` #### 2. Verify what was built Reproducible builds establish a verifiable relationship between source and firmware. ``` Source │ ▼ Rebuild │ ▼ bit-identical CVMF.fd ``` #### 3. Verify what is running Confidential-computing measurements and hardware attestation extend verification into the runtime environment. ``` Expected CVMF │ ▼ Expected measurement │ ▼ Attestation evidence │ ▼ Policy decision ``` Together these answer three fundamental questions: > **What firmware do I need to trust?** A reduced and explicitly defined CVMF computing base. > **Is the distributed firmware built from the expected source?** Verify it through reproducible builds and release provenance. > **Is the expected firmware represented in the running confidential VM?** Verify it through hardware-backed measurement and attestation. ### Summary Sylica turns VM firmware from an opaque infrastructure dependency into an explicitly defined and independently verifiable component of the VM security architecture. Its core approach is: ``` General-purpose OVMF │ ▼ Remove unnecessary code │ up to ~30% │ ▼ CVMF │ ┌───────────┼───────────┐ ▼ ▼ ▼ Reduced Reproducible Measurable TCB build firmware │ │ │ └───────────┼───────────┘ ▼ Verified release │ ▼ SEV-SNP / TDX launch │ ▼ Hardware attestation │ ▼ Trust decision ``` For conventional x86 VMs, Sylica provides a reduced, controlled, and reproducible UEFI firmware environment. For AMD SEV-SNP and Intel TDX confidential VMs, Sylica additionally connects that firmware identity to the hardware-backed measurement and attestation model. The result is a firmware layer designed around three principles: > **minimize what must be trusted, verify what was built, and verify what is running**