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
│
▼
ApplicationUEFI 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.
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:
CVMF is the firmware artifact produced by Sylica:
CVMF is the binary supplied to a virtual-machine runtime such as QEMU.
Conceptually:
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:
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:
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:
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.
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.
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 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.
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:
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 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:
The same inputs are intended to produce a bit-identical firmware artifact.
An independent party can therefore rebuild the firmware:
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:
with its platform packages.
Conceptually:
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:
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.
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:
Each platform package contains:
This creates a verification hierarchy:
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.
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:
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%.
2. Verify what was built
Reproducible builds establish a verifiable relationship between source and firmware.
3. Verify what is running
Confidential-computing measurements and hardware attestation extend verification into the runtime environment.
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:
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
Last updated