> 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/why-yet-another-ovmf.md). # 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 workload ``` If 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: 
Approved source code
          ↓
Reproducible firmware build
          ↓
Published firmware hash and expected measurement
          ↓
Confidential VM launch
          ↓
Remote attestation report
          ↓
Measurement comparison
          ↓
Firmware integrity decision
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: ``` Published source code ≠ Independently built binary ``` 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: ``` Reviewed source code ↓ Pinned build inputs ↓ Reproducible build ↓ Published CVMF.fd ↓ Published checksum ↓ Expected attestation measurement ``` 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: 1. **Open source**\ The firmware implementation is available for inspection. 2. **Pinned inputs**\ The source, dependencies, toolchain, and build environment are declared. 3. **Reproducible build**\ Independent builders can recreate the firmware binary. 4. **Published artifact identity**\ The release provides cryptographic hashes for the firmware. 5. **Measured launch**\ The confidential-computing platform measures the firmware during VM creation. 6. **Remote attestation**\ The running VM reports its measured identity. 7. **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 |