> 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/getting-started/release-model.md). # Release Model Sylica releases provide versioned, reproducible, and independently verifiable CVMF firmware artifacts for each supported platform. A release combines three layers: ``` Sylica Release │ ├── Release provenance │ ├── sha256sums │ ├── b2sums │ └── attestation.json │ ├── Platform packages │ ├── platform-sylica-x86-.tar.zst │ ├── platform-sylica-sev-oss-.tar.zst │ ├── platform-sylica-tdx-oss-.tar.zst │ ├── platform-debug-sev-.tar.zst │ └── platform-debug-tdx-.tar.zst │ └── Test package └── sylica-x86-test-.tar.zst ``` Each release is associated with a Git tag and contains the firmware, build metadata, measurements, checksums, and provenance information required to identify and independently verify the released firmware. ### Release lifecycle A release is created when a version tag matching `v*` is pushed to the repository. The release pipeline performs the following sequence: ``` Git tag │ ▼ Create build environment │ ▼ Pin build environment by digest │ ▼ Build all platforms │ ▼ Generate firmware hashes and measurements │ ▼ Assemble platform packages │ ▼ Generate release checksums │ ▼ Create build attestation │ ▼ Create GitHub Release │ ▼ Publish ``` All supported platforms are built as part of the same release workflow. The current build matrix contains: | Platform | Purpose | | ---------------- | ------------------------------------------- | | `sylica-x86` | CVMF for conventional x86 virtual machines | | `sylica-sev-oss` | CVMF for AMD SEV-SNP confidential VMs | | `sylica-tdx-oss` | CVMF for Intel TDX confidential VMs | | `debug-sev` | EDK2/OVMF SEV reference and debugging build | | `debug-tdx` | EDK2/OVMF TDX reference and debugging build | The `debug-*` artifacts are primarily intended for development, comparison, debugging, and reproducibility analysis. Operators normally use one of the `sylica-*` packages. ### Release structure A published release has the following conceptual structure: ``` Sylica vX.Y.Z │ ├── platform-sylica-x86-vX.Y.Z.tar.zst ├── platform-sylica-sev-oss-vX.Y.Z.tar.zst ├── platform-sylica-tdx-oss-vX.Y.Z.tar.zst │ ├── platform-debug-sev-vX.Y.Z.tar.zst ├── platform-debug-tdx-vX.Y.Z.tar.zst │ ├── sylica-x86-test-vX.Y.Z.tar.zst │ ├── sha256sums ├── b2sums └── attestation.json ``` The GitHub release notes additionally contain: * the firmware SHA-256 hashes; * information about the build environment; * verification instructions; * extraction instructions; * reproducibility instructions; * measurement instructions; * test instructions. ### Platform packages Each firmware platform is distributed independently. For example: ``` platform-sylica-sev-oss-vX.Y.Z.tar.zst ``` contains the complete release information for the AMD SEV-SNP CVMF variant. After extraction, the package conceptually contains: ``` platform-sylica-sev-oss/ │ ├── CVMF.fd ├── sha256sums ├── b2sums ├── measurements.json ├── tools-manifest.txt │ ├── LICENSE ├── LICENSE_NFSL-1.0.md ├── LICENSE_SYLICA.md └── NOTICE.md ``` The package is designed to be self-contained. An operator does not need the Sylica source repository merely to deploy and verify the firmware. #### `CVMF.fd` `CVMF.fd` is the deployable firmware image. It is the file supplied to the VM runtime, for example: ```bash qemu-system-x86_64 \ ... \ -bios CVMF.fd ``` The firmware differs between platforms. Always use the firmware from the package corresponding to the VM technology. Do not use `sylica-x86` firmware as a substitute for `sylica-tdx-oss` or `sylica-sev-oss` when creating a confidential VM. #### `sha256sums` `sha256sums` contains SHA-256 digests for the files generated by the platform build. Verify the package with: ```bash sha256sum -c sha256sums ``` For the firmware, this establishes: ``` downloaded CVMF.fd │ ▼ SHA-256 │ ▼ expected package hash │ match? / \ yes no │ │ ▼ ▼ accept reject ``` A mismatch indicates that the file is not identical to the firmware produced by the corresponding release build. #### `b2sums` `b2sums` provides an additional BLAKE2 digest set. Verify it with: ```bash b2sum -c b2sums ``` Both checksum sets are generated as part of the reproducible build. #### `tools-manifest.txt` `tools-manifest.txt` records the build-tool environment used to create the firmware. Sylica release builds use a controlled Ubuntu 22.04-based build environment with exact package versions. The manifest supports independent reproduction by documenting the tools that participated in the build. It should be considered build provenance rather than runtime configuration. #### `measurements.json` `measurements.json` connects a released CVMF artifact to confidential-computing verification. It contains the firmware hash and precomputed launch measurements for supported configurations. Conceptually: ``` Source │ ▼ CVMF.fd │ ├──────────────► SHA-256 │ └──────────────► expected CC measurement │ ▼ measurements.json ``` For AMD SEV-SNP, the expected measurement can be compared with the `MEASUREMENT` represented by the SNP attestation evidence. For Intel TDX, the corresponding firmware measurement can be compared with the expected TDX measurement, such as `MRTD`, according to the deployment and measurement model. A valid firmware checksum and a valid confidential-computing measurement answer different questions: | Verification | Question | | ----------------------- | -------------------------------------------------------------------------- | | Firmware checksum | Is this the expected `CVMF.fd` artifact? | | Release provenance | Did the expected release process produce the artifact metadata? | | Reproducibility | Can the artifact be independently rebuilt from the declared source? | | Attestation measurement | Is the expected firmware/configuration running inside the confidential VM? | ### Deterministic archives Platform packages themselves are constructed deterministically. The release workflow creates archives using normalized: * file ordering; * timestamps; * owner IDs; * group IDs. The archive creation uses equivalent controls to: ```bash tar \ --sort=name \ --mtime='@0' \ --owner=0 \ --group=0 \ --numeric-owner \ ... ``` and compresses the result using Zstandard. This prevents irrelevant filesystem metadata such as local usernames or modification timestamps from making release packages unnecessarily different. ### Release-level checksums Checksums exist at two levels. #### Package-level checksums Inside each platform package: ``` platform-sylica-x86/ │ ├── CVMF.fd ├── sha256sums └── b2sums ``` These verify the firmware and other platform build outputs. #### Release-level checksums The GitHub release additionally contains: ``` sha256sums b2sums ``` covering the assembled release assets. The complete hierarchy is therefore: ``` Release │ ├── release checksum │ │ │ ▼ │ platform archive │ │ │ ▼ │ package checksum │ │ │ ▼ │ CVMF.fd │ └── attestation ``` This allows verification of both the downloaded archive and the firmware contained within it. ### Release attestation The release contains: ``` attestation.json ``` The release workflow creates provenance for the release checksum manifests: ``` sha256sums b2sums │ ▼ GitHub Actions attestation │ ▼ attestation.json ``` The attestation binds the checksum manifests to the GitHub Actions release process and source revision. This provides a stronger verification model than checksums alone. A checksum can establish: > The file I downloaded is identical to the file represented by this checksum. Release provenance additionally helps establish: > The checksum information was produced by the expected Sylica release process from the expected source revision. The intended trust chain is: ``` Sylica source revision │ ▼ GitHub release workflow │ ▼ reproducible platform builds │ ▼ platform packages │ ▼ release checksum manifests │ ▼ GitHub attestation ``` ### Build environment The release workflow first constructs the build environment used by the platform builds. The environment is published as a container image and subsequently referenced by its immutable digest: ``` ghcr.io/enclaive/sylica/build-env@sha256: ``` The platform builds therefore consume an immutable build environment rather than relying on a mutable image tag. Conceptually: ``` Ubuntu snapshot + exact packages + build configuration │ ▼ build-env container │ ▼ immutable digest │ ▼ all platform builds ``` This environment is shared across the platform builds belonging to the release. The exact tool versions are additionally recorded in each platform package through `tools-manifest.txt`. ### Reproducibility Every production release is intended to be independently reproducible. The release records sufficient information to establish the chain: ``` Git tag │ ├── Sylica source ├── pinned EDK2 source ├── build environment digest ├── exact tool versions └── deterministic build configuration │ ▼ CVMF.fd ``` An independent verifier can check out the release tag and reproduce a selected platform: ```bash git checkout export BUILD_ENV= scripts/verify-reproducibility.sh ``` The reproduced firmware should be bit-identical to the released `CVMF.fd`. See [Reproducible Builds](/sylica/tutorials/reproducing-builds.md) for the complete reproducibility model. ### Test package Each release also contains: ``` sylica-x86-test-.tar.zst ``` This package is separate from the firmware packages and provides a convenient environment for testing CVMF. It contains: ``` test-assets/ ├── bzImage ├── initrd.img ├── Shell.efi └── readme.md ``` The generated `readme.md` contains the QEMU launch instructions corresponding to the test environment. The test package allows the basic CVMF boot path to be exercised without requiring AMD SEV-SNP or Intel TDX hardware. This is useful for: * installation testing; * firmware smoke tests; * QEMU integration testing; * CI; * development; * verifying a downloaded release before deployment. The test package does **not** reproduce the hardware security properties of an SEV-SNP or TDX VM. ### Choosing an artifact Most users need exactly one platform archive. | Target | Download | | ------------------------- | ------------------------------------------- | | Conventional x86 VM | `platform-sylica-x86-.tar.zst` | | AMD SEV-SNP VM | `platform-sylica-sev-oss-.tar.zst` | | Intel TDX VM | `platform-sylica-tdx-oss-.tar.zst` | | Basic firmware test | `sylica-x86-test-.tar.zst` | | SEV development/reference | `platform-debug-sev-.tar.zst` | | TDX development/reference | `platform-debug-tdx-.tar.zst` | The `debug-*` packages should not normally be selected for production deployments. ### Recommended verification workflow For production use, downloading `CVMF.fd` alone is not the recommended workflow. The complete verification path is: ``` Download release │ ▼ Verify release provenance │ ▼ Verify platform archive │ ▼ Extract package │ ▼ Verify package checksums │ ▼ Use CVMF.fd │ ▼ Launch confidential VM │ ▼ Obtain attestation evidence │ ▼ Compare expected measurement │ ▼ Apply attestation policy ``` These checks provide different levels of assurance and should not be treated as interchangeable. For development or evaluation, verifying the package checksum may be sufficient. For production confidential-computing deployments, release provenance, firmware identity, and runtime attestation should all be considered. ### Relationship between release and runtime trust The release model establishes a chain from source code to a known firmware artifact: ``` Source │ ▼ Reproducible build │ ▼ Release │ ▼ Verified CVMF.fd ``` Confidential-computing attestation extends this chain into the runtime environment: ``` Verified CVMF.fd │ ▼ SEV-SNP / TDX launch │ ▼ Hardware measurement │ ▼ Attestation evidence │ ▼ Verifier ``` Together they answer two fundamental questions: **Supply-chain verification** > Which source and build process produced this firmware? **Runtime verification** > Is the expected firmware executing in the confidential VM? CVMF's release model is designed to make both questions independently verifiable. ### Release artifacts and source code A Sylica release represents an immutable version of: ``` source revision + platform configuration + EDK2 revision + build environment + firmware artifacts + expected measurements ``` Operators should therefore treat the release version as the unit of firmware deployment and policy management. For example, an attestation allowlist should reference approved measurements associated with specific CVMF releases rather than accepting any syntactically valid SEV-SNP or TDX attestation. When a release is no longer approved because of a security vulnerability, its corresponding firmware measurements should also be removed from the deployment's attestation policy. ### Release security properties The release architecture provides complementary security controls: | Control | Purpose | | ------------------------ | ------------------------------------------------- | | Git tag | Identifies the source release | | Pinned EDK2 | Fixes the upstream firmware source | | Build environment digest | Fixes the build environment | | `tools-manifest.txt` | Records exact build tools | | Reproducible build | Enables source-to-binary verification | | `sha256sums` | Identifies artifacts cryptographically | | `b2sums` | Provides an additional artifact digest | | Deterministic archives | Removes irrelevant package variability | | `attestation.json` | Provides release provenance | | `measurements.json` | Connects firmware releases to runtime attestation | No single control establishes the complete trust chain. The release model combines them so that firmware can be traced from source through build and distribution to confidential-VM execution.