Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

AMD SEV-SNP support (tracking)

Aperta
  • Qualcosa non va?
#713 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
aws, azure, gcp
Ambito
cloud, infrastructure, security

Direzione di ricerca

Inizia con i tre elementi non selezionati: l’hardening di KDS fetch in #746, il lavoro di release di SNP guest image e kernel-hash e la verifica di KMS key-provider. Leggi #703 per il design esistente e mantieni separato il lavoro cloud in #125. È completato quando bare-metal SNP è sottoposto ad hardening, rilasciato con un kernel hash fissato e si fida solo del key provider previsto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

documentation

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
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.

Lingua principale
Rust
Stelle
551
Fork
97
Merge medio
1g 3h
PR unite (30g)
199

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Dstack-TEE/dstack

Tutte le issue di Dstack-TEE/dstack

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.