Confidential VM images

Testnet v1 publishes measured images of the node, so a node running in a confidential VM can prove which release it runs:

The images carry the released tenzro-node-linux-x86_64-cpu binaries unchanged. They are built by scripts/release/build-cvm-image.sh and scripts/release/build-nitro-eif.sh from that archive; two builds of the same inputs give the same bytes, so anyone can rebuild an image and compare its digests with the published ones.

What is measured

The confidential VM disk has three partitions: an EFI system partition holding one file, a read-only root file system, and its dm-verity hash tree. The EFI file is a unified kernel image: the kernel, the initrd and a kernel command line that carries the verity root hash. Changing any byte of the root file system changes the root hash, which changes the unified kernel image, which changes what the firmware measures when it starts it.

• Intel TDX. The firmware records the unified kernel image's Authenticode digest in RTMR1, with the disk's partition table, and the image's own stub records its sections in RTMR2. MRTD and RTMR0 describe the platform's firmware and virtual hardware. scripts/release/cvm-measure.py verify replays the firmware event log against the quote, checks that the image and the kernel it carries are the only programs the firmware started, and compares RTMR1 and RTMR2 with the published values.
• AMD SEV-SNP. The launch measurement covers what the hypervisor loads before the guest runs. When the firmware boots the disk, as on cloud platforms that supply their own firmware, it measures that firmware only: compare it with the firmware measurement the platform publishes, and bind the image through the guest's TPM event log. On your own host, boot the unified kernel image directly (QEMU -kernel tenzro-node-cvm-x86_64.efi with an SEV-SNP OVMF build and kernel hashes on); the launch measurement then covers the image, and sev-snp-measure --mode snp --ovmf <OVMF.fd> --vcpus <n> --vcpu-type <type> --kernel tenzro-node-cvm-x86_64.efi gives the expected value for that host.
• AWS Nitro. PCR0 measures the whole enclave image, PCR1 the kernel, command line and bootstrap ramdisk, PCR2 the node's ramdisk.

The published values for this release are in the table at the end of this page and in each image's .measurements.json / .pcrs.json.

Booting the image

The disk is a plain UEFI disk (.raw; .gce.tar.gz holds it as disk.raw for cloud image import). It needs:

• a confidential VM with Intel TDX or AMD SEV-SNP and a virtual TPM 2.0 (the node's keys live in the TPM; a guest without one refuses to start the node);
• a disk of at least 8 GB: on first boot the free space becomes the state partition (/var), which holds the chain data, the TPM-sealed authorization of the node's keys and nothing else;
• outbound network access (DHCP). The node's RPC listens on loopback only.

On first boot the image seals a fresh authorization for the node's TPM keys to the guest's TPM, provisions the node's keys (tenzro-node tpm provision) and starts the node. Node flags go in /var/lib/tenzro-config/node.env as TENZRO_NODE_ARGS=...; on Google Cloud the instance metadata attribute tenzro-node-args sets them. Flags are configuration, not code, and are not part of the measurement.

When the node answers, the image prints to the serial console the detected TEE, the measurement registers of a fresh report, and the report and the firmware event logs (gzip, base64), in lines tagged TENZRO-DETECT, TENZRO-MEASUREMENTS, TENZRO-REPORT and TENZRO-EVENTLOG-*.

Checking a node

Ask the node for a report and its registers:

tenzro tee attest --out report.json

tenzro_getTeeAttestation returns the registers (measurements: MRTD and RTMR0-3 on TDX, MEASUREMENT on SEV-SNP) and the report itself (report_hex). tenzro_verifyTeeAttestation verifies a report against a nonce from tenzro_teeAttestationChallenge and returns the verified registers.

For a TDX guest, check the image too:

python3 scripts/release/cvm-measure.py verify \
  --measurements tenzro-node-cvm-x86_64.measurements.json \
  --report report.json --eventlog CCEL.bin --platform gcp-tdx

CCEL.bin is the guest's /sys/firmware/acpi/tables/data/CCEL (also printed on the console).

Proofs made in the VM

The prover image runs both stages of the finality prover on the machine: the STARK stage (tenzro-finality-prover stark, on the CPU here; on an NVIDIA GPU in a GPU confidential VM) and the Groth16 wrap (tenzro-finality-prover wrap, on the CPU, in the Groth16 prover container the image carries by digest). A proof made there is bound to the machine's attestation:

tenzro-finality-prover wrap --receipt receipt.bin --out proof.json
tenzro zk attest-finality-proof --proof proof.json --out bound.json
tenzro zk verify-tee-finality-proof --bundle bound.json

tenzro_attestFinalityProof verifies the seal, then asks the TEE for a report whose report data commits to SHA-256("tenzro/zk/tee-bound-finality-proof" || image_id || SHA-256(journal) || SHA-256(seal) || prover_digest), where prover_digest is the digest of the Groth16 prover container. Any node verifies the bundle with tenzro_verifyTeeFinalityProof: the seal, the prover, the binding and the vendor evidence, returning the verified registers. Comparing those registers with the published measurements of the prover image shows the proof came from the published prover in a measured VM.

Receipts placed in /var/lib/tenzro-prover/inbox/*.receipt are wrapped, bound and verified automatically, with the results in /var/lib/tenzro-prover/outbox/. On Google Cloud the instance metadata attribute tenzro-prover-receipt (a gs:// object the instance's service account can read) places one receipt in the inbox.

The GPU STARK stage needs an NVIDIA GPU in confidential-computing mode inside a TDX or SEV-SNP guest, and a prover built with the cuda feature; the evidence then also carries the GPU's attestation. The prover image as published runs both stages on the CPU.

Published measurements (testnet v1)

These values are for the release candidate (node built from commit dc36c9fe, images built with SOURCE_DATE_EPOCH=1791298041). The release build of testnet v1 rebuilds the node, so the images and these values are refreshed then; the release's .measurements.json and .pcrs.json files are authoritative.

tenzro-node-cvm-x86_64

tenzro-node-cvm-x86_64-prover

tenzro-node-nitro-x86_64.eif

Platform registers on Google Cloud. MRTD, RTMR0 and the SEV-SNP launch measurement belong to the platform's firmware, not the image; each is signed for by the platform's firmware endorsement (gs://gce_tcb_integrity/ovmf_x64_csm/<tdx|sevsnp>/<value>.binarypb). Observed values: