Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

AMD SEV-SNP support (tracking)

Abierto
  • ¿Algo no está bien?
#713 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
aws, azure, gcp
Área
cloud, infrastructure, security

Línea de trabajo

Empieza por los tres elementos sin marcar: el endurecimiento de KDS fetch en #746, el trabajo de release de SNP guest image y kernel-hash, y la verificación de KMS key-provider. Lee #703 para consultar el diseño existente y mantén separado el trabajo de cloud en #125. Se considera terminado cuando bare-metal SNP esté endurecido, publicado con un kernel hash fijado y confíe únicamente en el key provider previsto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
555
Forks
97
Merge medio
1 d 3 h
PR fusionados (30 d)
199

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Dstack-TEE/dstack

Todos los issues de Dstack-TEE/dstack

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.