Use Cases

Sylica is primarily intended for confidential or trusted VM deployments where the firmware must be measurable, reproducible, and independently verifiable.

1. Confidential workloads in public clouds

Organizations can use sylica to run sensitive workloads inside confidential VMs while reducing trust in the cloud operator and hypervisor.

Typical workloads include:

• Personal or financial data processing

• Healthcare and regulated workloads

• Customer-managed databases

• Proprietary analytics

• Machine-learning inference over sensitive data

• SaaS applications requiring tenant isolation

• Confidential batch-processing jobs

The firmware is one component of the confidential VM trust chain. It establishes the initial boot environment and is included in the platform’s measured state.

2. Remote attestation before releasing secrets

A workload can be granted access to encryption keys, credentials, or other secrets only after its VM has passed remote attestation.

A typical flow is:

VM starts with sylica
        ↓
Platform generates an attestation report
        ↓
Verifier checks the firmware measurement
        ↓
Verifier checks VM and workload policy
        ↓
Key-management system releases secrets

For AMD SEV-SNP, the launch digest includes the initial guest memory contents, including the firmware. The expected digest can be computed in advance and compared with the measurement reported by the running VM.

This is useful for:

• Releasing database encryption keys

• Authorizing access to customer data

• Unsealing workload secrets

• Establishing confidential service-to-service communication

• Enforcing “run only on approved firmware” policies

3. Regulated and auditable infrastructure

Sylica can support environments where teams must demonstrate how their confidential VM firmware was produced and which artifact was deployed.

The reproducible build process fixes the edk2 tree, container image, toolchain package versions, apt snapshot, and build timestamp. Releases can include:

• Firmware binaries

• SHA-256 fingerprint

• Toolchain manifests

• Build-environment metadata

• Platform-specific measurements

This supports audit and compliance activities by allowing an organization to retain evidence of:

• The source revision used

• The build environment

• The firmware hash

• The expected launch measurement

• The deployed VM’s attestation report

4. Independent firmware audits and rebuilds

Because the firmware source and build inputs are available, security teams and independent auditors can inspect and rebuild the firmware.

This is particularly important because the firmware acts as a software root of trust. An independent rebuild can verify that:

Reviewed source
        ↓
Declared build environment
        ↓
Published firmware binary

are consistent.

5. Secure VM boot with measured firmware

Sylica can be used where the VM boot chain itself must be included in the attested identity.

The firmware image is named CVMF.fd and combines firmware code with the variable store in one measured binary. It is passed to QEMU with -bios .

This is useful when deployment policy needs to control:

• The exact firmware release

• Secure Boot configuration

• Firmware variables

• Kernel and initrd selection

• VM launch parameters

• Approved combinations of firmware and guest configuration

For SEV-SNP, the expected digest is dependent on deployment details such as vCPU count and type, so each supported VM configuration should be associated with the correct expected measurement.

6. AMD SEV-SNP production deployments

The sylica-sev platform is intended for AMD SEV-SNP confidential VMs.

It includes Sylica-specific changes compared with upstream AmdSev, including:

• Secure Boot enabled

• Dynamic stack cookies

• A Sylica platform boot manager

Potential applications include:

• Confidential application servers

• Protected databases

• Confidential Kubernetes nodes

• Private AI inference

• Customer-controlled workloads hosted by a third party

• Infrastructure where attestation is required before workload authorization

7. Intel TDX deployments and evaluation

The sylica-tdx platform provides a corresponding firmware configuration for Intel TDX. It is based on the upstream Intel TDX edk2 platform and includes Sylica-specific changes.

8. CI/CD verification of firmware releases

Platform and DevOps teams can integrate reproducibility checks into CI/CD pipelines.

The repository provides a reproducibility verification script:

scripts/verify-reproducibility.sh <platform>

It builds the platform twice, including a second build that bypasses the container-layer cache, and fails if the firmware hashes differ.

This can be used to:

• Verify every release candidate

• Detect nondeterministic build inputs

• Prevent unverified firmware from entering an artifact repository

• Produce audit evidence for release approval

• Compare Sylica firmware with upstream reference builds

9. Firmware supply-chain monitoring

Sylica can be used as a controlled firmware artifact within an organization’s software supply chain.

Teams can:

• Mirror approved firmware artifacts internally

• Pin firmware by cryptographic hash

• Associate firmware with a release and source commit

• Store measurement policies alongside deployment manifests

• Reject unapproved firmware during provisioning

• Track firmware changes as part of vulnerability management

This is valuable for organizations that do not want VM firmware to be an implicit, opaque dependency of the cloud platform.

10. Debugging and platform comparison

The debug-sev and debug-tdx builds provide upstream edk2 reference firmware without Sylica code.

They can be used to:

• Compare boot behavior

• Investigate firmware compatibility issues

• Identify whether a problem is in SylicaPkg or the shared build system

• Compare launch measurements

• Diagnose differences between upstream OVMF and CVMF.fd

• Test whether a failure is platform-specific

These builds are reference and diagnostic artifacts rather than replacements for the production firmware.

11. Confidential VM platform standardization

Organizations operating across multiple environments can use sylica as a consistent firmware layer across their confidential VM fleet.

A standardization strategy might define:

AMD hosts
  → sylica-sev
  → Approved firmware hash
  → Approved SNP launch measurements

Intel hosts
  → sylica-tdx
  → Approved firmware hash
  → TDX-specific verification policy

This allows infrastructure teams to manage firmware as a versioned platform dependency rather than treating each cloud or hypervisor deployment as an unrelated configuration.

Summary

The main use cases for sylica are:

Use case	Primary benefit
Confidential cloud workloads	Protect sensitive VM memory from infrastructure operators
Remote attestation	Verify firmware before releasing secrets
Regulated workloads	Provide auditable firmware and measurement evidence
Independent audits	Inspect and rebuild the firmware
Secure measured boot	Bind VM identity to an approved firmware configuration
AMD SEV-SNP deployments	Use UEFI-specific cloud-native confidential VM firmware
Intel TDX deployments	Use UEFI-specific cloud-native confidential firmware platform
CI/CD verification	Detect nondeterministic or unapproved builds
Supply-chain control	Pin and verify firmware artifacts
Debugging	Compare Sylica firmware with upstream edk2
Platform standardization	Establish a consistent firmware policy across environments