Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

AMD SEV-SNP support (tracking)

Offen
  • Stimmt etwas nicht?
#713 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
aws, azure, gcp
Bereich
cloud, infrastructure, security

Rechercherichtung

Beginne mit den drei nicht abgehakten Punkten: der Härtung des KDS-Fetch in #746, der Release-Arbeit für das SNP guest image und kernel-hash sowie der Verifizierung des KMS key-provider. Lies #703 zum bestehenden Design und halte die Cloud-Arbeit in #125 getrennt. Als erledigt gilt die Aufgabe, wenn bare-metal SNP gehärtet und mit einem festgelegten kernel hash veröffentlicht ist und nur dem vorgesehenen key provider vertraut.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
551
Forks
97
Ø Merge
1 T. 3 Std.
Gemergte PRs (30 T.)
199

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Dstack-TEE/dstack

Alle Issues in Dstack-TEE/dstack

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.