Dstack-TEE / Dstack-TEE/dstack

GPU attestation gate follow-ups: commit to RTMR, enforce CC mode, cache OCSP, SNP

未關閉
#778 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
Rust
星號
544
分支
96
平均合併
23 小時 40 分鐘
30 天內合併 PR
126

描述

## Context

The GPU attestation gate landed in #765 and Dstack-TEE/meta-dstack#83. It runs local `nvattest` before key provisioning, and fails closed if an attached GPU can't attest. That's a good foundation, but a few follow-ups remain before it's a complete, remotely-verifiable trust story. Design context is in #751.

## Follow-ups

- [x] **Commit the attestation result into an RTMR, not report_data.** Today it only lands in a file under `/run`, and the planned binding would put it in report_data. But report_data can be set by any app to any value. So a VM with no GPU could copy a real VM's value and pass, and a verifier couldn't tell the two apart. If dstack-util instead emits a `gpu-attestation` event before `system-ready`, the value lands in RTMR3, which is measured and append-only, so KMS and remote verifiers can actually trust it. It also closes a gap we have today: a no-GPU VM with `verify_gpu=true` currently looks identical to a verified one.

- [x] **Require CC mode on, and reject DEVTOOLS.** We run `nvattest` with no policy file, so success comes down to the `x-nvidia-overall-result` claim. That claim proves the GPU is genuine and its measurements match, but it does not require CC mode to be on. That means a GPU in DEVTOOLS mode, where memory encryption is off, can still pass. A small Rego policy that requires CC on and debug off would close this.

- [x] **Don't let OCSP turn into a boot DoS.** Local verify makes a live call to NVIDIA's OCSP endpoint at boot (that's what the chrony step is for). Because the gate is fail-closed, anyone who blocks that endpoint stops every GPU VM from booting. That includes a malicious host, but also an egress-restricted or air-gapped deployment, or plain NVIDIA downtime. Caching or stapling the OCSP response would avoid it.

- [ ] **Add SNP support.** The RTMR approach doesn't port to SEV-SNP, because SNP has no runtime measurement register: its identity comes from launch-time HOST_DATA. So SNP will need a vTPM before the same binding works. Worth tracking now, otherwise SNP quietly ships a weaker binding.

Refs: #765, Dstack-TEE/meta-dstack#83, #751.

貢獻指南

開啟貢獻指南

研究方向

從 #751 中的設計背景,以及 #765 和 Dstack-TEE/meta-dstack#83 中引用的現有 attestation 工作開始。追蹤 system-ready 周圍 dstack-util 的事件路徑,並確定 SNP/vTPM 整合邊界;完成的標準是 SNP 在不依賴 RTMR 的情況下具備相同的可遠端驗證繫結。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
rust
領域
security
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
冷清
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。