You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/amd-sev-snp-review-readiness.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -119,8 +119,8 @@ After those fixes, the manual smoke progressed through full dstack-managed SNP g
119
119
- Configfs TSM report collection falls back to the SEV-SNP extended-report ioctl when configfs does not carry certificate collateral.
120
120
- If verifier-side evidence still lacks ASK/VCEK collateral, the verifier can fetch AMD KDS ARK/ASK/VCEK using the report `chip_id` and reported TCB, then verify the signed report fail-closed.
121
121
- KMS measurement recomputation now uses the image's original kernel cmdline for SNP launch measurement, while app identity is bound by MrConfigV3/HOST_DATA instead of appended cmdline fields.
122
-
- VMM now extracts the image OVMF SEV metadata and OVMF launch digest seed, includes them in the `sev_snp_measurement` document string, and passes that through the guest to KMS; KMS no longer needs a single locally configured `ovmf_path`, so different image/OVMF versions can be verified by their self-contained launch inputs.
123
-
- SNP `BootInfo.os_image_hash` is the canonical image-invariant projection of the verified launch inputs: rootfs identity is derived from the measured `dstack.rootfs_hash=...` cmdline parameter, and the hash covers the cmdline, kernel/initrd hashes, and OVMF hash/sections while excluding per-deployment values like vCPU count/model and guest features.
122
+
- VMM now passes the image's split `measurement.snp.cbor` material plus per-launch SNP fields through the guest to KMS; KMS no longer needs a single locally configured `ovmf_path`, so different image/OVMF versions can be verified by their self-contained launch inputs.
123
+
- SNP `BootInfo.os_image_hash` is the unified image digest (`sha256(sha256sum.txt)`). The `measurement.snp.cbor` entry in `sha256sum.txt` commits to the cmdline, kernel/initrd hashes, and OVMF hash/sections while excluding per-deployment values like vCPU count/model and guest features.
124
124
125
125
Latest sanitized remote smoke result with PR-built host binaries and a coherent `MACHINE = "sev-snp"` guest image:
Copy file name to clipboardExpand all lines: docs/security/security-model.md
+66Lines changed: 66 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,6 +92,47 @@ dstack implements layered verification from hardware to application. Each layer
92
92
93
93
**Key management layer.** The KMS root CA public key hash is recorded in RTMR3 as the key-provider event. This binds your workload to a specific KMS instance. The KMS itself runs in a TEE with its own attestation quote, so you can verify the KMS the same way you verify any workload.
94
94
95
+
### How `os_image_hash` becomes trusted
96
+
97
+
The `os_image_hash` carried in `vm_config` is not trusted just because the guest
98
+
or host reports it. The verifier first validates the hardware-signed quote, then
99
+
uses the quoted measurements to bind `os_image_hash` to the software that
100
+
actually booted.
101
+
102
+
For the full-image TDX path, the verifier obtains the OS image identified by
103
+
`os_image_hash`, checks the image checksum manifest, recomputes the expected
104
+
MRTD and RTMR0-2 from the image and VM configuration, and requires those values
105
+
to match the measurements in the quote. If the host substitutes either the image
106
+
hash or the VM configuration, the recomputed measurements no longer match the
107
+
quote.
108
+
109
+
For the no-image-download TDX lite path and the AMD SEV-SNP path,
110
+
`os_image_hash` is the unified image identity: `sha256(sha256sum.txt)`. The
111
+
`sha256sum.txt` file is the image checksum manifest generated at image build
112
+
time. It is a text file whose lines contain a SHA-256 digest and relative file
113
+
name for each manifest entry, such as `metadata.json`, the kernel, initrd,
114
+
firmware, and the split measurement file. Some launch-critical artifacts are
115
+
represented indirectly instead of as direct manifest entries: for example, the
116
+
rootfs is committed by the measured `dstack.rootfs_hash` kernel command-line
117
+
parameter, and the SEV firmware is committed by `measurement.snp.cbor`. The exact
118
+
`sha256sum.txt` bytes are hashed, so the manifest contents, file names, ordering,
119
+
and line endings are all part of the image identity.
120
+
121
+
The attestation carries a copy of the image's `sha256sum.txt` plus the platform
122
+
specific measurement material (`measurement.tdx.cbor` or
123
+
`measurement.snp.cbor`). The verifier checks that:
124
+
125
+
1.`sha256(checksum_file) == os_image_hash`;
126
+
2. the checksum file contains the expected `measurement.*.cbor` entry and that
127
+
entry hashes to the supplied measurement material;
128
+
3. the supplied measurement material replays to the hardware-signed TDX
129
+
MRTD/RTMR values or SEV-SNP launch `MEASUREMENT`/`HOST_DATA`.
130
+
131
+
Only after these checks pass does the verifier treat the returned
132
+
`os_image_hash` as the measured OS image identity. Downstream authorization
133
+
systems can then compare that trusted value against an allowlist or governance
134
+
contract.
135
+
95
136
## Verification Checklist
96
137
97
138
Use this checklist to verify a workload running in a dstack CVM.
@@ -124,6 +165,31 @@ This is also reflected at the source: the event log shipped alongside an attesta
124
165
125
166
The reason boot-time event log entries (RTMR0-2) are dropped is that **nothing downstream consumes them**. Verification recomputes the OS-layer measurements directly from the signed `rt_mr0/1/2` values and compares them to independently reproduced expected measurements, so the corresponding boot event log would be redundant. Keeping it would only bloat the RA-TLS certificate and expose extra detail without adding any verification capability. RTMR3, by contrast, is runtime-extended (compose-hash, key-provider, instance-id, and application-emitted events), so its event log is the only one with a real consumer — the replay that proves what was extended into RTMR3.
126
167
168
+
### Why TDX lite mode does not validate ACPI table contents
169
+
170
+
TDX lite mode verifies the OS image without downloading the image and without
171
+
running QEMU to regenerate ACPI tables. It still uses the three RTMR0 `ACPI
172
+
DATA` digests from the attestation event log as measurement inputs. The guest
173
+
labels those three events as `acpi-loader`, `acpi-rsdp`, and `acpi-tables`
174
+
before exposing the event log, and the verifier checks that the recomputed RTMR
175
+
values match the hardware-signed quote. What it does not do is reconstruct and
176
+
byte-compare the full ACPI table contents.
177
+
178
+
This is safe for dstack's threat model because ACPI tables are treated as
179
+
untrusted host-provided platform description, not as trusted guest code. The
180
+
dangerous executable part of ACPI is AML (ACPI Machine Language): malicious AML
181
+
can try to use `SystemMemory` operation regions through the Linux ACPICA
182
+
interpreter to read or write guest physical memory. dstack kernels include the
which hooks the ACPI `SystemMemory` region handler, walks the guest page tables,
185
+
and denies AML access to encrypted/private guest RAM. AML can only access
186
+
unencrypted/shared mappings.
187
+
188
+
Therefore, an infrastructure operator can still provide bad ACPI data and cause
189
+
misconfiguration or denial of service, but unvalidated ACPI/AML cannot tamper
190
+
with confidential private memory or extract secrets. That residual availability
191
+
risk is already outside dstack's confidentiality/integrity guarantees.
192
+
127
193
### TCB status is surfaced, not gated, during verification
128
194
129
195
dstack's `validate_tcb` does not reject a quote based on its TCB status string (`UpToDate`, `OutOfDate`, `ConfigurationNeeded`, `SWHardeningNeeded`, ...). It only enforces hard invariants: debug mode must be off, and the SEAM/service-TD measurements must be well-formed. The verified report carries the `status` field through to the caller.
0 commit comments