Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions dstack-helios-tdx/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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

Expand Down