TDISP and Confidential Computing: Extending the PCIe Chain of Trust

TDISP and Confidential Computing: Extending the PCIe Chain of Trust

Part 1 and part 2 of this series examined how PCI Express (PCIe) systems establish device trust and protect data in motion. Confidential computing introduces an additional requirement: A trusted workload must be able to verify, securely attach, and maintain control of a PCIe device interface throughout its use. This blog post examines how the TEE Device Interface Security Protocol (TDISP) enables trusted device assignment and works with Integrity and Data Encryption (IDE) in systems implementing the Arm Confidential Compute Architecture (CCA). The Arm Realm Management Extension (RME) provides the architectural extension for Realm-based confidential computing, while Realms are the protected execution environments that extend the chain of trust beyond processor execution and memory.

TDISP: Bringing Trust to PCIe Device Assignment

While IDE protects the communication channel, it does not establish whether a device itself should be trusted. This is the role of the TDISP.

PCI-SIG® defines TDISP as an architecture for trusted I/O virtualization that:

1. Establishes trust between a trusted execution environment (TEE) workload and a device.
2. Secures communication between the host and device.
3. Enables trusted device attachment and detachment.

TDISP builds directly on Data Object Exchange (DOE), Component Measurement and Authentication (CMA), Security Protocol and Data Model (SPDM), and IDE. It is not a replacement for these technologies, but it uses them to create a trusted lifecycle for PCIe device assignment.

Example: Confidential AI Training and a GPU

Consider a confidential AI training workload running within a TEE. The workload needs direct access to a GPU through SR-IOV.

Without TDISP:

• The GPU assignment may be modified by software outside the TCB.
• DMA mappings could be altered.
• Device state could change after assignment.
• The workload cannot reliably verify the device's security posture.

With TDISP:

1. The GPU is authenticated using SPDM and CMA.
2. Measurements are validated.
3. An encrypted IDE connection is established.
4. A trusted device interface (TDI) is assigned.
5. Configuration is locked.
6. The workload can now trust both the communication path and the assigned device interface.

TDISP Architecture

TDISP introduces several new architectural elements:

• TEE security manager (TSM) resides on the host side and manages trusted resources on behalf of confidential workloads.
• Device security manager (DSM) resides within the device and manages authentication, measurements, IDE configuration, and TDI security operations.
• Trusted device interface (TDI) is the portion of a PCIe device assigned to a trusted workload.

For a SR-IOV-capable NIC, a TDI might correspond to an individual virtual function. For other devices, it may represent an entire PCIe function.

TDISP introduces a lifecycle state machine for each TDI. These states describe the trustworthiness and operational status of the assigned interface rather than the security state of the overall device. A TDI transitions from CONFIG_UNLOCKED, where configuration changes are permitted, to CONFIG_LOCKED, where security-sensitive settings are frozen. Once attached to a confidential workload, the interface enters the RUN state. Any event that invalidates the trusted assumptions associated with the interface, such as an unauthorized configuration change, device reset, or loss of IDE protection, forces the interface into the ERROR state until trust can be re-established.

These states ensure that a confidential workload can verify the complete lifecycle of device ownership and operation.

How IDE and TDISP Extend the Arm RME Chain of Trust

Within Arm's CCA, the RME is the architectural extension for Realm-based confidential computing. Protected execution environments, or Realms, are designed to protect applications and data from software outside the workload's trusted computing base, including the hypervisor. This allows cloud providers to build a Trusted Computing Base (TCB) where customers can run their secure workloads reliably.

However, confidential workloads must communicate securely with I/O devices such as GPUs, SmartNICs, SSDs, and AI accelerators, in addition to protecting CPU execution and memory. IDE and TDISP are critical for this reason.

Consider an AI inference workload executing inside an Arm Realm while using a directly attached GPU accelerator:

The TSM authenticates the GPU using SPDM and CMA:

1. IDE establishes encrypted communication between the host and device.
2. TDISP securely assigns the GPU interface(s) to Trusted Virtual Machines (TVMs). The Arm System Memory Management Unit (SMMU) enforces memory access security by scrutinizing the requester ID (TDI), address, T-bit, and XT-bit (if present) from the device request to allow or deny access.
3. Transactions originating from the TVM or Trusted Device Interface (TDI) are identified and protected throughout the system.

