Why yet another OVMF
Firmware is the software root of trust
Before a confidential VM can run its operating system or workload, platform firmware initializes the virtual machine and establishes the initial execution state. It configures the boot environment, initializes platform-specific functionality, and controls how subsequent softwre is loaded.
For this reason, the firmware forms the software root of trust for the confidential VM.
The trust chain can be represented as:
Hardware security mechanisms
↓
Confidential VM firmware
↓
Guest bootloader or kernel
↓
Guest operating system
↓
Application and workloadIf the firmware is modified, compromised, or built from an unknown source, the security of every component above it is affected. Encryption and memory isolation cannot compensate for firmware that cannot be trusted.
Firmware integrity is part of attestation
Remote or local attestation provides cryptographic evidence about the environment in which a workload is running. As part of the VM launch process, the platform measures the firmware into a launch measurement or measurement register.
For AMD SEV-SNP, the initial guest memory contents—including the firmware—are incorporated into the launch digest reported in the attestation report verification (1).md. For Intel TDX, firmware contributes to the measured boot state and RTMR values.
A verifier can compare the measurement reported by the running VM with an expected value generated from an approved firmware release. A matching value provides evidence that the VM was launched with the approved firmware and corresponding configuration.
The verification flow is:
The firmware measurement is therefore not an optional metadata value. It is a central part of proving the integrity of the environment in which the workload executes.
Measurement establishes identity, not complete security
A valid firmware measurement proves that the measured firmware corresponds to an approved value. It does not automatically prove that the entire workload is secure.
A production verifier must also consider:
The guest kernel and initrd
The guest command line
The VM's vCPU and memory configuration
The hypervisor and cloud platform
The guest operating system
The workload identity and policy
The validity of the attestation report
The platform certificate chain
When direct kernel boot is used with kernel-hashes=on, the injected kernel, initrd, and command line are included in the same launch measurement verification. This allows the attestation policy to bind the VM identity to more than the firmware alone.
Why the firmware must be open
A root of trust must be independently inspectable.
The firmware source code should be open so that customers, security teams, and independent auditors can:
Review the implementation
Identify unexpected behavior
Inspect security-sensitive changes
Analyze dependencies
Compare platform-specific modifications with upstream code
Rebuild the firmware independently
Confirm that the published binary corresponds to the reviewed source
Open source does not automatically make firmware secure. It does, however, make independent verification possible. Without access to the source, users must trust the firmware provider’s claims without being able to inspect or reproduce the artifact themselves.
For confidential computing, this distinction is particularly important. The firmware is not an ordinary boot component: it is part of the measured identity presented during remote attestation.
Reproducible builds make the root of trust verifiable
Source availability is only one part of the verification process. An auditor must also be able to build the source and obtain the same binary that was released.
Historically, open VM firmware projects could still be difficult to reproduce. Differences in toolchains, package versions, build timestamps, dependency resolution, and build environments could produce different binaries from the same source tree.
This creates a verification gap:
In that situation, users can inspect the source, but cannot confidently establish that the deployed firmware was produced from it.
Sylica is designed to reduce this gap through a controlled and reproducible build process. The build pins the edk2 source tree, container image, package versions, apt snapshot, and build timestamp. Compilation is performed in an isolated container, including a network-disabled compilation stage verification (1).md.
The resulting release includes the firmware image, checksums, toolchain information, and build-environment metadata needed for independent verification verification (1).md.
The intended relationship is:
An independent party can rebuild the firmware and compare its hash with the published artifact:
sha256sum out/sylica-sev/CVMF.fd
The result should match the release checksum. This provides evidence that the firmware used in deployment corresponds to the publicly inspectable source and declared build environment.
Unified firmware images and measurement
Sylica uses a unified CVMF.fd image containing both firmware code and variable storage. The image is passed to QEMU using -bios platforms.
This design keeps the firmware code and variable store within one measured binary. A separate writable variable-store image could exist outside the launch measurement, making it harder to establish exactly which firmware state was used during VM launch.
Secure Boot variables are also measured as part of the firmware state. Consequently, an attestation report can provide evidence about which Secure Boot variables are in effect verification.
The Sylica trust model
The security model depends on several independently verifiable links:
Open source The firmware implementation is available for inspection.
Pinned inputs The source, dependencies, toolchain, and build environment are declared.
Reproducible build Independent builders can recreate the firmware binary.
Published artifact identity The release provides cryptographic hashes for the firmware.
Measured launch The confidential-computing platform measures the firmware during VM creation.
Remote attestation The running VM reports its measured identity.
Policy enforcement A verifier compares the attested value with an approved measurement before authorizing the workload or releasing secrets.
The resulting trust chain is:
Open source → Audited implementation → Reproducible build → Verified firmware artifact → Measured VM → Remote attestation → Policy-controlled workload access
What this proves
When all parts of the process are correctly implemented, a matching attestation measurement provides evidence that:
The VM was launched with the expected firmware
The firmware corresponds to an approved release
The release can be traced to inspectable source code
The released binary can be independently rebuilt and verified
The measured boot state satisfies the deployment policy
This is the foundation on which higher-level confidential-computing guarantees are built.
Sylica CVMF vs. Upstream OVMF
Sylica is a security-focused confidential VM firmware distribution, while upstream OVMF is the reference edk2 virtual-machine firmware project, maintained as the baseline implementation of the UEFI standard.
Primary purpose
Production-oriented confidential VM firmware for Sylica deployments
General-purpose open virtual-machine firmware and upstream reference implementation
Source base
Built from edk2 with Sylica platform changes in SylicaPkg
Built from the upstream edk2 OVMF packages
Confidential-computing targets
Provides platform variants for AMD SEV-SNP and Intel TDX
Provides upstream platform recipes, including AmdSev and Intel TDX
AMD SEV-SNP configuration
SylicaPkg/SylicaPkgSev.dsc
Upstream OvmfPkg/AmdSev/AmdSevX64.dsc recipe
Intel TDX configuration
SylicaPkg/SylicaPkgTdx.dsc
Upstream OvmfPkg/IntelTdx/IntelTdxX64.dsc recipe
QEMU integration
Passed as a unified BIOS image with -bios CVMF.fd
Typically passed as an OVMF firmware image, commonly using OVMF.fd
Variable store
Kept inside the unified measured image; split CODE/VARS images are not used
Upstream deployments commonly distinguish firmware code and variable-store images
Secure Boot
Enabled in the SEV-SNP variant
Depends on the upstream build and configuration
Dynamic stack cookies
Enabled by default
Not identified as a Sylica-specific feature in the upstream reference build
Platform boot manager
Replaced with SylicaOss/Library/PlatformBootManager
Uses the upstream edk2 platform boot manager
TDX library configuration
Uses GenericQemuLoadImageLib to align with the AmdSev package
Uses the upstream Intel TDX configuration, including X86QemuLoadImageLib
TDX flash-device name
Renamed to CVMF_TDX
Uses the upstream Intel TDX naming
Build model
Reproducible build with pinned source, container, package snapshot, and build timestamp
Built according to the upstream edk2 recipe
Release verification
Publishes firmware hashes, measurements, toolchain information, and build-environment metadata
Used primarily as an upstream reference and comparison build
Reproducibility role
Target firmware whose output must be reproducible
Reference or canary used to identify infrastructure and toolchain problems
Measurement role
Provides Sylica firmware hashes and platform-specific measurements
Provides a known-good upstream baseline for comparison
Operational status
Intended for Sylica confidential VM deployments
Reference firmware; not the Sylica production image
Recommended use
Deploy when the workload requires the Sylica firmware configuration
Use for upstream compatibility testing, debugging, and differential analysis
Last updated