From 0fb189dfbb443d8d131546c58fba674229b3b105 Mon Sep 17 00:00:00 2001 From: "Joshua J. Bouw" Date: Fri, 22 Aug 2025 01:49:12 +0400 Subject: [PATCH] chore: various readme improvements --- dstack-helios-tdx/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/dstack-helios-tdx/README.md b/dstack-helios-tdx/README.md index 92aa970..bcc9679 100644 --- a/dstack-helios-tdx/README.md +++ b/dstack-helios-tdx/README.md @@ -10,11 +10,11 @@ All communications are carried through the `/overlay` library, a stripped down v > NB: we're not necessarily advocating for dstack nodes to infer the cluster they want to join based on operator choices. This is an experiment. -When a node is spinned up without specifying peers it assumes it's being bootstrapped and creates it own view of the dstack network. Other peers can now be spun up and join the bootstrapped node. +When a node is spun up without specifying peers it assumes it's being bootstrapped and creates it own view of the dstack network. Other peers can now be spun up and join the bootstrapped node. When they request to join the bootstrapped node a P2P connection over QUIC is established between the two peers as follows: -``` +```IntentsIntents Peer wants to join bootstrap B_0 -> Peer establishes connection with B_0. Both nodes send their attestation paired with their local pubkey -> mutual authentication happens |-> mutual authentication establishes a secure encrypted communication channel between the two nodes. @@ -27,11 +27,11 @@ Among other things, this approach ensures that applications where various TEEs w > NB: there's situations where the overlay will want to share with multiple TEEs of the same authorization group. In such situations sharing a secret across authorization groups can be beneficial for networking workload on the encryption; on the full implementation we reserve a message type for this. -> NB: replication is currently **not safe** as it's **not checking measurements** (any TDX node can fake the shared dstack signature!!). Checking measurements is fairly trivial to add once the light clients app is measured into rtmr3 and we can easily deterministically reproduce application measurements. Hopefully we would be using something like https://github.com/kvinwang/dstack-mr. +> NB: replication is currently **not safe** as it's **not checking measurements** (any TDX node can fake the shared dstack signature!!). Checking measurements is fairly trivial to add once the light clients app is measured into rtmr3, and we can easily deterministically reproduce application measurements. Hopefully we would be using something like https://github.com/kvinwang/dstack-mr. # A meta-dstack note -As you'll learn when applying what is instructed in the `meta-dstack-patch`, this very first example relies on the app logic being within the TEE and there is a minimal abstraction over environment variables to have measurements be easily reproducible. The reason is because we don't expect to be maintaining the base TEE dstack image ourselves so haven't do much work on enabling virtualization and a more structured approach to measurements like splitting app and system measurements. +As you'll learn when applying what is instructed in the `meta-dstack-patch`, this very first example relies on the app logic being within the TEE and there is a minimal abstraction over environment variables to have measurements be easily reproducible. The reason is that we don't expect to be maintaining the base TEE dstack image ourselves so haven't done much work on enabling virtualization and a more structured approach to measurements like splitting app and system measurements. ## Modularization