GPU attestation gate follow-ups: commit to RTMR, enforce CC mode, cache OCSP, SNP
还没有人认领这个 Issue。
评估
调研方向
从 #751 中的设计背景以及 #765 和 Dstack-TEE/meta-dstack#83 中引用的现有 attestation 工作开始。跟踪 system-ready 周围 dstack-util 的事件路径,并确定 SNP/vTPM 集成边界;完成的标准是 SNP 在不依赖 RTMR 的情况下具备相同的可远程验证绑定。
由索引模型根据 Issue 内容生成。
描述
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
-
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 agpu-attestationevent beforesystem-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 withverify_gpu=truecurrently looks identical to a verified one. -
Require CC mode on, and reject DEVTOOLS. We run
nvattestwith no policy file, so success comes down to thex-nvidia-overall-resultclaim. 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. -
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.
- 主要语言
- Rust
- 星标
- 551
- 派生
- 97
- 平均合并
- 1 天 8 小时
- 30 天内合并 PR
- 182
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Dstack-TEE/dstack 的其他 Issue
-
难度 5/5 一周以上 新手友好度 35/100
Dstack-TEE/dstack#1384 ·
-
难度 5/5 一周以上 新手友好度 30/100
Dstack-TEE/dstack#1301 ·
-
难度 3/5 1-2 天 新手友好度 55/100
Dstack-TEE/dstack#1300 ·
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1299 ·
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1298 ·
查看 Dstack-TEE/dstack 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
-
bug core
难度 2/5 1-3 小时 新手友好度 86/100
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW 未关闭fuzz
难度 2/5 1-3 小时 新手友好度 82/100
ClickHouse/ClickHouse#122114 ·
-
难度 1/5 1 小时以内 新手友好度 92/100
linebender/vello_svg#90 ·
-
难度 2/5 1-3 小时 新手友好度 74/100