> 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/tutorials/check-platform-compatibility.md). # Check platform compatibility Sylica provides firmware variants for confidential and conventional x86 virtual machines. A **Sylica platform** is a build configuration under `platforms/` that selects the firmware source, EDK2 platform definition, build target, output image, and measurement mode. It is distinct from the virtualization platform on which the resulting firmware runs. For operators, the main choice is straightforward: | VM environment | Sylica platform | Firmware | Intended use | | --------------------------- | --------------- | --------- | ----------------------------------------- | | AMD SEV-SNP confidential VM | `sylica-sev` | `CVMF.fd` | Production confidential computing | | Intel TDX confidential VM | `sylica-tdx` | `CVMF.fd` | Production confidential computing | | Conventional x86 VM | `sylica-x86` | `CVMF.fd` | Production general-purpose virtualization | | AMD SEV reference build | `debug-sev` | `OVMF.fd` | Engineering and comparison | | Intel TDX reference build | `debug-tdx` | `OVMF.fd` | Engineering and comparison | {% hint style="info" %} `sylica-x86` is not limited to confidential-computing environments. It is intended for conventional x86 virtual machines and can be used wherever the VM platform supports standard x86 UEFI firmware. On KVM/QEMU, the SEV-specific code paths remain inactive when the guest is not launched with an SEV context. {% endhint %} This allows operators to use the same Sylica firmware distribution across confidential and conventional VM estates while retaining Sylica's reduced firmware computing base, controlled build process, reproducibility, and security lifecycle. ### Why use Sylica on conventional VMs? Confidential computing is not required to benefit from a smaller and more controlled firmware stack. Traditional virtual-machine firmware is typically designed for broad hardware and operating-system compatibility. That flexibility increases the amount of firmware code and functionality that must be trusted and maintained. Sylica takes a different approach: > Provide only the firmware functionality required for the supported virtual-machine environment and remove unnecessary components from the computing base. `sylica-x86` brings this design to conventional virtual machines. The benefits include: * a reduced firmware computing base; * fewer unnecessary firmware components and code paths; * reproducible firmware builds; * deterministic firmware artifacts; * independently verifiable firmware hashes; * controlled Sylica releases and security updates; * consistent firmware behavior across VM environments. The security benefit is independent of memory encryption. Even without SEV-SNP or TDX, reducing the amount of privileged firmware code lowers the amount of code that must be trusted during VM initialization. Conceptually: ``` Conventional VM with generic firmware Hypervisor │ ▼ General-purpose UEFI / OVMF │ ├── broad compatibility functionality ├── optional drivers ├── legacy features └── VM boot ``` With Sylica: ``` Hypervisor │ ▼ Sylica CVMF.fd │ ├── reduced computing base ├── controlled configuration ├── reproducible build └── VM boot ``` Confidential-computing variants add hardware-backed isolation and attestation on top of the same firmware-engineering principles: ``` AMD SEV-SNP Intel TDX AMD CPU Intel CPU │ │ ▼ ▼ SEV-SNP TDX │ │ ▼ ▼ sylica-sev sylica-tdx │ │ ▼ ▼ CVMF.fd CVMF.fd │ │ ▼ ▼ Confidential VM Confidential VM ``` ### Build platforms The currently defined build platforms are: | Platform | EDK2 platform | Output | CC technology | Measurement | Use | | ------------ | ---------------------------------- | --------- | ------------- | ------------------------ | ---------- | | `sylica-sev` | `SylicaOss/SylicaOssSev.dsc` | `CVMF.fd` | AMD SEV-SNP | SNP launch measurement | Production | | `sylica-tdx` | `SylicaOss/SylicaOssTdx.dsc` | `CVMF.fd` | Intel TDX | MRTD support in progress | Production | | `sylica-x86` | `SylicaOss/SylicaOssSev.dsc` | `CVMF.fd` | None | N/A | Production | | `debug-sev` | `OvmfPkg/AmdSev/AmdSevX64.dsc` | `OVMF.fd` | AMD SEV-SNP | SNP | Reference | | `debug-tdx` | `OvmfPkg/IntelTdx/IntelTdxX64.dsc` | `OVMF.fd` | Intel TDX | TDX | Reference | The `debug-*` platforms contain unmodified upstream EDK2 recipes. They are intended for engineering comparison and reproducibility diagnostics rather than production deployment. ### `sylica-sev` `sylica-sev` is the Sylica firmware variant for AMD SEV-SNP confidential virtual machines. It is built from: ``` SylicaOss/SylicaOssSev.dsc ``` and produces: ``` CVMF.fd ``` The firmware is derived from the EDK2 AMD SEV platform but uses the Sylica platform package and configuration. Compared with the upstream AMD SEV build, Sylica includes security-oriented changes such as: * Secure Boot enabled; * dynamic stack cookies; * Sylica's platform boot manager; * Sylica firmware vendor and version identification; * Sylica-controlled build and reproducibility configuration. The platform boot manager is provided by: ``` SylicaOss/Library/PlatformBootManager ``` #### Host requirements The firmware does not itself provide SEV-SNP capability. The virtualization host must provide the corresponding confidential-computing stack: ``` AMD CPU with SEV-SNP │ ▼ SEV-SNP-enabled host firmware │ ▼ Linux KVM with SNP support │ ▼ QEMU with SNP support │ ▼ sylica-sev / CVMF.fd │ ▼ SEV-SNP confidential VM ``` #### Measurement For SEV-SNP, Sylica can derive the expected launch measurement associated with the VM firmware configuration. The launch measurement is different from the SHA-256 digest of `CVMF.fd`: ``` Firmware SHA-256 │ └── verifies the firmware artifact SNP launch measurement │ └── verifies the measured VM launch state ``` The firmware hash is used for build and artifact verification. The SNP launch measurement is used in hardware-backed remote attestation. ### `sylica-tdx` `sylica-tdx` is the Sylica firmware variant for Intel TDX confidential virtual machines. It is built from: ``` SylicaOss/SylicaOssTdx.dsc ``` and produces: ``` CVMF.fd ``` The platform is derived from the upstream: ``` OvmfPkg/IntelTdx/IntelTdxX64.dsc ``` with Sylica-specific integration. Current implementation differences include: * `GenericQemuLoadImageLib` replaces `X86QemuLoadImageLib` to align the platform with the Sylica firmware architecture; * the flash device is named `CVMF_TDX`; * Sylica firmware vendor and release metadata identify the resulting image. #### Host requirements Running the firmware as a TDX confidential VM requires a TDX-capable host stack: ``` Intel CPU with TDX │ ▼ TDX-enabled platform firmware │ ▼ Linux KVM with TDX support │ ▼ QEMU with TDX support │ ▼ sylica-tdx / CVMF.fd │ ▼ TDX confidential VM ``` #### Measurement Intel TDX uses `MRTD` and `RTMR0` TDX measurement registers as part of its attestation model. This does not affect binary reproducibility: ``` source │ ▼ reproducible build │ ▼ CVMF.fd │ ▼ SHA-256 ``` The TDX measurement layer is separate: ``` CVMF.fd + VM launch configuration │ ▼ MRTD │ ▼ TDX attestation ``` ### `sylica-x86` `sylica-x86` is the Sylica firmware variant for **conventional, non-confidential x86 virtual machines**. It is intended to allow Sylica to be deployed beyond AMD SEV-SNP and Intel TDX environments. The platform uses: ``` SylicaOss/SylicaOssSev.dsc ``` and produces: ``` CVMF.fd ``` The same SEV-capable firmware implementation can boot without an SEV guest context. When the VM is launched as a conventional VM, the SEV-specific code paths remain inactive. As a result, `sylica-x86` can be used as standard UEFI firmware for conventional KVM/QEMU x86 virtual machines without requiring SEV-SNP or TDX hardware. #### Why `sylica-x86` exists The objective is not to provide confidential-computing properties without confidential-computing hardware. Instead, `sylica-x86` makes Sylica's firmware security model available to ordinary VMs: ``` No SEV-SNP No TDX │ ▼ sylica-x86 │ ├── reduced computing base ├── controlled firmware configuration ├── reproducible builds ├── verifiable firmware artifact └── managed security lifecycle │ ▼ Conventional x86 VM ``` This is useful where an infrastructure operator wants a common, security-focused firmware baseline across the complete virtualization environment. For example, an estate can use: ``` AMD SEV-SNP VMs → sylica-sev Intel TDX VMs → sylica-tdx Conventional x86 VMs → sylica-x86 ``` The confidential variants additionally provide hardware-backed memory isolation and attestation, but all three benefit from the same approach to firmware minimization, deterministic configuration, reproducibility, and lifecycle management. #### Reduced computing base Firmware executes at a highly privileged stage before the guest operating system starts. Every firmware component included in the image therefore contributes to the amount of code that must be trusted during VM initialization. Reducing unnecessary functionality provides several benefits: ``` less firmware functionality │ ▼ smaller computing base │ ├── fewer components to review ├── fewer components to maintain ├── fewer potential vulnerabilities └── simpler verification ``` `sylica-x86` is therefore useful even when confidential-computing attestation is not required. #### Measurement No SEV-SNP or TDX launch measurement applies to a conventional VM. For `sylica-x86`, `measurements.json` therefore contains the firmware hash only. The hash can be used to verify that the deployed firmware artifact corresponds to the expected Sylica release. ### Virtualization compatibility Sylica firmware is primarily designed for x86 virtualization environments that allow the operator to supply custom UEFI firmware. | Environment | `sylica-sev` | `sylica-tdx` | `sylica-x86` | | --------------------------------------------------------- | ------------------ | -------------------------------- | -------------------- | | QEMU/KVM | Supported | Supported | Supported | | libvirt with QEMU/KVM | Supported | Supported where TDX is available | Supported | | Other QEMU-based environments | Platform-dependent | Platform-dependent | Generally compatible | | Managed public-cloud VM with provider-controlled firmware | Provider-dependent | Provider-dependent | Provider-dependent | For conventional VMs, `sylica-x86` does not require confidential-computing CPU extensions. Its primary requirement is that the virtualization stack allows custom x86 UEFI firmware to be supplied. #### Customer-supplied firmware Hardware support for SEV-SNP or TDX does not automatically mean that Sylica can be deployed. The virtualization platform must also allow the firmware image used by the VM to be selected or replaced. For example: ``` CPU supports SEV-SNP │ ▼ Cloud exposes SEV-SNP VM │ ▼ Can customer choose VM firmware? │ ├── yes → Sylica may be deployable │ └── no → provider firmware remains in use ``` Compatibility should therefore be evaluated separately for: 1. CPU confidential-computing support; 2. hypervisor support; 3. customer-supplied firmware support; 4. attestation and measurement integration. ### Container and Kubernetes integrations Sylica is not itself a Kubernetes component. In confidential-container architectures, it provides the firmware for the confidential VM that isolates the workload. For example: ``` Kubernetes │ ▼ Kata Containers / Confidential Containers │ ▼ Pod VM │ ▼ QEMU/KVM │ ▼ Sylica CVMF.fd │ ▼ SEV-SNP or TDX ``` Sylica can therefore be integrated into platforms that create confidential VM-backed containers, provided the underlying VM runtime supports customer-selected firmware. ### Reference platforms #### `debug-sev` `debug-sev` builds the unmodified upstream EDK2 AMD SEV platform: ``` OvmfPkg/AmdSev/AmdSevX64.dsc ``` It contains no Sylica platform code. It serves two engineering purposes. **Reproducibility canary** If both `debug-sev` and `sylica-sev` become non-reproducible, the likely cause is a shared build input such as EDK2, the toolchain, or the build environment. If `debug-sev` remains reproducible while `sylica-sev` does not, the problem can be narrowed to the Sylica-specific build path. **Reference firmware** It provides a known upstream baseline for comparing: * firmware size; * firmware volumes; * boot behavior; * measurements; * configuration; * Sylica-specific changes. `debug-sev` is an engineering reference, not the recommended production Sylica firmware. #### `debug-tdx` `debug-tdx` performs the equivalent role for Intel TDX. It uses: ``` OvmfPkg/IntelTdx/IntelTdxX64.dsc ``` and contains no Sylica platform code. It provides an upstream reference for comparing the Sylica TDX firmware and helps isolate build or reproducibility problems between the common build environment and Sylica-specific changes. ### Firmware image model Sylica firmware images use the filename: ``` CVMF.fd ``` where CVMF stands for **Confidential Virtual Machine Firmware**. The name distinguishes Sylica firmware from the upstream EDK2 `OVMF.fd` reference image. Sylica uses a unified firmware image rather than separate firmware CODE and VARS files. Conceptually: ``` Traditional split OVMF OVMF_CODE.fd OVMF_VARS.fd │ │ firmware code mutable variables ``` Sylica: ``` CVMF.fd │ unified firmware image ``` The unified representation provides a stable firmware artifact that can be hashed, reproduced, distributed, and associated with a release. The same image model is used for: ``` sylica-sev sylica-tdx sylica-x86 ``` while the confidential-computing measurement semantics remain specific to the selected technology. ### Build and verification Build a platform using: ```bash scripts/build.sh ``` For example: ```bash scripts/build.sh sylica-sev scripts/build.sh sylica-tdx scripts/build.sh sylica-x86 ``` Build artifacts are written to: ``` out// ``` For Sylica production platforms, the primary firmware image is: ``` CVMF.fd ```