Confidential Computing¶

Confidential Computing (CC) protects data in use — while it is actively being processed in memory — not just at rest on disk or in transit over the network. Verda Confidential VMs (CVM) run inside a hardware-enforced Trusted Execution Environment (TEE) that encrypts both CPU and GPU memory and cryptographically isolates your workload from the hypervisor and the cloud provider. Even Verda's own infrastructure cannot read plaintext data inside a running CVM.

How it works¶

• AMD SEV-SNP (CPU): each CVM gets a unique AES-128 memory encryption key managed exclusively by the AMD Secure Processor (AMD-SP), an on-chip security co-processor the hypervisor cannot access. SEV-SNP adds memory integrity protection via the Reverse Map Table (RMP), which prevents the hypervisor from replaying, remapping, or corrupting guest memory pages. CPU register state is additionally encrypted on every hypervisor exit (SEV-ES).
• NVIDIA Confidential Computing (GPU): the RTX PRO 6000 Blackwell GPU runs in CC mode with all ingress and egress paths protected by AES-256-GCM encryption. GPU memory is isolated from the host. NVIDIA firmware verifies its own integrity at boot via an on-die hardware Root of Trust before the GPU accepts any workload.
• Encrypted PCIe transfers: data moving between the CVM and the GPU passes through bounce buffers. Payloads are AES-GCM-encrypted inside the CVM, staged through a shared PCIe buffer, and decrypted only once inside GPU-protected memory. A rolling 96-bit IV and an AES-GCM AuthTag prevent replay and tampering on the bus.
• Trust boundary: the TEE perimeter encloses the CVM and the GPU's protected memory. The KVM/QEMU hypervisor, host OS, cloud management software, and all other VMs sit outside this boundary and are treated as untrusted.
• Attestation: before any workload runs, you can cryptographically verify the full hardware stack. CPU and GPU attestation are independent: the AMD-SP issues a signed SEV-SNP report (VCEK-signed ECDSA, tied to the firmware TCB version) verifiable against AMD's certificate chain, while nvattest performs GPU-only remote attestation — proving the GPU is genuine, firmware is unmodified, and CC mode is active.

Architecture¶

The AMD-SP hardware and the CVM (including its assigned GPU) are the only trusted components. The hypervisor can schedule and terminate the VM but cannot read its memory or register state. Verda's management plane is outside the trust boundary and has no access to plaintext data or decryption keys.

Attestation chain¶

Before a workload runs, the full hardware stack can be verified by a remote party. CPU and GPU attestation are separate flows. See System Attestation for the exact commands to run on your instance.

1. CPU attestation (AMD SEV-SNP): the AMD-SP generates a report containing a measurement of the VM's initial memory, the SEV-SNP TCB version, and a user-supplied nonce or public key hash. The report is signed with the VCEK — a per-chip ECDSA key cryptographically derived from the firmware version — verifiable against AMD's public certificate chain. This is handled independently via the SEV guest driver (/dev/sev-guest).
2. GPU attestation (NVIDIA): nvattest attest --device gpu --verifier remote drives a GPU-only attestation flow. The NVIDIA driver establishes an SPDM session with GPU firmware using a Diffie-Hellman key exchange, and GPU firmware returns a certificate and measurement report signed by NVIDIA's Root of Trust, proving the GPU is genuine and running unmodified firmware in CC mode. On success, nvattest automatically sets the GPU Ready State, which gates CUDA workload execution.

Supported Hardware¶

Verda currently supports confidential computing on the NVIDIA RTX PRO 6000 (Single GPU). Support for additional Blackwell GPUs is planned for the future:

System Attestation¶

Attestation lets you verify that your instance is running with full confidential computing protections enabled.

Verify CPU RAM encryption¶

$ sudo dmesg | grep -i sev-snp
[    1.816039] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP

Run AMD SEV-SNP CPU attestation¶

Install snpguest (one-time):

$ curl -fsSL https://github.com/virtee/snpguest/releases/download/v0.10.0/snpguest \
    -o /usr/local/bin/snpguest && chmod +x /usr/local/bin/snpguest

Check that SEV, SEV-ES, and SNP are all active:

$ snpguest ok
[ PASS ] - SEV: ENABLED
[ PASS ] - SEV-ES: ENABLED
[ PASS ] - SNP: ENABLED

Generate an attestation report and fetch the AMD certificate chain:

$ mkdir -p /tmp/snp-attest
$ snpguest report /tmp/snp-attest/report.bin /tmp/snp-attest/nonce.bin --random
$ snpguest fetch ca pem /tmp/snp-attest/ turin
$ snpguest fetch vcek pem /tmp/snp-attest/ /tmp/snp-attest/report.bin

Verify the certificate chain — AMD ARK → ASK → VCEK:

$ snpguest verify certs /tmp/snp-attest/
The AMD ARK was self-signed!
The AMD ASK was signed by the AMD ARK!
The VCEK was signed by the AMD ASK!

Verify the attestation report is signed by this chip's VCEK:

