Intel TDX and SGX Overview

• Intel’s TDX and SGX are hardware-enforced Trusted Execution Environments that secure code execution with distinct isolation models.
• SGX isolates process-level enclaves using memory encryption and attestation, while TDX protects entire VMs through secure arbitration and multi-key encryption.
• Both technologies address performance and integration challenges in cloud platforms by trading off between fine-grained control and legacy workload support.

Intel's Trusted Domain Extensions (TDX) and Software Guard Extensions (SGX) are architectural security technologies that underpin the evolution of hardware-enforced Trusted Execution Environments (TEEs) in server and cloud platforms. Both mechanisms focus on the confidential execution of code and data, but they address different usage models and offer distinct trade-offs in performance, security granularity, and ease of integration for legacy and modern applications. This article surveys the core principles, technical underpinnings, practical challenges, and comparative evaluations of Intel TDX and SGX in both standalone and industry-standardized execution contexts.

1. Architectural Foundations and Core Mechanisms

SGX introduces the enclave abstraction—a protected virtual memory region within a user-space application process. Each SGX enclave is isolated from all other software, including privileged system software (OS, hypervisor). Memory encryption, integrity verification (using the Memory Encryption Engine and a secure MAC tree), and attestation—including the measurement registers such as MRENCLAVE and MRSIGNER—are the fundamental constructs ensuring that enclave code and data remain confidential and verifiable (Nyman et al., 2015, Mofrad et al., 2017, Pires, 2020). Entry to and exit from the enclave is managed by specific hardware instructions: ECREATE, EENTER, EEXIT, AEX, ERESUME, and EINIT.

TDX generalizes this concept from the process level to the virtual machine (VM) level, introducing the “Trust Domain” (TD)—a confidential VM in which all guest memory and CPU state are cryptographically isolated from the host, hypervisor, and other VMs. TDX is implemented via a new Secure-Arbitration Mode (SEAM), in which the TDX Module manages TD lifecycle and runtime (Cheng et al., 2023). TDX leverages Multi-Key Total Memory Encryption (MKTME), partitioning memory into private (TD-bound) and shared regions via Host Key IDs (HKIDs). Each memory cache line that belongs to a TD is encrypted with a TD-unique HKID and ownership is tracked with the “TD Owner bit.” Integrity is protected using both logical and cryptographic (MAC-based) mechanisms.

Comparison Table (SGX vs TDX):

	SGX (Process-based)	TDX (VM-based)
Scope	Application-level (enclave in process)	Full VM (Trust Domain)
Isolation	EPC partitioning, MEE	VMX SEAM mode, MKTME, HKID partitioning
State Prot.	Memory, partial CPU state	Memory + full VM CPU state
Attestation	Quoting Enclave, MRENCLAVE/MRSIGNER	Remote attestation, quote using QE
OS Trust	Untrusted OS, OS manages page tables	Untrusted hypervisor, module manages EPTs

SGX provides fine-grained isolation for selected code/data, with support for remote attestation and modular code porting, but with tighter memory constraints (EPC limit), no direct system call support, and explicit application partitioning. TDX instead allows lift-and-shift of legacy workloads by providing VM-level isolation and encryption, with hardware mediation of all host/guest boundaries (Cheng et al., 2023, Coppolino et al., 1 Aug 2024).

2. Security Models, Trusted Computing Base, and Attestation

SGX's security model protects enclave memory (confidentiality/integrity) and provides measurement registers (MRENCLAVE, MRSIGNER) for both local and remote attestation. Enclave binaries are signed, allowing an external party to verify correct execution via attestation reports produced by the Quoting Enclave (QE). Secrets can be provisioned post-attestation to minimize leakage (Nyman et al., 2015, Fuhry et al., 2017, Cheng et al., 2023).

TDX expands protection to the full VM state, including all vCPUs and memory contents. The TDX module manages extended page tables for guest memory and maintains robust attestation chains by combining both build-time and runtime hash chains (RTMR, MRTD) using cryptographic measurements (e.g., RTMR[index] = SHA384(RTMR[index] || value)). The attestation process produces a TD quote that is rooted in an Intel-issued Provisioning Certification Key (PCK) (Cheng et al., 2023).