Arm documentation specifically describes how PCIe IDE integrates with RME. IDE-protected TLPs contain information that allows the system to identify whether a transaction is associated with a TEE. Earlier implementations relied on the T-bit to distinguish trusted transactions from ordinary PCIe traffic. More recent PCIe specifications introduce eXtended TEE (XT) mode, which adds an XT-bit alongside the T-bit to provide finer-grained control over memory-access restrictions for TEE-originated requests. The combination of XT and T bits allows devices, translation agents, and memory-management hardware to determine whether a transaction originates from a TEE and whether access should be restricted to TEE memory, non-TEE memory, or both.

XT	T	Meaning
0	0	Non-TEE originator
0	1	TEE originator
1	0	TEE originator, access restricted to non-TEE memory
1	1	TEE originator, access restricted to TEE memory

An RME-aware SMMU can use the T-bit and, where implemented, the XT-bit when applying memory-access controls. These indicators allow the system to distinguish ordinary PCIe traffic from TEE-associated transactions and enforce the appropriate memory-access policy. IDE encrypts the TLPs, thereby providing protection from bad actors who have physical access to the system. Encrypted IDE TLPs can securely carry T-bit and XT-bit (if present), which are required for enforcing TDISP security requirements. In effect, IDE, along with the TDISP protocol, extend Realm trust semantics from TVM onto the PCIe fabric, and vice versa.

This creates an environment where secure transactions can be transmitted to their respective destinations securely and have the means to detect security violations:

Technology	Function
DOE	Security message transport
SPDM	Authentication and attestation
CMA	PCIe trust architecture
IDE	Protection of PCIe traffic
TDISP	Trusted device assignment
Arm RME	Protection of Realm execution and memory
SMMU	Enforcement of Realm-aware access controls

Together, these technologies allow confidential computing workloads to securely consume accelerators and peripherals and maintain a smaller TCB footprint. while maintaining the same trust guarantees that protect processor execution and memory.

Implementing PCIe Security with Cadence IP

As AI factories and composable infrastructure continue to scale, implementing PCIe security is becoming a foundational design consideration for next-generation accelerators, networking devices, storage controllers, and chiplet-based systems.

Security mechanisms such as SPDM, IDE, TDISP, and RME introduce significant design and verification complexity. Designers must manage authentication flows, key management, IDE streams and substreams, TDISP state transitions, encryption performance, trusted device assignment, error recovery, virtualization support, and software integration.

Cadence addresses these challenges through a comprehensive PCIe IP portfolio spanning design IP, subsystem IP, and verification solutions.

The Cadence Controller IP for PCIe supports the latest PCIe specifications and relevant engineering change notices (ECNs), including DOE and IDE support, while providing root-port, endpoint, and dual-mode configurations along with SR-IOV and PASID capabilities required by many confidential computing deployments.

Cadence also supports IDE, TDISP, and Arm RME capabilities within its PCIe and CXL controller, including trusted device interface management, stream management, trusted memory-range controls, and Realm-aware transaction handling.

These capabilities help designers accelerate the deployment of secure PCIe subsystems without compromising interoperability or performance.

Security Must Be Architectural

The most important takeaway is that PCIe security cannot be treated as a standalone encryption feature. Modern confidential computing platforms require an architectural chain of trust extending from the workload to the device and across the interconnect that connects them.

SPDM-CMA establishes trust, while IDE protects data in motion. TDISP governs trusted device assignment and secures the TDI, while Arm RME provides a protected execution environment and secure access to memory. Together, they transform PCIe from a traditional I/O fabric into a trusted extension of the confidential computing environment.

As AI infrastructure continues to move toward disaggregated, composable, and rack-scale architectures, these security technologies will increasingly become foundational requirements rather than optional features. Organizations that architect for security from the outset will be best positioned to deploy trusted AI infrastructure at scale.

For more information on Cadence’s PHY and controller IP solutions for PCIe, visit the PCIe and CXL landing page.

Learn More

Part 1: Security Foundations for PCIe: Establishing Trust Beyond the CPU

Part 2: Protecting PCIe Traffic: Understanding Link IDE and Selective IDE

White Paper: Building AI Factories with IP Solutions