$ snpguest verify attestation /tmp/snp-attest/ /tmp/snp-attest/report.bin
Reported TCB Boot Loader from certificate matches the attestation report.
Reported TCB TEE from certificate matches the attestation report.
Reported TCB SNP from certificate matches the attestation report.
Reported TCB Microcode from certificate matches the attestation report.
VEK signed the Attestation Report!

Verify GPU confidential compute mode¶

$ nvidia-smi conf-compute -q
==============NVSMI CONF-COMPUTE LOG==============

    CC State                   : ON
    Multi-GPU Mode             : None
    CPU CC Capabilities        : AMD SEV-SNP
    GPU CC Capabilities        : CC Capable
    CC GPUs Ready State        : Not Ready

Run NVIDIA GPU attestation¶

Install nvattest (one-time):

$ apt install nvattest

Run remote attestation against the GPU:

$ nvattest attest --device gpu --verifier remote
Devices:
- Device 0:
    Device Type: gpu
    Hardware Model: GB20X
    UEID: 632831960640621557346471716215948155372539415535
    VBIOS Version: 98.02.8D.00.01
    Driver Version: 580.126.09
    Measurement Result: success
    Attestation Report Cert Chain:
        Status: valid, OCSP: good
        Expires: 9999-12-31T23:59:59Z
    Driver RIM Cert Chain:
        Status: valid, OCSP: good
        Expires: 2028-01-07T22:11:08Z
    VBIOS RIM Cert Chain:
        Status: valid, OCSP: good
        Expires: 2027-08-26T10:19:38Z

GPU attestation was successful

Key fields to check in the output:

Set the GPU ready state¶

The GPU will not accept any workload until a user inside the CVM sets the ReadyState. This prevents accidental usage before attestation is complete.

Successfully passing remote attestation (see above) automatically sets the ready state. You can also set it manually:

$ nvidia-smi conf-compute -srs 1

Protecting Your Confidential Data¶

When running a Confidential VM, you can create a user with an encrypted home folder so that your data at rest is also protected.

Create an encrypted user¶

$ adduser --encrypt-home newusername
$ sudo usermod -aG sudo newusername

Log in to your user with login (this will ask for your password and decrypt the home folder):

$ login newusername

Verify home folder encryption¶

Create a test file from your user session:

$ echo "secret 123" > ~/test.txt

Then exit and inspect the home folder as root. If encryption is working correctly, you will not see test.txt but instead encrypted directory entries:

$ exit
root@ncc-vm:~# ls -lah /home/newusername/
total 8.0K
dr-x------ 2 newusername newusername   4.0K Mar  2 14:25 .
drwxr-xr-x 4 root        root          4.0K Mar  2 14:44 ..
lrwxrwxrwx 1 newusername newusername   33 Mar  2 14:25 .Private -> /home/.ecryptfs/newusername/.Private
lrwxrwxrwx 1 newusername newusername   34 Mar  2 14:25 .ecryptfs -> /home/.ecryptfs/newusername/.ecryptfs

Booting a Custom OS¶

By default, Verda CVM instances are provisioned with Ubuntu 24.04. If you need a different OS (e.g., Ubuntu 25.10), you can replace the OS on the primary volume in place: a one-shot grub-reboot drops the VM into a RAM-only dropbear rescue shell, and the new image is then streamed directly onto /dev/vda.

How it works¶

• The target VM is booted once into Ubuntu's own initramfs with dropbear SSH added.
• The initramfs pauses at break=mount before touching /dev/vda, so the disk is free to overwrite.
• The new image is streamed from the local machine straight onto /dev/vda.
• After cycling the VM, the target VM boots the new OS.

Prerequisites¶

• A Verda CVM instance with SSH access as root.
• On the local machine:

$ sudo apt-get install -y libguestfs-tools qemu-utils pv

Download the helper scripts and sample env file into a working directory on the local machine:

• env_sample.txt
• 00_build_image.sh
• 01_setup_rescue.sh
• 02_reboot_to_ramdisk.sh
• 03_upload_and_flash.sh

After downloading, make the scripts executable:

$ chmod +x *.sh

1. Configure¶

$ cp env_sample.txt .env
$ # Edit .env: set REMOTE (root@<instance-ip>) and SSH_KEY

2. Build the OS image (local machine)¶

$ ./00_build_image.sh

Produces questing-server-raw.img (~2.1 GB): Ubuntu 25.10 with your SSH key injected, DHCP networking, cloud-init disabled, and a first-boot partition resize.

3. Set up the rescue environment¶

$ ./01_setup_rescue.sh

Installs dropbear-initramfs on the target, copies SSH keys, rebuilds the Ubuntu initramfs with dropbear included, and adds the dropbear-rescue GRUB entry.

4. Boot into rescue¶

$ ./02_reboot_to_ramdisk.sh

Sets a one-shot grub-reboot and syncs. Then go to the Verda console and click Shutdown, then Start — both actions, in that order. The script polls SSH until dropbear answers.

5. Flash the new OS¶

$ ./03_upload_and_flash.sh

Verifies /dev/vda is unmounted, flash the image, and triggers an in-guest poweroff. Verda may still show the VM as "running" — go to the Verda console and click Shutdown, then Start to boot the freshly flashed OS. The script waits for the new OS to come up and reports when SSH is available.