feat: AMD SEV-SNP app key provisioning (GetAppKeyAmd)

[DeDTihoN]

feat: AMD SEV-SNP app key provisioning (GetAppKeyAmd)

Adds AMD SEV-SNP support to the KMS. AMD-based confidential VMs can now obtain the same application keys (disk encryption, env secrets, k256 identity) as Intel TDX VMs.

How it differs from GetAppKey (TDX)

	TDX (GetAppKey)	AMD SEV-SNP (GetAppKeyAmd)
Attestation transport	RA-TLS mTLS client cert	SNP report + VCEK cert chain in request body
Root of trust	Intel PCK Root CA via DCAP/PCCS	AMD Root Key (ARK) — hardcoded, no PCCS needed
Measurement	RTMRs extended at runtime, verified by replaying event log	Single MEASUREMENT fixed at launch: OVMF + kernel + initrd + cmdline
compose/rootfs binding	Extended into RTMR3 at runtime via event log	Embedded in kernel cmdline at launch → part of MEASUREMENT; KMS recomputes expected value and rejects any mismatch
Auth webhook	os_image_hash + compose_hash	os_image_hash + compose_hash
Response delivery	Plaintext over TLS — session is bound to the attested mTLS identity	ECDH-encrypted to VM's X25519 pubkey from report_data

AMD SEV-SNP supports generating on-demand attestation reports with custom report_data (via /dev/sev-guest), so RA-TLS over mTLS would be technically feasible. However, implementing it would require changes at multiple levels: AMD-specific X.509 extension format, a new code path in handle_prpc_impl to parse two different attestation types from client certs, and a new cert generation flow parallel to the existing TDX one. Instead, the current approach sends the SNP report in the request body and ECDH-encrypts the response to the VM's X25519 pubkey embedded in report_data[0..32]. The VM places its pubkey there before requesting the report from the kernel, so AMD hardware attests it. This is simpler to implement and equivalent in security.

Changes

kms/src/main_service.rs

• New get_app_key_amd: verifies AMD cert chain (ARK → ASK → VCEK → SNP report), recomputes expected MEASUREMENT, calls auth webhook, derives keys, ECDH-encrypts response

kms/rpc/proto/kms_rpc.proto

• New GetAppKeyAmd RPC, GetAppKeyAmdRequest, AppKeyAmdResponse

kms/src/config.rs, kms/kms.toml

• New optional [core.sev_snp] section (ovmf_path, guest_features); if absent, measurement recomputation is skipped

dstack-attest/

• New DstackSevSnp attestation mode variant

[kvinwang]

Thanks for the PR.

I still need to review the details, but one high‑level concern: it’s not clear how this integrates with the existing dstack-os images, and for SEV-SNP the way we build the OS image and launch the CVM is part of the security model.

Could you provide the scripts of how the SEV-SNP OS image is built and the CVM is launched? Also, in what environment do you expect this CVM to run (e.g. GCP, bare metal)?

[DeDTihoN]

Thanks for the review!

Just to clarify the intent of this PR: the goal here is not to integrate AMD SEV-SNP support into dstack itself, but rather to allow VMs that are already running under AMD SEV-SNP (built and launched independently) to obtain keys from the dstack KMS, which itself runs as a TDX CVM. How dstack-os images for SEV-SNP would be built in the future — and how they would communicate with a dstack KMS host — is a separate concern that can be addressed later with dedicated approaches.

Regarding your questions about image build and launch — for our SecretVM case specifically:

• The SEV-SNP OS image build can be found here: https://github.com/scrtlabs/secret-vm-build/tree/amd
• The launch scripts and the scripts handling communication with the dstack KMS for the AMD SEV-SNP case are here: https://github.com/scrtlabs/secret-vm-ops/tree/amd/scripts

As for the environment — we expect these CVMs to run on bare metal.

[kvinwang]

Thanks for the review!

Just to clarify the intent of this PR: the goal here is not to integrate AMD SEV-SNP support into dstack itself, but rather to allow VMs that are already running under AMD SEV-SNP (built and launched independently) to obtain keys from the dstack KMS, which itself runs as a TDX CVM. How dstack-os images for SEV-SNP would be built in the future — and how they would communicate with a dstack KMS host — is a separate concern that can be addressed later with dedicated approaches.

Regarding your questions about image build and launch — for our SecretVM case specifically:

• The SEV-SNP OS image build can be found here: https://github.com/scrtlabs/secret-vm-build/tree/amd
• The launch scripts and the scripts handling communication with the dstack KMS for the AMD SEV-SNP case are here: https://github.com/scrtlabs/secret-vm-ops/tree/amd/scripts

As for the environment — we expect these CVMs to run on bare metal.

Thanks for the detailed writeup.

There are two concerns with this approach.

1. A separate GetAppKeyAmd API increases maintenance burden and surface area

Every additional API endpoint is another code path to audit, keep in sync with policy changes, and reason about during security reviews. The asymmetry between the TDX and AMD paths (different transport, different root-of-trust verification, different response encryption) means bugs or policy updates would need to be applied and tested in two places independently. The preference is to converge on a single key provisioning model rather than fan out.

2. Without vTPM/SVSM, the host can manipulate the AMD CVM in ways the KMS cannot detect

The current implementation relies on AMD SEV-SNP measured direct boot, where MEASUREMENT covers OVMF + kernel + initrd + cmdline — but not ACPI tables. This is exactly the gap described in AMD-SB-3012: a malicious host can inject arbitrary ACPI AML into the guest and have it executed, potentially compromising the guest before any key provisioning happens. The KMS currently has no way to distinguish a legitimately booted AMD CVM from one that has been tampered with at the ACPI layer.

The right fix is to introduce a vTPM backed by Coconut-SVSM running at VMPL0. SVSM is hardware-isolated from the guest OS (via AMD's RMP/VMPL enforcement), measures ACPI tables and other boot components into vTPM PCRs before the guest OS runs, and can produce a TPM quote whose trust chain is anchored to the SNP attestation report (MEASUREMENT covers SVSM code, VMPL=0 is hardware-attested, and the vTPM EK is bound via REPORT_DATA). The KMS can then verify this full chain.

Beyond fixing the security gap, vTPM/SVSM would also allow the AMD attestation model to converge with how dstack handles non-TDX environments. In dstack-cloud's GCP support, a unified emit_runtime_event abstraction already extends RTMR3 on TDX and extends a vTPM PCR otherwise — the KMS attestation path is shared. An AMD CVM with SVSM-backed vTPM could plug into exactly this model, making the KMS verification logic unified rather than forked.

This is significantly more work than the current PR — the suggestion would be to address the vTPM/SVSM integration before merging. Happy to discuss the design if that's useful.