Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

AMD SEV-SNP support (tracking)

Đang mở
  • Có gì không ổn?
#713 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
aws, azure, gcp
Lĩnh vực
cloud, infrastructure, security

Hướng nghiên cứu

Bắt đầu với ba mục chưa được đánh dấu: hardening KDS fetch trong #746, công việc release của SNP guest image và kernel-hash, và xác minh KMS key-provider. Đọc #703 để biết design hiện có và giữ riêng phần công việc cloud trong #125. Hoàn tất nghĩa là bare-metal SNP được hardening, được phát hành với một kernel hash được ghim, và chỉ tin cậy key provider đã định.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
551
Fork
97
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
182

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Dstack-TEE/dstack

Tất cả issue của Dstack-TEE/dstack

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.