Both technologies enable the implementation and isolation of virtual TPMs (vTPMs) within their trust boundaries, permitting measured boot and secure key management for cloud workloads (Narayanan et al., 2023). A vTPM inside a TD or enclave uses ephemeral or sealed state, and generates standard attestation evidence by recursively updating PCRs (Platform Configuration Registers) via hash chaining (e.g., PCR_new = hash(PCR_old || input_data)).

3. Standardization, Accessibility, and Interface Layering

A central challenge for making TEEs accessible is interface standardization. Early work mapped GlobalPlatform (GP) TEE Core API interfaces—originally designed for split-world TEEs like ARM TrustZone—to SGX's enclave abstraction (Nyman et al., 2015). Because SGX enclaves cannot perform system calls, Open-TEE's approach splits the Trusted Application (TA) into two threads: one for I/O (forwarding requests to a Manager component for services such as secure storage) and one for enclave-resident logic. The interface mapping is strict; for example:

$\begin{array}{l|l} \textbf{GP TEE Core API} & \textbf{Mapped SGX Operations} \ \hline \text{TA\_CreateEntryPoint} & \text{ECREATE, EINIT, EENTER, EEXIT} \ \text{TA\_DestroyEntryPoint} & \text{EENTER, EEXIT} \ \text{TA\_OpenSessionEntryPoint} & \text{EENTER, AEX, ERESUME, EEXIT} \ \text{TA\_InvokeCommandEntryPoint} & \text{EENTER, AEX, ERESUME, EEXIT} \ \end{array}$

This architectural separation and interface adaptation lower the barrier for developers targeting both SGX and (potentially) TDX by decoupling core logic from OS/manager interaction (Nyman et al., 2015). A plausible implication is that the same GP interface mapping paradigm could be applied to TDX in order to offer standardized, developer-friendly APIs for VM-confidential computing.

4. Security Limitations and Side Channels

Despite formal security proofs against direct memory access, both SGX and TDX face persistent microarchitectural side channel threats. Notably:

• Page table and TLB-based leakage: In SGX, untrusted OS control of page tables permits attacks correlating page faults or accessed/dirty bits to enclave control flow—for example, triggering deterministic page faults on sensitive operations (Strackx et al., 2017). The Heisenberg defense proactively defends by preloading TLB entries at enclave (re-)entry, preventing new page table walks during secret-dependent execution (i.e., ensuring all pages p in S have T(p) loaded in TLB before any secrets are computed). The hardware variant introduces a block-eresume bit to force preloading, yielding low (<10%) overhead; the TSX software variant suffers high abort rates under load.
• Interface-based side channels: By logging ECALL/OCALL invocations—names, input sizes, and timing—the OS can reconstruct input classifications (e.g., tracked web pages in a network function virtualization platform) with high accuracy (87.6%) (Wang et al., 2018). Countermeasures include data-size padding and batch request processing.
• Enclave-to-host attacks: The asymmetric SGX trust model (host cannot read enclave, but enclave can access host address space) enables SGX-ROP attacks where a malicious enclave bypasses ASLR, stack canaries, and integrity checks using TSX-based fault-resistant memory reads (TAP) and write-anywhere primitives (CLAW) (Schwarz et al., 2019). In the absence of bidirectional memory access restrictions, TDX may be susceptible to similar attacks unless stricter architectural isolation is enforced.

Careful hardware-software co-design is therefore essential for both SGX and TDX to mitigate leaking control flow or enabling cross-domain privilege escalation (Strackx et al., 2017, Wang et al., 2018, Schwarz et al., 2019).

5. Performance, Scalability, and Benchmarking

SGX performance is dominated by enclave transition overhead (17,000 cycles per ECALL/OCALL (Kumar et al., 2022)), EPC size limitations (92–128 MB), and the cost of EPC paging or TLB flushes. When working set size exceeds EPC, abrupt and severe throughput degradation can be observed (metrics such as dTLB misses and EPC evictions increase super-linearly). I/O and system interactions also impose additional enclave crossings, increasing latency and reducing throughput. Library OS approaches (GrapheneSGX) contribute only about ±10% overhead compared to native SGX (Kumar et al., 2022).

