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
The RPC only meaningfully works on TDX (RTMR3 extension), is rarely used,
and cannot be implemented faithfully in the simulator or across TEEs. Apps
that need extra runtime measurements should use native TEE interfaces.
Keep emit_runtime_event for guest boot measurements in dstack-util.
Copy file name to clipboardExpand all lines: docs/native-tee-interfaces.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -144,4 +144,4 @@ For configfs-tsm, permissions can be more provider-specific. If your main proces
144
144
145
145
On TDX, RTMR3 is an append-only runtime measurement register. It is useful when a launcher measures code or configuration first, then hands permission and execution to the measured code.
146
146
147
-
Use `/EmitEvent` through `/var/run/dstack.sock` when you want dstack's event log and verifier to replay an application runtime measurement. If your application extends RTMR3 directly through native interfaces, your application owns the event-log story for those extensions.
147
+
dstack itself extends RTMR3 during guest boot (compose-hash, key-provider, instance-id, and related runtime events). Applications that need additional runtime measurements should extend RTMR3 through the native TDX / TSM measurement interfaces documented above and own the event-log story for those extensions.
Copy file name to clipboardExpand all lines: docs/security/security-model.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -166,7 +166,7 @@ dstack replays an event log only for RTMR3. RTMR0-2 (and MRTD) are not replayed
166
166
167
167
This is also reflected at the source: the event log shipped alongside an attestation is stripped down to RTMR3 entries before it is embedded. `VersionedAttestation::into_stripped()` keeps only events with `imr == 3` (see `dstack-attest/src/attestation.rs`), and verification only ever replays those runtime events against `rt_mr3` (`verify_tdx_quote_with_events` / `decode_mr_tdx_from_quote`).
168
168
169
-
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.
169
+
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 other guest boot events), so its event log is the only one with a real consumer — the replay that proves what was extended into RTMR3.
170
170
171
171
### Why TDX lite mode does not validate ACPI table contents
Empty response with HTTP 200 status code on success.
203
-
204
-
### 6. Sign (not yet released)
177
+
### 5. Sign (not yet released)
205
178
206
179
Signs a payload.
207
180
@@ -238,7 +211,7 @@ curl --unix-socket /var/run/dstack.sock -X POST \
238
211
}
239
212
```
240
213
241
-
### 7. Verify (not yet released)
214
+
### 6. Verify (not yet released)
242
215
243
216
Verifies a signature.
244
217
@@ -273,7 +246,7 @@ curl --unix-socket /var/run/dstack.sock -X POST \
273
246
}
274
247
```
275
248
276
-
### 8. Attest
249
+
### 7. Attest
277
250
278
251
Generates a versioned attestation with the given report data. Returns a dstack-defined attestation format that supports different attestation modes across platforms.
279
252
You can submit the returned `attestation` directly to the verifier `/verify` endpoint.
> This feature isn't available in the simulator. We recommend sticking with `report_data` for most cases since it's simpler and safer to use. If you're not super familiar with SGX/TDX attestation quotes, it's best to avoid adding data directly into quotes as it could cause verification issues.
0 commit comments