📃
Confidential Computing 101
HomeTechnologyTry CC!
  • Welcome
  • Confidential Computing
    • What is Confidential Computing
    • What problems Confidential Computing solves
      • Bare Metal
      • Docker
      • Kubernetes
      • Knative
    • Why Confidential Computing
    • How Confidential Computing works
      • Memory Encryption
      • Workload Attestation
      • Confidential Boot
      • Sealing / Binding
      • Secret Provisioning
    • Technology Overview
    • Cloud Service Providers
  • Technology in depth
    • Intel SGX
      • Getting Started
        • Bare Metal Server Installation
        • Enclave Development Environment
        • Intel SGX SDK Setup
      • Technology
        • 🎭Features
        • 💂Threat Model
        • 🆚Versions
        • 🟦Concepts
          • 🏦Memory Encryption
          • 👮Local and Remote Attestation
          • 🖼️DCAP-Attestation Framework
          • 🔑Secret Key Provisioning
      • enclaive Development Kit
        • 🏢Architecture
        • 🌪️Workflow
        • 🌍Tutorials
          • Azure DCdsv3, DCsv2, or DCsv3 Setup
          • Redis in cK8s
          • MongoDB in cK8s
          • K8s + HashiCorp Vault on Azure DCsv3
      • Vault Remote Attestation Plug-In
        • 🏃‍♂️Initialization
        • 👮Attestation
        • ⚙️Configuration
    • Intel TDX
      • Getting Started
        • Azure
        • AWS
        • GCP
      • Technology
        • History
          • VT
          • TME/MKTME
          • SGX
        • Features
        • Threat Model
        • Concepts
          • Architecture
            • TDX Module
          • Memory Encryption
            • Confidentiality and Integrity
            • Keys and Key Management
          • TD Partitioning
          • DCAP-Attestation
            • Overview
            • Platform Registration
            • Attestation Report
    • AMD SEV
      • Getting Started
        • Azure
        • AWS
        • GCP
      • Technology
        • History
        • Threat Model
        • SME Concepts
          • Use Models
        • SEV-SNP Concepts
          • Features
            • Integrity Threats
            • Reverse Map Table
            • Page Validation
            • Page States
            • Virtual Machine Privilege Levels
            • Interrupt/Exception Protection
            • Trusted Platform Information
            • TCB Versioning
            • VM Launch & Attestation
            • VM Migration
            • Side Channels
          • Use Cases
          • Architecture
            • Encrypted Memory
            • Key Management
          • Software Implications
    • ARM CC
      • Technology
        • Introduction
        • Threat Model
        • Design
        • Comparison
    • Attestation Methods
      • Raw Attestation
      • Raw Attestation with Secure-Boot
      • Raw Attestation with a vTPM
        • AMD Secure VM Service Module and vTPMs
      • Raw Attestation with paravirtualized TPM
  • Resources
    • Youtube
    • Github
    • Products
Powered by GitBook
On this page
  • Prerequisites
  • Architecture
  • I/O Model

Was this helpful?

  1. Technology in depth
  2. Intel TDX
  3. Technology
  4. Concepts

Architecture

Last updated 11 months ago

Was this helpful?

Prerequisites

TDX comprises two main components:

TDX-enabled processors

These processors provide essential architectural functionalities, including hardware-assisted virtualization, memory encryption/integrity protection, and the capability to certify Trusted Execution Environment (TEE) platforms.

TDX Module

The TDX Module is an Intel-signed and CPU-attested software module that harnesses the capabilities of TDX-enabled processors to facilitate the creation, execution, and termination of TDs (Trusted Domains) while ensuring robust security guarantees.

Architecture

The TDX Module offers two interface functions: host-side interface functions for a TDX-enlightened hypervisor and guest-side interface functions for TDs. This module is loaded and executed within the Secure-Arbitration Mode (SEAM) RANGE, a reserved portion of system memory set up through UEFI/BIOS. The P-SEAM Loader, also residing in the SEAM RANGE, manages the installation and updates of the TDX Module.

SEAM is an extension of the VMX (Virtual Machine Extensions) architecture, introducing SEAM VMX root mode and SEAM VMX non-root mode. A TDX-enlightened hypervisor operates in the traditional VMX root mode. Still, it can transition into SEAM VMX root mode using the SEAMCALL instruction to invoke host-side interface functions (identified by function names starting with TDH) within the TDX Module. Once the task is completed, the logical processor returns to the hypervisor in VMX root mode through the SEAMRET instruction.

In contrast, TDs run in the SEAM VMX non-root mode. They can access the TDX Module through a TD exit or the TDCALL instruction. In both cases, the logical processor switches from SEAM VMX non-root mode to SEAM VMX root mode to execute code within the TDX Module. The guest-side interface functions responsible for handling TDCALLs have names starting with TDG.

I/O Model

The TDX threat model considers hypervisors and peripheral devices untrusted, prohibiting direct access to the private memory of TDs. Therefore, TDs and their owners must secure I/O data before it crosses the trust boundary. This involves sealing I/O data buffers and placing them in shared memory, identified by the shared bit in the Guest's Physical Address. Hypervisors and peripheral devices can move data to and from the shared memory. Consequently, the guest kernel requires modifications to support this I/O model. Additionally, all I/O data entering TDs from hypervisors or peripheral devices must undergo thorough examination and validation, as it can no longer be considered trustworthy.

In Linux guest support for TDX, all MMIO (Memory Mapped I/O) regions and DMA (Direct Memory Access) buffers are mapped as shared memory within TDs. The Linux guest enforces using SWIOTLB (Software I/O Translation Lookaside Buffer) to allocate and convert DMA buffers to unified locations. This protects against malicious inputs from I/O, and only a limited number of hardened drivers are permitted within TDs.

Intel TDX Architecture
Drawing