> 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/review-the-security-model.md). # Review the security model This document defines the security model of CVMF and provides a basis for security architecture reviews, threat modelling, penetration testing, and independent assessment. CVMF is Sylica's EDK2/OVMF-based firmware for AMD SEV-SNP, Intel TDX, and conventional x86 virtual machines. The security model distinguishes between: 1. properties provided by CVMF itself; 2. properties inherited from EDK2 and the CPU confidential-computing architecture; 3. properties provided by the build and distribution process; 4. properties that depend on the hypervisor or VM configuration; 5. properties that depend on the operating-system boot chain. CVMF must not be treated as an independent security boundary. For confidential VMs it forms part of a larger hardware-backed trust chain. ### Security objectives CVMF has the following primary security objectives. #### Firmware integrity An operator must be able to identify the exact firmware artifact used to start a VM and compare it against an expected CVMF release. #### Firmware provenance A published CVMF firmware artifact should be reproducible from its corresponding source revision and declared build environment. #### Minimal firmware computing base CVMF should contain only the firmware functionality required for its supported virtual-machine environments. Removing unnecessary firmware functionality reduces: * attack surface; * dependency count; * privileged code; * parser exposure; * device support; * maintenance burden; * code requiring security review. #### Controlled boot CVMF should transfer execution only through explicitly supported boot paths. Where UEFI Secure Boot is enabled, EFI executables must satisfy the configured Secure Boot policy before execution. #### Confidential-computing integration For AMD SEV-SNP and Intel TDX, CVMF must execute correctly within the protection model established by the respective CPU architecture. Firmware identity must be usable as part of the confidential-VM verification and attestation model. #### Deterministic configuration Security-relevant firmware functionality must be determined by the platform build configuration rather than uncontrolled runtime discovery or host-provided policy. ## System security model The simplified system model is: ``` Management plane │ ▼ VM configuration / launch │ ▼ ┌─────────────────────────────────────────────────────────┐ │ Untrusted host │ │ │ │ administrator ─ hypervisor ─ QEMU ─ virtual devices │ │ │ │ └──────────────────────────────────┼──────────────────────┘ │ confidential boundary │ ▼ ┌─────────────────────────────────────────────────────────┐ │ SEV-SNP VM / Intel TD │ │ │ │ CVMF │ │ │ │ │ ▼ │ │ EFI boot workload │ │ │ │ │ ▼ │ │ guest OS │ │ │ │ │ ▼ │ │ workload │ └─────────────────────────────────────────────────────────┘ │ ▼ Attestation verifier ``` For conventional `sylica-x86` VMs, the confidential boundary does not exist: ``` Hypervisor / QEMU │ ▼ CVMF │ ▼ guest OS ``` Consequently, the host must be trusted for confidentiality and runtime integrity in a conventional VM. ## Assets The security review should consider the following assets. | Asset | Security property | | ------------------------------ | ----------------------------- | | CVMF source | Integrity | | EDK2 source revision | Integrity and provenance | | Build environment | Integrity and reproducibility | | `CVMF.fd` | Integrity and authenticity | | Firmware configuration | Integrity | | Firmware measurement | Integrity | | UEFI Secure Boot configuration | Integrity | | Boot image / UKI | Integrity and authenticity | | Kernel | Integrity and authenticity | | Initrd | Integrity and authenticity | | Kernel command line | Integrity | | Guest memory | Confidentiality and integrity | | Guest secrets | Confidentiality and integrity | | Attestation evidence | Authenticity and freshness | | Expected measurements | Integrity | | Attestation policy | Integrity | The importance of each asset depends on the deployment model. For example, CVMF itself does not protect application secrets after control has transferred to a compromised guest operating system. ## Trust boundaries Understanding the trust boundaries is critical to reviewing CVMF. ### Hardware boundary For confidential VMs, AMD SEV-SNP or Intel TDX establishes the fundamental isolation boundary between the confidential VM and the host. ``` Untrusted │ ┌──────────┴──────────┐ │ Hypervisor / QEMU │ └──────────┬──────────┘ │ ════════════════╪════════════════ hardware security boundary ════════════════╪════════════════ │ ┌──────────▼──────────┐ │ Confidential VM │ │ │ │ CVMF │ │ OS │ │ workload │ └─────────────────────┘ ``` CVMF does not create this boundary. The CPU confidential-computing architecture does. ### Firmware boundary CVMF executes before the guest operating system and therefore occupies a highly privileged position inside the VM. ``` CVMF │ │ transfers control ▼ EFI workload │ ▼ kernel ``` A compromise of CVMF can invalidate security properties expected from later stages of the guest. CVMF must therefore be treated as part of the guest's trusted computing base. ### Firmware-to-boot-image boundary UEFI Secure Boot can establish an authentication boundary between CVMF and subsequent EFI executables. ``` CVMF │ │ signature verification ▼ authorized EFI executable ``` Secure Boot protects this transition only when: * Secure Boot is enabled; * the relevant verification path is used; * trusted keys are correctly provisioned; * untrusted execution paths are unavailable. Secure Boot does not establish confidentiality. ### Host-to-firmware boundary The hypervisor provides virtual hardware and data to the firmware. Examples include: * CPU state; * memory layout; * virtual PCI devices; * ACPI-related information; * QEMU `fw_cfg`; * boot images; * initrd; * kernel command line. For a conventional VM these inputs originate from a trusted host. For a confidential VM the host may be adversarial. Host-provided data must therefore not automatically be considered trustworthy merely because CVMF executes inside a confidential VM. ## Threat actors The security model considers the following adversaries. ### Malicious cloud administrator The attacker controls the host environment but not the confidential-computing hardware root of trust. Potential capabilities include: * modifying QEMU configuration; * modifying virtual devices; * supplying malicious boot parameters; * replacing disk images; * replacing firmware; * modifying VM launch configuration; * observing host-visible VM activity; * controlling VM scheduling; * terminating or restarting VMs. For SEV-SNP and TDX deployments, protection against a malicious or compromised host is a central security objective. ### Compromised hypervisor The attacker has arbitrary code execution in the host kernel, hypervisor, or virtual-machine monitor. This is stronger than an administrative attacker. The CPU confidential-computing mechanism is expected to protect confidential VM memory against this adversary within the guarantees of the relevant hardware architecture. CVMF must not assume that hypervisor-provided input is benign. ### Malicious VM image provider An attacker can provide or replace: * boot disks; * EFI executables; * UKIs; * kernels; * initrds. Secure Boot and higher-level image verification mechanisms are responsible for restricting which boot workloads may execute. ### Software supply-chain attacker An attacker attempts to alter: * EDK2 source; * Sylica source; * build dependencies; * compiler packages; * container images; * CI configuration; * release artifacts. Reproducible builds and independent artifact verification are intended to make unauthorized modifications detectable. ### Guest attacker An attacker obtains execution inside the guest operating system or application. CVMF is not intended to isolate applications from a compromised guest kernel. After boot, the guest operating system normally becomes part of the trusted computing base for application-level security. ## Trusted computing base The TCB depends on the deployment. ### SEV-SNP At a high level: ``` AMD hardware / firmware + SEV-SNP architecture + CVMF + authorized boot workload + guest kernel + security-critical guest software ``` The hypervisor is intentionally outside the confidentiality and memory-integrity TCB to the extent provided by SEV-SNP. ### Intel TDX At a high level: ``` Intel hardware + TDX module / platform TCB + CVMF + authorized boot workload + guest kernel + security-critical guest software ``` Again, the VMM is intended to remain outside the confidential guest's memory confidentiality and integrity TCB to the extent provided by TDX. ### Conventional x86 For `sylica-x86`: ``` host + hypervisor + QEMU + CVMF + guest OS ``` The host and hypervisor remain trusted. `sylica-x86` therefore provides firmware hardening and supply-chain properties but does **not** provide confidential-computing isolation. ## Security assumptions The CVMF security model depends on explicit assumptions. ### Hardware assumptions For confidential VMs, CVMF assumes: * the CPU implements the relevant SEV-SNP or TDX security guarantees correctly; * required CPU security updates are installed; * platform firmware and microcode meet vendor requirements; * hardware attestation keys and certificate chains have not been compromised. CVMF cannot compensate for a broken hardware root of trust. ### Cryptographic assumptions The model assumes that the cryptographic primitives used for: * firmware hashing; * Secure Boot; * confidential-computing measurements; * attestation; remain secure for their intended use. ### Build assumptions The release model assumes that: * the declared EDK2 revision is correct; * build inputs are pinned; * the build container corresponds to the published build environment; * deterministic-build controls are applied; * independent rebuilds can detect changes to the resulting firmware. Reproducibility provides evidence about source-to-binary correspondence. It does not prove that the source itself is secure. ### Verifier assumptions Remote attestation only provides useful security if the verifier correctly evaluates the evidence. The verifier must maintain trusted policy including expected: * platform identity; * TCB versions; * firmware measurements; * guest policy; * boot configuration where applicable. Accepting arbitrary valid hardware attestations is insufficient. The attested state must satisfy an explicit policy. ## Host trust model The host trust model differs fundamentally between confidential and conventional VMs. | Component | Conventional VM | SEV-SNP / TDX | | ---------------------- | ------------------ | ----------------------------------- | | Physical CPU | Trusted | Trusted | | CPU security mechanism | N/A | Trusted | | Host firmware | Trusted | Platform-dependent TCB | | Host OS | Trusted | Untrusted for guest confidentiality | | Hypervisor | Trusted | Untrusted for guest confidentiality | | QEMU/VMM | Trusted | Untrusted | | CVMF | Trusted | Trusted | | Guest kernel | Trusted | Trusted | | Guest applications | Workload-dependent | Workload-dependent | "Untrusted" does not mean the component cannot affect the VM. The hypervisor necessarily controls resources such as: * scheduling; * availability; * virtual devices; * interrupts; * I/O; * VM lifecycle. Confidential computing primarily removes the host from the confidentiality and memory-integrity trust boundary. It does not remove host control over availability. ## Security guarantees When correctly built, configured, deployed, and verified, CVMF is intended to contribute the following properties. ### Reproducible firmware The same pinned source and build inputs should produce bit-identical firmware. This allows an independent party to compare: ``` official CVMF.fd │ │ hash ▼ H1 independent rebuild │ │ hash ▼ H2 ``` with: ``` H1 == H2 ``` A match provides evidence that the distributed firmware corresponds to the reviewed source and build inputs. ### Firmware identification Each exact firmware artifact can be identified by its cryptographic digest. This allows policy systems to distinguish approved firmware from modified or unexpected firmware. ### Hardware-backed launch evidence For confidential VMs, hardware attestation provides evidence about the VM launch environment according to the capabilities of SEV-SNP or TDX. The verifier can use that evidence to determine whether the VM corresponds to an approved configuration. ### Boot-image authentication When Secure Boot is enabled and correctly configured, CVMF can reject EFI executables that are not authorized by the configured trust policy. This extends the trust chain: ``` hardware │ ▼ CVMF │ │ Secure Boot ▼ authorized UKI │ ▼ kernel ``` ### Reduced firmware attack surface CVMF intentionally reduces unnecessary OVMF functionality. This does not prove the absence of vulnerabilities. It reduces the amount of privileged firmware functionality exposed to attackers and requiring review. ## Non-goals A security review should explicitly recognize what CVMF does **not** guarantee. ### Protection against denial of service A malicious host can generally: * stop the VM; * pause the VM; * withhold CPU time; * remove devices; * interrupt network connectivity; * prevent storage access; * destroy the VM. CVMF does not provide availability against a malicious infrastructure operator. ### Application isolation CVMF does not isolate applications from each other after the operating system has booted. Application isolation must be provided by mechanisms such as: * process isolation; * containers; * VMs; * language sandboxes; * application-specific controls. ### Protection from a compromised guest kernel The guest kernel executes with higher privilege than applications. A compromised guest kernel can generally access application memory and secrets. CVMF does not prevent this. ### Secure application software A verified CVMF image does not imply that: * the kernel is vulnerability-free; * the initrd is secure; * applications are secure; * application configuration is secure. Firmware verification is only one part of the trust chain. ### Rollback prevention by itself Cryptographic integrity alone does not necessarily prevent an attacker from launching an older but correctly signed or correctly measured firmware version. Rollback resistance requires policy that rejects versions or measurements that are no longer approved. ## Firmware attack surface The principal CVMF attack surface should be reviewed by input origin. ### QEMU `fw_cfg` CVMF consumes host-provided information through QEMU `fw_cfg`. Relevant Sylica components include: ``` SylicaOss/Library/QemuFwCfg/ SylicaOss/Library/QemuLoadImage/ SylicaOss/Driver/QemuLoader/ ``` Potential vulnerability classes include: * malformed lengths; * integer overflow; * integer truncation; * out-of-bounds reads; * out-of-bounds writes; * allocation failures; * inconsistent size/data pairs; * unexpected file names; * malformed boot blobs; * TOCTOU conditions. For confidential VMs, `fw_cfg` should be treated as an **untrusted input boundary** unless a particular value is independently authenticated. ### Virtual devices DXE interacts with virtual hardware controlled by the VMM. Potential attack surfaces include: * PCI configuration; * MMIO; * port I/O; * virtual block devices; * console devices; * ACPI; * interrupt configuration. Every unnecessary device driver increases the amount of host-controlled input processed by privileged firmware. This is one of the principal reasons for CVMF's reduced-component architecture. ### EFI executables Any EFI executable accepted for execution becomes part of the pre-OS attack surface. Secure Boot should therefore be reviewed for: * key enrollment; * allowed signing authorities; * forbidden certificates and hashes; * fallback boot paths; * removable-media paths; * shell availability; * injected EFI applications. ### Variable services UEFI variables may affect security-sensitive state. Review should determine: * where variables are stored; * whether the host can replace the variable store; * which variables influence boot behavior; * how Secure Boot variables are protected; * whether variable state contributes to attestation; * whether rollback is possible. Persistent mutable state deserves particular scrutiny because reproducibility of `CVMF.fd` does not automatically establish the integrity of runtime variable state. ### Boot parameters Kernel command-line parameters can substantially alter guest security. Potential examples include parameters that: * disable security features; * change init behavior; * enable debugging; * expose consoles; * alter integrity verification. Where command-line data originates from the host, the security model must specify whether it is: * measured; * authenticated; * embedded into a signed UKI; * or explicitly considered untrusted. ## QemuLoader security boundary `QemuLoader` is a particularly important CVMF-specific component because it translates host-supplied QEMU data into UEFI-visible objects. The architecture is: ``` untrusted host │ │ fw_cfg ▼ ┌─────────────────┐ │ QemuLoader │ └────────┬────────┘ │ ├── SimpleFileSystem └── LoadFile2 │ ▼ UEFI consumers ``` The driver can expose items such as: ``` kernel initrd cmdline EFI\BOOT\BOOTX64.EFI startup.nsh ``` This component therefore crosses a significant trust boundary. Security review should verify that: * all host-provided sizes are validated; * allocations cannot overflow; * data cannot exceed allocated buffers; * unsupported names cannot create unexpected paths; * the filesystem interface remains read-only; * path parsing cannot escape the intended namespace; * boot-policy decisions do not implicitly trust host-provided data; * injected EFI executables remain subject to the intended authentication policy. ## Secure Boot review Secure Boot should be evaluated as an independent subsystem. The expected security property is: ``` CVMF │ ├── trusted keys │ ▼ signature verification │ ├── valid + authorized ──► execute │ └── invalid/untrusted ───► reject ``` The review should answer: 1. Is Secure Boot enabled in production artifacts? 2. Which keys are trusted? 3. How are keys provisioned? 4. Can the host replace the variable store? 5. Can the host disable Secure Boot? 6. Is Secure Boot state covered by the attestation policy? 7. Are all EFI execution paths subject to verification? 8. Is the UEFI shell present in production? 9. Can `startup.nsh` introduce an unintended execution path? 10. Can QEMU-injected EFI binaries bypass normal verification? A statement that CVMF "supports Secure Boot" is insufficient for the security model. The deployed configuration determines whether Secure Boot provides an effective security boundary. ## Measurement and attestation Measurement and verification should be considered separately. ### Measurement A measurement identifies state: ``` firmware/configuration │ ▼ measurement │ ▼ digest/state ``` ### Attestation Attestation authenticates hardware-generated evidence containing or binding such state: ``` measurement + platform state + freshness data │ ▼ hardware-signed evidence │ ▼ verifier ``` ### Authorization The verifier must then apply policy: ``` attestation evidence │ ▼ cryptographic verification │ ▼ policy evaluation │ ┌────┴────┐ ▼ ▼ accept reject ``` These are three different operations. A valid attestation report proves that authentic hardware generated the evidence. It does **not** by itself establish that the measured firmware is trusted. ## Expected measurement management Expected CVMF measurements are security-sensitive configuration. They should be: * associated with an exact release; * published through an authenticated channel; * versioned; * immutable for a released artifact; * independently reproducible where possible. A policy should conceptually contain: ``` CVMF release │ ├── artifact hash ├── platform ├── expected measurement ├── security version └── approval state ``` An attestation verifier should reject unknown measurements by default rather than interpreting successful hardware signature verification as sufficient authorization. ## Supply-chain security The CVMF supply-chain model is: ``` Sylica source │ ▼ pinned EDK2 │ ▼ pinned build environment │ ▼ isolated build │ ▼ CVMF.fd │ ▼ cryptographic digest │ ▼ release ``` Independent verification adds: ``` source revision │ ▼ independent build │ ▼ CVMF.fd │ ▼ compare digest ``` The security review should separately evaluate: * source repository protection; * dependency pinning; * CI permissions; * GitHub Actions pinning; * build-container provenance; * compiler provenance; * release permissions; * release signing; * artifact publication; * expected-measurement publication. Reproducibility makes supply-chain compromise more detectable but does not eliminate it. ## Mutable versus immutable state An important review distinction is between immutable firmware content and mutable runtime state. ``` CVMF security state ┌────────────┴────────────┐ │ │ ▼ ▼ immutable mutable CVMF code variables drivers boot order libraries Secure Boot state compiled policy enrolled keys runtime configuration ``` A reproducible firmware binary establishes only the immutable side. If security decisions depend on mutable state, that state requires its own integrity and attestation model. ## Security invariants The following invariants are useful targets for automated tests and security review. #### Invariant 1 An untrusted host must not be able to cause memory corruption in CVMF through malformed external input. #### Invariant 2 An untrusted host must not be able to execute an unauthorized EFI binary when Secure Boot is part of the deployment security policy. #### Invariant 3 An attestation verifier must not accept an unknown CVMF measurement merely because the hardware attestation signature is valid. #### Invariant 4 A released CVMF artifact must correspond to its documented source revision and reproducible build inputs. #### Invariant 5 Removing or modifying security-relevant firmware components must change the resulting firmware artifact and, where applicable, its expected confidential-VM measurement. #### Invariant 6 Host-provided boot data must not implicitly become trusted merely because it is consumed inside the confidential VM. #### Invariant 7 Conventional `sylica-x86` deployments must not be represented as providing SEV-SNP or TDX host-isolation guarantees. ## Security review checklist A CVMF security assessment should cover at least the following areas. * [ ] Verify the exact EDK2 revision and all source dependencies. * [ ] Reproduce `CVMF.fd` independently. * [ ] Compare the resulting cryptographic digest with the release artifact. * [ ] Inventory every SEC, PEI, DXE, runtime, and UEFI module. * [ ] Justify every included firmware driver. * [ ] Identify every host-controlled input consumed before `ExitBootServices()`. * [ ] Review `QemuFwCfg` handling as untrusted input. * [ ] Review `QemuLoader` for memory-safety and path-handling errors. * [ ] Review all size and offset calculations. * [ ] Review boot-image verification. * [ ] Review Secure Boot configuration and key ownership. * [ ] Verify whether the UEFI shell is disabled in production. * [ ] Review `startup.nsh` behavior. * [ ] Review all alternative and fallback boot paths. * [ ] Review UEFI variable persistence and integrity. * [ ] Determine whether the host can replace the variable store. * [ ] Determine which mutable state affects the trust decision. * [ ] Verify SEV-SNP expected measurements. * [ ] Verify TDX expected measurements. * [ ] Review attestation-policy versioning. * [ ] Test rejection of unknown firmware measurements. * [ ] Test rejection of obsolete firmware measurements. * [ ] Test malformed QEMU `fw_cfg` inputs. * [ ] Test malformed EFI images. * [ ] Test malformed initrd and command-line inputs. * [ ] Review virtual-device attack surface. * [ ] Review debug and development functionality in release builds. * [ ] Verify that release builds do not expose unintended diagnostic interfaces. * [ ] Review compiler and build-container provenance. * [ ] Review CI and release permissions. * [ ] Review publication of hashes and expected measurements. * [ ] Verify that documentation does not overstate hardware or firmware guarantees. ## Open security questions The following questions should be explicitly resolved before considering the CVMF security model complete. #### Boot integrity * Is the production boot path always Secure Boot protected? * Can host-injected `BOOTX64.EFI` execute without satisfying the expected authentication policy? * Under what conditions is `startup.nsh` available? * Are fallback EFI boot paths enabled? #### Host-provided data * Which `fw_cfg` items are accepted? * Which are considered trusted? * Which are measured? * Which are authenticated? * Can the host independently control kernel, initrd, and command line? #### Variable state * Is the variable store part of `CVMF.fd` at launch? * Can the host supply another variable store? * Can Secure Boot state be rolled back? * Is variable state represented in attestation? #### Measurement * Exactly which bytes contribute to the SEV-SNP launch measurement? * Exactly which CVMF components contribute to TDX MRTD/RTMR state? * How are expected measurements generated? * How are expected measurements published? * How are obsolete measurements revoked? #### Update and rollback * How is a CVMF security update authorized? * How are vulnerable releases removed from attestation allowlists? * Is there an explicit minimum security version? * How are emergency revocations distributed? These questions should have concrete implementation answers rather than assumptions. ## Residual risks Even with all CVMF controls operating correctly, residual risks remain. These include: * CPU vulnerabilities; * CPU microcode vulnerabilities; * SEV-SNP or TDX implementation vulnerabilities; * EDK2 vulnerabilities; * vulnerabilities in retained CVMF drivers; * malicious virtual-device behavior; * guest-kernel vulnerabilities; * Secure Boot key compromise; * signing infrastructure compromise; * attestation verifier compromise; * policy misconfiguration; * denial of service by the host; * side channels outside the guarantees of the hardware architecture; * rollback where version policy is insufficient. CVMF reduces selected risks but does not eliminate the security dependencies of the complete confidential-computing stack. ## Review outcome A CVMF security review should not produce only a binary "secure/insecure" conclusion. Findings should be classified according to the affected trust boundary. | Category | Example | | ---------------------- | ----------------------------------------------- | | Firmware memory safety | malformed `fw_cfg` causes buffer overflow | | Boot integrity | unsigned EFI image can execute | | Measurement | security-relevant state is not measured | | Attestation | verifier accepts unknown measurement | | Supply chain | build dependency is not pinned | | Rollback | obsolete firmware remains authorized | | TCB reduction | unnecessary network/device driver included | | Documentation | claimed guarantee exceeds actual implementation | | Platform configuration | insecure feature enabled in release build | For every finding, reviewers should identify: ``` asset + attacker + trust boundary + attack path + security impact + required mitigation ``` This makes findings actionable and avoids treating firmware vulnerabilities, attestation-policy failures, and infrastructure configuration errors as equivalent problems. ## Security model summary The CVMF security model consists of four complementary layers: ``` ┌──────────────────────────────────────────┐ │ Attestation policy │ │ Is this VM configuration approved? │ ├──────────────────────────────────────────┤ │ Boot authentication │ │ Is this boot workload authorized? │ ├──────────────────────────────────────────┤ │ CVMF firmware │ │ Minimal, controlled, reproducible TCB │ ├──────────────────────────────────────────┤ │ SEV-SNP / Intel TDX hardware │ │ Confidentiality + integrity boundary │ └──────────────────────────────────────────┘ ``` No individual layer provides the complete security property. The intended chain is: ``` reviewed source │ ▼ reproducible CVMF │ ▼ known firmware identity │ ▼ hardware-protected VM launch │ ▼ verified attestation │ ▼ approved measurement │ ▼ authenticated boot workload │ ▼ guest operating system │ ▼ application ``` The central security requirement is that **every transition across this chain must either be authenticated, measured and verified, or explicitly documented as an untrusted input boundary**. That principle should guide both the implementation and every security review of CVMF.