The arrival of SGXv2 and, more prominently, TDX shifts the performance bottleneck. SGXv2 removes strict EPC size constraints, allowing VMs/TDs to use gigabytes of protected memory. However, hardware side-channel mitigations (e.g., always-on speculative store bypass) and certain OS interaction costs (thread synchronization, memory allocation) can still result in substantial slowdowns for specific workloads (e.g., histogram creation in analytic queries is up to 225% slower inside SGXv2 until optimized by loop unrolling and vectorization) (Lutsch et al., 18 Mar 2024). Memory-intensive and I/O-intensive workloads perform better under TDX than under SGX with Gramine or Occlum runtimes, but a 28.6% average overhead (relative to Native) is present for I/O-intensive tasks; TDX also consistently outperforms AMD SEV when CPU performance is normalized (Coppolino et al., 1 Aug 2024).

For CPU-bound applications—e.g., TensorFlow inference—Gramine-SGX and, in some cases, TDX can approach or even outperform Native runs. SGX's security granularity is higher due to process-based isolation, but this comes at the expense of higher application porting complexity, increased TCB, and greater resource overhead when scaling up workloads (Coppolino et al., 1 Aug 2024).

6. Portability, Application Domains, and Evolution

SGX is better suited for scenarios where selective confidentiality is needed within otherwise untrusted OS-controlled environments, such as cryptographic key management, privacy-preserving analytics, and privacy-aware middleware (Fuhry et al., 2017, Pires, 2020, Widanage et al., 2021). SGX-based systems have demonstrated secure analytical query processing, encrypted search (e.g., HardIDX), and genomic analytics via data partitioning and hybrid secure containerization (Fuhry et al., 2017, Widanage et al., 2021).

TDX is designed for VM-level protection, enabling confidential computing in public cloud and multi-tenant environments without requiring extensive application refactoring. Its transparent deployment model, in combination with features such as multi-key memory encryption (MKTME) and hardware resource partitioning, is targeted at regulated or privacy-sensitive sectors needing full VM isolation (Cheng et al., 2023, Coppolino et al., 1 Aug 2024). TDX's early comparative evaluations show promise in memory and I/O-intensive workloads, benefitting from the "lift-and-shift" approach (Coppolino et al., 1 Aug 2024).

7. Limitations, Misconceptions, and Future Directions

Myths regarding TEE-assisted malware (e.g., using SGX or TDX to "cloak" malicious code) have been systematically debunked. Running malware in an enclave imposes significant logistical and operational limitations: lack of persistent presence, restricted privileges, dependent communication, and greater maintenance burden; memory encryption does not render malware undetectable at the behavioral or system level (Küçük et al., 2022). Both SGX and TDX instead restrict rather than enhance the asymmetry of attack surfaces available to malware authors.

State-of-the-art hardening (e.g., dynamic program partitioning for side channel suppression using TSX (Tang et al., 2022)) and proposals for TEE-TPM symbiosis (e.g., TALUS for securely outsourcing SGX cryptographic secrets to hardware TPM) represent the trajectory of future TEE research (Chakraborty et al., 2023).

A plausible implication is that as VM-based TEEs such as TDX mature, their adoption will depend on the balance between ease of deployment and the tighter attack surface achieved by process-based solutions; emerging workloads that combine the fine-grained control of SGX with VM-level isolation of TDX—potentially via nested or hybrid architectures—are likely to define future confidential computing paradigms.

---

References: (Nyman et al., 2015, Fuhry et al., 2017, Mofrad et al., 2017, Strackx et al., 2017, Wang et al., 2018, Schwarz et al., 2019, Pires, 2020, Widanage et al., 2021, Kumar et al., 2022, Küçük et al., 2022, Tang et al., 2022, Cheng et al., 2023, Narayanan et al., 2023, Yuhala et al., 2023, Chakraborty et al., 2023, Wang et al., 18 Feb 2024, Lutsch et al., 18 Mar 2024, Coppolino et al., 1 Aug 2024)