The Evolution of CXL.CacheMem IDE: Insights into CXL3.0 Security Feature

By ShuWang

July 9, 2025

In continuation of our series on IDE blogs, Why IDE Security Technology for PCIe and CXL?, Verification of Integrity and Data Encryption (IDE) for PCIe Devices, and Verification of Integrity and Data Encryption (IDE) for CXL Devices, this blog focuses on CXL3 IDE verification changes from CXL2.0.

Understanding CXL.CacheMem IDE in CXL3.0/CXL3.1/CXL3.2

The CXL 3.0 and CXL 3.1 specifications build on the security features of the CXL 2.0 IDE module, incorporating key elements from PCIe 6.0, particularly within the CXL.io channel. These specifications define mechanisms for data encryption and integrity protection in the CXL.CacheMem channel. This article will focus on the CXL.CacheMem IDE concept.

Figure 1: Functionality of IDE

Cipher Operation in IDE Flow for CXL3.x

In the CXL.CacheMem IDE context, the CXL 3.x specification maintains the encryption and integrity algorithms established in CXL 2.0. While the encryption and decryption engines remain consistent, the mapping of cipher inputs has evolved. Key distinctions exist between the 256B Standard mode and the 256B Latency-Optimized (LOpt) mode:

• The AES-GCM algorithm continues to be utilized, employing a 256-bit key for data encryption and integrity, along with a 96-bit MAC for data protection.
• For Additional Authenticated Data (AAD) mapping, credit or slot format information is combined with padded zeros to create a 4-byte AAD for integrity protection.
• Number of Flits in one MAC Epoch in 256B flit mode is changed to 2 for containment mode and 32 for skid mode, hence causing cipher inputs size change.
• Plaintext mapping differentiates FLITs carrying H8 (MAC/TMAC) slots and the status of the 256B LOpt Mode. The table below lists the mapping for any position that is not using the slot data.

Table: Mapping of Slot0/Slot8 to PlainText

Newly Introduced IDE.Stop in CXL3.x

A significant new feature in CXL 3 IDE is the IDE termination handshake. This introduces a new flit type, the IDE.Stop control flit, which facilitates a coordinated shutdown of the CXL.CacheMem IDE between the transmitter and receiver:

• Transmitter: Once the IDE.Stop flit is issued, all subsequent protocol flits will not be IDE protected.
• Receiver: The receiver must complete all pending actions for the current MAC Epoch before disabling IDE flow upon receiving the IDE.Stop flit.

Challenges Ahead and Solutions

While the IDE enhances security for data transfers, the complexity of security-related operations can obscure the relationship between inputs and outputs. To aid in this, the VIP (Verification Intellectual Property) provides detailed logging of IDE flow, flexible error injection methods for rigorous testing, and insights into Cipher Operations to ensure alignment between the Device Under Test (DUT) and VIP BFM (Bus Functional Model).

Key features of the VIP include:

• A standard prefix for all security-related prints in the CXL.CacheMem IDE module
• Packet payload prints prior to the IDE encryption flow
• Callback information for users to facilitate error injection during testing
• Cipher prints that reveal inputs and outputs
• Cipher configuration details for comparison

By leveraging these features, developers can ensure a robust implementation of CXL.CacheMem IDE, paving the way for secure and efficient data transfers.

The IDE further increased the complexity of the intricate PCIe and CXL protocols. Cadence CXL Verification IP and TripleCheck solution can help significantly reduce verification project cycles with comprehensive APIs, checkers for protocol violations, and a test suite.

Learn More

• For more information on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify IDE, see our VIP for PCI Express, VIP for Compute Express Link, and TripleCheck for PCI Express
• For more information on PCIe in general, and on the various PCI standards, see the PCI-SIG website
• For more information on CXL in general, see the CXL consortium website