> 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/trust-but-reproduce.md). # Trust-but-Reproduce This guide shows how to verify, extract, reproduce, measure, and test a downloaded Sylica CVMF release. {% hint style="info" %} The examples use **v1.1.0**. Replace the version, source commit, and build-environment digest when working with another release. {% endhint %} ### Prerequisites Install the following tools: ```bash sudo apt install \ git \ zstd \ coreutils \ jq xxd ``` Install the GitHub CLI (`gh`) and Docker or another container runtime if you want to reproduce the firmware. Clone Sylica when performing reproducibility or measurement verification: ```bash git clone --recursive https://github.com/enclaive/sylica.git cd sylica ``` The release itself can be downloaded from the Sylica GitHub Releases page. ### 1. Verify the release Always verify the release **before extracting or using its firmware**. A Sylica release provides three complementary integrity mechanisms: ``` GitHub attestation │ ▼ release checksum manifests │ ▼ platform archives │ ▼ package checksums │ ▼ CVMF.fd ``` The top-level `sha256sums` and `b2sums` files cover the release artifacts. `attestation.json` provides provenance for those checksum manifests. #### Verify provenance Obtain the GitHub trusted root: ```bash gh attestation trusted-root > trusted_root.json ``` Verify both release checksum manifests against the release attestation: ```bash for sums in sha256sums b2sums; do gh attestation verify \ -b attestation.json \ -R enclaive/sylica \ --custom-trusted-root trusted_root.json \ --source-digest 9e2684d5606b5aa67509060caa49e47c2baebc1b \ --signer-digest 9e2684d5606b5aa67509060caa49e47c2baebc1b \ "$sums" done ``` The source and signer digest must correspond to the Git commit associated with the release. For another release, do not reuse the digest from this example. #### Verify downloaded release assets After establishing the provenance of the checksum manifests, verify the downloaded files: ```bash sha256sum -c --ignore-missing sha256sums b2sum -c --ignore-missing b2sums ``` Every downloaded asset covered by the manifests should report: ``` : OK ``` Do not use an artifact whose checksum fails. ### 2. Extract the platform packages Create a directory for the release: ```bash mkdir -p v1.1.0 ``` Extract the packages you need. For all firmware platforms: ```bash tar -C v1.1.0 -xf platform-debug-sev-v1.1.0.tar.zst tar -C v1.1.0 -xf platform-debug-tdx-v1.1.0.tar.zst tar -C v1.1.0 -xf platform-sylica-sev-oss-v1.1.0.tar.zst tar -C v1.1.0 -xf platform-sylica-tdx-oss-v1.1.0.tar.zst tar -C v1.1.0 -xf platform-sylica-x86-v1.1.0.tar.zst ``` Most users need only one production package: | VM type | Package | | ---------------- | --------------------------- | | Conventional x86 | `platform-sylica-x86-*` | | AMD SEV-SNP | `platform-sylica-sev-oss-*` | | Intel TDX | `platform-sylica-tdx-oss-*` | The `debug-sev` and `debug-tdx` packages are upstream reference builds intended primarily for development, comparison, and reproducibility diagnostics. #### Verify extracted packages Each package contains its own checksums. Verify all extracted packages with: ```bash for dir in v1.1.0/*/; do ( cd "$dir" && b2sum -c b2sums && sha256sum -c sha256sums ) done ``` This establishes two levels of integrity: ``` release checksum │ ▼ platform-*.tar.zst │ ▼ package checksum │ ▼ CVMF.fd ``` ### 3. Inspect the firmware The production packages contain the deployable firmware: ``` CVMF.fd ``` For example: ```bash ls -lh v1.1.0/platform-sylica-x86/CVMF.fd ``` Calculate its SHA-256 digest: ```bash sha256sum v1.1.0/platform-sylica-x86/CVMF.fd ``` For v1.1.0, the expected firmware hashes are: | Platform | SHA-256 | | ---------------- | ------------------------------------------------------------------ | | `debug-sev` | `3651e4a2077a411f9c763c4d5df1818652cc6b824f9efb095e5aabcd69f03f0b` | | `debug-tdx` | `48c3a18691b199aca596c36bdb979d82859c7d7fe764de6738c2269c6ea97fc4` | | `sylica-sev-oss` | `9a97a52257cfcdd22c5271ef6a119d43fb4ba76b71e505748c02367ea43b2fae` | | `sylica-tdx-oss` | `9e76edd0a5fc0625a4b9b3c263f88efcc83abe49fdc8f7a90851e234abf62f3e` | | `sylica-x86` | `9a97a52257cfcdd22c5271ef6a119d43fb4ba76b71e505748c02367ea43b2fae` | {% hint style="info" %} `sylica-sev-oss` and `sylica-x86` intentionally produce the same firmware image for this release. The SEV-capable CVMF firmware can also operate as conventional x86 VM firmware when the VM is launched without an SEV context. {% endhint %} ### 4. Inspect the build environment Each platform package contains: ``` tools-manifest.txt ``` The release is built from a pinned Ubuntu 22.04 snapshot with exact package versions. Inspect the build environment with: ```bash cat v1.1.0/platform-sylica-x86/tools-manifest.txt ``` The manifest records the tools used to produce the firmware and is useful when reviewing or independently reproducing the release. ### 5. Reproduce the firmware Reproducibility verifies that the released `CVMF.fd` can be independently regenerated from the corresponding source and build environment. Check out the exact release: ```bash git checkout v1.1.0 ``` Set the immutable build-environment image published for the release: ```bash export BUILD_ENV=ghcr.io/enclaive/sylica/build-env@sha256:67c89af826981b6dcbe5605f558458e245b1a3fbbaa4d180c008a8bb912a50c4 ``` Then reproduce a platform: ```bash scripts/verify-reproducibility.sh ``` For example: ```bash scripts/verify-reproducibility.sh sylica-x86 ``` or: ```bash scripts/verify-reproducibility.sh sylica-sev-oss ``` A successful verification means that an independent build produced the same firmware artifact as the release. Conceptually: ``` released CVMF.fd source v1.1.0 │ │ │ ▼ │ pinned build environment │ │ ▼ ▼ SHA-256 ◄────────────── reproduced CVMF.fd │ ▼ match ``` For another release, use the build-environment digest published with that release. See [Reproducible Builds](/sylica/tutorials/reproducing-builds.md) for the complete reproducibility model. ### 6. Verify the measurements Each platform package contains: ``` measurements.json ``` It records the firmware hash and, where applicable, precomputed confidential-computing launch measurements. Inspect it with: ```bash cat v1.1.0/platform-sylica-sev-oss/measurements.json ``` To independently regenerate the measurement: ```bash TARGET=v1.1.0/platform- verify/file.sh \ "$TARGET/CVMF.fd" \ > measurements.json ``` where `` is either * measure\_none * measure\_snp * measure\_tdx Compare the generated measurement with the released value: ```bash diff -s \ measurements.json \ "$TARGET/measurements.json" ``` No difference should be reported. The measurement mode depends on the selected platform and confidential-computing technology. See [Verification and Usage](/sylica/tutorials/verifying-reproducible-builds.md) for the supported modes and measurement parameters. #### Firmware hash vs. launch measurement Do not confuse the two: ``` CVMF.fd │ ├── SHA-256 │ │ │ └── identifies the firmware artifact │ └── launch measurement │ └── identifies confidential VM launch state ``` Both are useful, but they answer different questions. ### 7. Compare against attestation For a running confidential VM, compare the expected measurement from: ``` measurements.json ``` with the measurement reported by the hardware-backed attestation evidence. For **AMD SEV-SNP**, compare against the applicable: ``` MEASUREMENT ``` For **Intel TDX**, compare against the applicable: ``` MRTD ``` The expected flow is: ``` released CVMF.fd │ ▼ measurements.json │ │ expected ▼ launch digest │ │ compare ▼ MEASUREMENT / MRTD │ ▼ attestation policy ``` A valid attestation signature alone is not sufficient. The reported measurement must correspond to a firmware and VM configuration approved by the verifier. See [Verification and Usage](/sylica/tutorials/verifying-reproducible-builds.md) for the platform-specific procedure. ### 8. Test CVMF without confidential hardware The release contains a separate test package: ``` sylica-x86-test-v1.1.0.tar.zst ``` It allows the basic CVMF boot path to be tested on a conventional x86 KVM/QEMU host. You do **not** need an AMD SEV-SNP or Intel TDX-capable CPU for this test. Extract it: ```bash tar -C v1.1.0 \ -xf sylica-x86-test-v1.1.0.tar.zst ``` The package contains the kernel, initrd, EFI shell, and launch instructions: ``` test-assets/ ├── bzImage ├── initrd.img ├── Shell.efi └── readme.md ``` Read: ```bash cat v1.1.0/test-assets/readme.md ``` and execute the QEMU command provided there. The smoke test verifies that: ``` CVMF.fd │ ▼ QEMU/KVM │ ▼ UEFI initialization │ ▼ test workload │ ▼ successful boot ``` It verifies firmware functionality, not confidential-computing isolation. ### 9. Capture attestation evidence On a host with AMD SEV-SNP or Intel TDX support, the test workload can output the attestation report and event log as hexadecimal data. For example: ``` report.hex ccel.hex ``` Convert them to their binary representations: ```bash xxd -r -p report.hex > report.bin xxd -r -p ccel.hex > ccel.bin ``` The files represent: | File | Purpose | | ------------ | -------------------------------------------------------------- | | `report.bin` | Hardware-generated confidential-computing attestation evidence | | `ccel.bin` | Confidential Computing Event Log | The attestation report contains the hardware-backed measurement state. The CCEL provides information about events that contributed to measured state and can be used to understand how the resulting measurement was constructed. You can inspect and verify these artifacts using the Sylica verification tooling described in [Verification and Usage](/sylica/tutorials/verifying-reproducible-builds.md). ### Quick verification workflow {% hint style="info" %} For a quick smoke test, steps 1–5 and 9 are sufficient. For independent supply-chain verification, additionally reproduce the firmware. For a production confidential-computing deployment, verify the release, firmware, expected measurement, and hardware attestation before trusting the workload. {% endhint %} For a normal release evaluation, the complete process is: ``` 1. Download release │ ▼ 2. Verify attestation.json │ ▼ 3. Verify release checksums │ ▼ 4. Extract platform package │ ▼ 5. Verify package checksums │ ▼ 6. Inspect CVMF.fd │ ├──────────────┐ ▼ ▼ 7. Reproduce 8. Measure │ │ ▼ ▼ compare binary compare measurement │ │ └──────┬───────┘ ▼ 9. Test boot │ ▼ 10. Obtain attestation │ ▼ verify MEASUREMENT/MRTD ```