AMD SEV-SNP landed in #703 as an experimental, opt-in platform. Intel TDX with NVIDIA Confidential Computing stays the production path. This issue tracks what's left before bare-metal SNP can be called supported, and how SNP should reach the clouds.
Where it stands
The hard parts are done:
Left before it's "supported"
Until these land, SNP stays experimental and out of the production docs.
Cloud comes later, and separately
Whoever controls the VM launch decides the backend. On bare metal we control the launch and recompute the measurement ourselves. In a cloud we don't, so each cloud is its own backend on top of the provider's vTPM plus the AMD report, not a fork of the bare-metal path. AWS also signs reports with VLEK, which we reject today, so it needs its own verifier. None of this blocks bare metal. Cloud image and config plumbing is tracked in #125.
Related
Design notes
SNP is shaped differently from TDX. TDX gives runtime measurement registers and an event log, so we read identity straight from signed state. SNP gives a single launch measurement and no runtime register, so we bind app identity into the launch config (host_data) and recompute the launch measurement to check it against the report. One consequence: SNP has no RTMR-style runtime composability yet. That needs a vTPM, via SVSM on bare metal or the cloud's own vTPM elsewhere.
For the clouds, GCP and Azure would verify the provider vTPM and consume the AMD report; AWS needs VLEK support. For confidential GPUs, H100 works on bare-metal SNP and on Azure SNP, while GCP's confidential GPU is TDX. The full rationale and references live in #703.
AMD SEV-SNP landed in #703 as an experimental, opt-in platform. Intel TDX with NVIDIA Confidential Computing stays the production path. This issue tracks what's left before bare-metal SNP can be called supported, and how SNP should reach the clouds.
Where it stands
The hard parts are done:
--platform amd-sev-snp, auto-detected on AMD hostsLeft before it's "supported"
Until these land, SNP stays experimental and out of the production docs.
Cloud comes later, and separately
Whoever controls the VM launch decides the backend. On bare metal we control the launch and recompute the measurement ourselves. In a cloud we don't, so each cloud is its own backend on top of the provider's vTPM plus the AMD report, not a fork of the bare-metal path. AWS also signs reports with VLEK, which we reject today, so it needs its own verifier. None of this blocks bare metal. Cloud image and config plumbing is tracked in #125.
Related
Design notes
SNP is shaped differently from TDX. TDX gives runtime measurement registers and an event log, so we read identity straight from signed state. SNP gives a single launch measurement and no runtime register, so we bind app identity into the launch config (
host_data) and recompute the launch measurement to check it against the report. One consequence: SNP has no RTMR-style runtime composability yet. That needs a vTPM, via SVSM on bare metal or the cloud's own vTPM elsewhere.For the clouds, GCP and Azure would verify the provider vTPM and consume the AMD report; AWS needs VLEK support. For confidential GPUs, H100 works on bare-metal SNP and on Azure SNP, while GCP's confidential GPU is TDX. The full rationale and references live in #703.