Reference Implementations#

This paper covers reference implementations of the CVM architecture, integrated with hypervisor and host/guest OS capabilities provided by Canonical and a partner solution from Fortanix, that provides the attestation service (Fortanix CCM) and Key management service (Fortanix DSM).

CVM Reference Implementation with Fortanix#

The CVM stack in this Reference Architecture uses KVM/QEMU as the hypervisor provided by Canonical, OVMF as virtual firmware, and a vendor-partner attestation and key-management solution provided by Fortanix.

The GPU CC capability and supported GPU SKUs, use the Fortanix implementation for a commercially supported CVM path.

Fortanix Implementation#

Fortanix is a vendor-partner that provides SaaS and On-premises solutions to enable Confidential Computing. Two of their products are the Fortanix Confidential Computing Manager (CCM) and Fortanix Data Security Manager (DSM).

Fortanix Confidential Computing Manager (CCM) handles workload registration, attestation, and policy. Fortanix Data Security Manager (DSM) handles key management and release.

The Fortanix-based stack — KVM/QEMU, OVMF, Ubuntu on both host and guest, Fortanix CCM, Fortanix DSM — is one validated implementation, not the architecture itself. Other key managers with integrated attestation support and a client attester app could play the same role.

Table 6: Fortanix Reference Documentation

Fortanix reference	Use it for
Fortanix CCM usage workflow	CCM workload registration, attestation workflow, zone CA, and policy management.
Fortanix SaaS IP whitelisting	Outbound endpoints and IP ranges for Fortanix SaaS deployments.

Concretely: a CVM runs on KVM/QEMU with an Ubuntu host and a locked-down Ubuntu guest, CPU TEE and GPU CC enabled, and an HTTPS inference endpoint. The guest receives model keys only after Fortanix verifies CPU and GPU evidence against approved policy.

The deployment topology is chosen with Fortanix and the customer security team. Validation and managed-services deployments can use Fortanix SaaS. Production customer-managed deployments use a Fortanix-supported DSM and CCM topology for high availability and policy control. Fortanix attestation and policy services don’t drive GPU-server sizing and can run on regular CPU capacity.

Domain ownership and model-key policy are named per deployment. For model IP protection, the model provider controls the model-key policy; the customer controls infrastructure and availability policy.

Software Components#

Refer to the NVIDIA CC Compatibility Matrix.

Table 7: Software Components

Layer	Component	Version
Hypervisor	KVM/QEMU (SEV-SNP / TDX patches required)	9.2.1
Virtual firmware	OVMF	edk2-stable202408
Host OS	Ubuntu (Canonical)	25.10 or 26.04 LTS
Host kernel	—	6.11+ (6.17+ recommended)
Guest OS	Ubuntu (Canonical)	24.04 minimal or distroless
Guest kernel	—	6.11+
NVIDIA driver	Guest-side only; host runs no NVIDIA driver	580.x +
CPU TEE — AMD	AMD SEV-SNP	EPYC Genoa (9004) or Milan (7003)
CPU TEE — Intel	Intel TDX	Xeon Emerald Rapids or Sapphire Rapids

Supported GPU platforms: NVIDIA HGX H100, H200, H100/H200 PPCIe, B200, RTX Pro 6000 BSE. The same CC mode, topology, and MIG/vGPU restrictions apply. The GPU passes directly into the confidential VM via VFIO.

QEMU Launch Flags (AMD SEV-SNP)#

qemu-system-x86_64 \
  -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \
  -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 \
  -object memory-backend-memfd-private,id=ram1,size=32G,share=true \
  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.snp.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
  -device vfio-pci,host=<gpu-pci-bdf> \
  -drive file=guest.qcow2,if=virtio \
  -smp 32 -m 64G -nographic

QEMU Launch Flags (Intel TDX)#

qemu-system-x86_64 \
  -machine q35,confidential-guest-support=tdx0,hpet=off \
  -object tdx-guest,id=tdx0,sept-ve-disable=on \
  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.tdx.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
  -device vfio-pci,host=<gpu-pci-bdf> \
  -drive file=guest.qcow2,if=virtio \
  -smp 32 -m 64G -nographic

Support Model#

Table 8: Support Model

Component	Maintainer	Notes
QEMU (SEV-SNP / TDX)	QEMU project + AMD / Intel	Distribution QEMU may lack SEV-SNP patches; use AMDSEV project packages or build from source
OVMF	TianoCore EDK II	SEV-SNP and TDX variants in edk2 main
Ubuntu 24.04 LTS	Canonical	5-year LTS; recommended for host and guest

Gaps to production readiness: On Ubuntu 24.04 LTS, the stock distribution QEMU/OVMF/kernel packages do not include the full SEV-SNP host-side patch set, and the stock packages also do not include Intel TDX host enablement. For a 24.04 host, the deployment must use either: (a) AMDSEV-project builds from source for SEV-SNP, or (b) Canonical’s Intel-optimized TDX build (canonical/tdx PPA) for TDX. Ubuntu 25.04 adds stock SEV-SNP host support; Ubuntu 25.10 adds stock TDX host support. The guest image (Ubuntu 24.04 inside the CVM) needs no extra patches for either technology.

GPU RIM collateral must be reachable at attestation time; pre-cache for air-gapped deployments. Guest image hardening is the model provider’s responsibility.

Table 9: External References

Reference	Use it for
AMD SEV repository	SEV-SNP firmware enablement, kernel patches, sample launch tooling
NVIDIA CC Deployment Guide (SNP)	BIOS/firmware prerequisites, GPU CC mode setup, attestation flow
NVIDIA H100 CC Whitepaper	GPU CC architecture, secure channel, attestation evidence format

Exact component versions, hardware profile, and support status are part of the validated configuration profile in Appendix A, not the body of this section.

Example Validation: RTX PRO 6000 Blackwell Server Edition#

The Fortanix CVM implementation is validated on NVIDIA RTX PRO 6000 Blackwell Server Edition nodes. Each validation node uses AMD SEV-SNP, NVIDIA GPU confidential computing, KVM/QEMU with OVMF, Fortanix CCM for attestation workflow, and Fortanix DSM for model-key release.

Table 10: Validated Environment

Area	Validated environment
Server platform	Dell PowerEdge XE7745 node class. UEFI boot, Performance BIOS Settings, iDRAC10 Datacenter, Secured Component Verification, no factory-installed OS.
CPU	2x AMD EPYC 9555 64-core processors per node. 2 sockets, 64 cores per socket, 128 physical cores, 256 threads.
CPU TEE	AMD SEV-SNP enabled in platform firmware and visible to the host kernel and KVM/QEMU launch stack.
GPU	8x NVIDIA RTX PRO 6000 Blackwell Server Edition PCIe GPUs per node. 96 GB-class memory per GPU. ~760 GiB reported aggregate GPU memory per node. Compute capability 12.0.
System memory	1.5 TB-class system memory per node. ~1511 GB observed usable memory.
Local storage	Local NVMe storage for host, guest, and encrypted-artifact workflows. E3.S NVMe data drives and redundant M.2 boot media in the server BOM.
Network adapters	1x NVIDIA BlueField-3 dual-port 200 GbE DPU. 1x NVIDIA ConnectX-6 Lx dual-port 25 GbE adapter. 4x NVIDIA ConnectX-7 single-port IB/400 GbE adapters per node.
Host software	Ubuntu 25.10 host OS, KVM, QEMU 9.2.1, OVMF, VFIO/IOMMU device assignment, Linux kernel 6.14.0-37-generic.
Guest software	Ubuntu 24.04 guest image with a minimal package set, guest kernel 6.11+, inference server, Fortanix/NVIDIA attestation bootstrap, GPU user-space libraries. SSH and remote login disabled.
CVM launch artifacts	Unified Kernel Image, qcow2 virtual disk image, OVMF/BIOS image, KVM/QEMU launch script or domain.xml definition.
Fortanix services	Fortanix CCM verifies the CVM attestation workflow and issues workload certificates through the zone CA after successful attestation. Fortanix DSM stores or wraps model keys and releases them only under approved policy.
Network egress	CVM outbound HTTPS/443 to Fortanix CCM for attestation and certificate issuance, Fortanix DSM for key retrieval, and approved artifact or application endpoints.
Operations telemetry	Operators monitor Fortanix CCM attestation heartbeats, certificate issuance failures, DSM access events, guest startup logs, and service health without sensitive payloads.