Latency Considerations Of IDE Deployment On CXL Interconnects

Certain applications and hardware types – emerging memory, artificial intelligence/machine learning (AI/ML), and cloud servers, to name a few – can realize significant performance advantages when a low latency interface is employed. However, traditional interconnects like PCI Express (PCIe) often do not offer low enough latencies required to optimize these applications. In response, the Compute Express Link (CXL) standard was developed specifically as a low-latency offshoot of PCIe and is quickly finding its footing in chip architecture and system designs.

For reference, the following table lists typical latencies of various interconnect standards:

The CXL interconnect allows high value data to move across the link; however, as with all high value data, there is a need to protect that data from nefarious parties. In fact, security experts agree that every chip in a system is a potential target for physical attack. CXL, as a key interconnect that is often within designated secure boundaries of a system, is a specific target for exploitation. It is imperative that CXL interconnects are protected. Adversaries will take a number of approaches to attempt to breach system security. An example is the use of a ‘sniffing’ device to attack systems; for instance, through the injection of packet headers in an attempt to observe payload data.

To address the need to protect systems, the CXL Consortium incorporated IDE (Integrity and Data Encryption) as an optional part of the CXL 2.0 specification. IDE is designed to provide protection against physical attacks, as well as aiming to enhance security in packets transmitted between two locations. IDE employs a 256-bit AES-GCM (Advanced Encryption Standard, Galois/Counter Mode) symmetric-key cryptographic block cipher, with a 96-bit MAC transmitted for integrity protection, designed to allow chip designers and security architects to ensure confidentiality, integrity, and replay protection for traffic that travels over CXL links. While in the CXL.io path (where the CXL IDE spec follows the PCIe IDE specification), link and selective streams are protected by IDE, as are TLPs. In the CXL.cache and CXL.mem paths, link IDE only is offered, with no selective streams.

The importance of securing CXL interconnects is well understood, with many CXL users mandating this feature from their suppliers. In response, many security IP vendors have purposed generic AES-GCM products aimed at this market, along with leading CXL controller vendors (like Rambus) designing purpose-built IDEs integrated tightly within their CXL products.

Simply put though, not all IDEs are created equally. When considering which IDE to deploy, system designers have to balance the needs of deploying security with the overall needs of the system.

The first consideration in choosing an IDE is most often the level of security required. At a bare minimum, security engineers should outline the threat model their products face and implement security sufficient to ward off this level of attacks. Most system designers have deemed that the base CXL IDE specification offers a sufficient level of security for their needs, though additional security might be required depending on the sensitivity of the application (say, military or financial use cases).

However, system designers must also consider the performance needs of their system. With CXL, we’ve addressed that this interconnect is largely chosen for its low latency vs. alternative interconnect technologies. The introduction of IDE into a system can actually introduce additional latency, depending on the specific IDE chosen, which would be at cross-purposes of achieving a low latency link.  If a system designer was to insert a typical 3^rd-party AES-GCM engine in the CXL data path, there is additional latency to be expected. At 1GHz, a standard AES-GCM solution might add a minimum of 14ns latency – that translates to increasing the latency by as much as 40% or more.  However, tight integration of the IDE inside the CXL controller allows for a zero-latency solution. Rambus has introduced just such a solution with our CXL 2.0 Controller with IDE that delivers zero-latency performance for the CXL.cache and CXL.mem protocols.

System designers need to ask – if my chosen IDE adds latency to the CXL link, would that added latency still allow the system to meet its design targets? And if so, what alternatives are there to allow me to better address the security and latency requirements of my CXL subsystem?

Additional resources:

• Rambus CXL 2.0 Controller with IDE
• Rambus CXL 2.0/PCIe 5.0 PHY