AMD SEV-SNP support (tracking)

3つの未チェック項目から始めてください。#746 の KDS fetch のハードニング、SNP guest image と kernel-hash のリリース作業、そして KMS key-provider の検証です。既存の設計については #703 を読み、cloud の作業は #125 で分離してください。bare-metal SNP がハードニングされ、固定された kernel hash とともにリリースされ、意図した key provider のみを信頼すれば完了です。

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:

• SNP reports verified against pinned AMD roots
• App identity bound to the hardware-signed report
• BadAML/ACPI closed by a kernel AML sandbox shipping in the guest image
• Key release fail-closed by default
• Opt-in via --platform amd-sev-snp, auto-detected on AMD hosts

Left before it's "supported"

• Harden the AMD KDS fetch so a throttled host can't hang bootstrap (#746)
• Ship the SNP guest image in a tagged release and pin its kernel hash
• Small KMS hardening: confirm the key provider the guest trusts is actually ours

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

• #703 (merged)
• #746 (KDS hardening)
• #125 (cloud plumbing)
• Closed during triage: #443, #744