​
Security Architecture

Establishing hardware-rooted security at scale presents significant challenges. It is not sufficient to simply deploy specialized hardware such as Intel TDX; a comprehensive framework is also required to ensure that trust can be established, measured, and remotely verified by any party, regardless of their location or privilege level. Intel TDX provides the foundational capability for remote attestation by enabling the creation of isolated Trusted Domains (TDs), each capable of generating cryptographically signed evidence of its current state. However, even with these capabilities, TDs remain potentially vulnerable to a variety of attack vectors, including those originating from privileged system software or compromised infrastructure. The core security challenge is to guarantee that only genuine, uncompromised environments are able to prove their integrity. This is essential for scenarios where highly confidential data or workloads must be shared or processed under strict confidentiality agreements, allowing authorized parties to interact with sensitive resources without risk of tampering or data leakage. To address these challenges, the dStack framework is architected around the principles of remote trusted domains. It leverages the full suite of TDX’s standards for measurement, event logging, and attestation, and augments them with advanced mechanisms such as cryptographic key management, policy enforcement, and continuous verification. The following subsections detail the architectural decisions and mechanisms that underpin this approach, providing a clear conceptual foundation for understanding how dStack delivers secure, auditable, and scalable confidential computing on top of Intel TDX.

​
Hardware Root of Trust

The attestation system in dStack is fundamentally anchored in Intel TDX CPU instructions, which are designed to produce TD reports that are cryptographically resistant to forgery—even in the presence of malicious hypervisors or privileged host software. All critical low-level operations interact directly with the CPU using instructions such as tdx_att_get_report and tdx_att_get_quote. This direct invocation ensures that the root of trust is established in hardware (silicon), minimizing the attack surface and eliminating reliance on potentially compromised software layers.

​
Cryptographic Foundations

Each attestation quote generated by the system is protected by an ECDSA signature, using attestation keys provisioned directly by Intel. This cryptographic process, as implemented in the tdx-attest crate, guarantees that only authentic TDX hardware can produce valid attestation quotes. Every quote encapsulates a 1024-byte TDX report, which includes the current values of all measurement registers and a 64-byte report data field. This report data field enables cryptographic binding of application-specific data to the attestation, supporting advanced use cases such as secure key provisioning and policy enforcement.

​
Runtime Measurement Registers (RTMRs)

The TDX security architecture is structured around four Runtime Measurement Registers (RTMRs), each of which defines a distinct trust boundary within the system:
  • RTMR0: Captures the virtual hardware configuration, such as CPU count and memory size.
  • RTMR1: Records the measurement of the Linux kernel.
  • RTMR2: Contains measurements of the kernel command line and the initramfs.
  • RTMR3: Tracks application runtime measurements, including compose hashes, instance IDs, and other application-specific data.
Each RTMR is extended and updated using SHA-384 hashing, which provides strong cryptographic guarantees for state tracking and tamper evidence. This mechanism creates a verifiable, append-only log of all measurement events, as detailed in linux.rs#L129 and further explained in the tdx-attest crate. By chaining measurements in this way, the system ensures that any modification to the boot or runtime environment is immediately detectable and can be independently audited by external verifiers.

​
Event Log Security

dStack’s attestation system maintains a cryptographically secure event log, recording every RTMR extension (linux.rs#L105). Each event contains the measurement register index, event type, descriptive metadata, and payload. The replay logic (attestation.rs#L421) enables auditors to verify that RTMR values are consistent with all prior measurements, providing full transparency for the system’s integrity chain.
The security architecture is the backbone of dStack’s TDX attestation, ensuring that every component and event is measured, logged, and verifiable. The next section explores how these architectural elements are leveraged in the quote generation and verification process.