以最小的性能影响保护通过互连传递的高价值数据。
当采用低延迟接口时，某些应用程序和硬件类型(新兴内存、人工智能/机器学习(AI/ML)和云服务器等)可以实现显著的性能优势。然而，像PCI Express (PCIe)这样的传统互连通常不能提供足够低的延迟来优化这些应用程序。作为回应，计算快速链路(CXL)标准被专门开发为PCIe的低延迟分支，并迅速在芯片架构和系统设计中站稳脚跟。
下表列出了各种互连标准的典型时延，以供参考:
CXL互连允许高价值数据在链路上移动;然而，与所有高价值数据一样，有必要保护这些数据不受不法分子的侵害。事实上，安全专家一致认为，系统中的每个芯片都是物理攻击的潜在目标。CXL作为一个关键互连，通常位于系统指定的安全边界内，是一个被利用的特定目标。对CXL互连进行保护势在必行。攻击者将采取多种方法来试图破坏系统安全性。一个例子是使用“嗅探”设备来攻击系统;例如，通过注入数据包头试图观察有效载荷数据。
为了满足保护系统的需求，CXL联盟将IDE(完整性和数据加密)作为CXL 2.0规范的可选部分。IDE旨在提供物理攻击的保护，并旨在增强在两个位置之间传输的数据包的安全性。IDE采用256位AES-GCM(高级加密标准，Galois/Counter模式)对称密钥加密分组密码，带有96位MAC传输用于完整性保护，旨在允许芯片设计师和安全架构师确保通过CXL链路的流量的机密性、完整性和重放保护。在CXL中。io路径(其中CXL IDE规范遵循PCIe IDE规范)，链路和选择性流受IDE保护，tlp也是如此。CXL中。cache和CXL。mem路径，link IDE只提供，没有选择的流。
保护CXL互连的重要性是众所周知的，许多CXL用户要求他们的供应商提供这一特性。作为回应，许多安全IP供应商针对这一市场推出了通用AES-GCM产品，同时领先的CXL控制器供应商(如Rambus)也设计了专门构建的ide，与CXL产品紧密集成。
简单地说，并不是所有的ide都是一样创建的。在考虑部署哪个IDE时，系统设计人员必须在部署安全性的需求与系统的总体需求之间取得平衡。
选择IDE时首先要考虑的通常是所需的安全级别。至少，安全工程师应该概述他们的产品面临的威胁模型，并实现足以抵御这种级别攻击的安全性。大多数系统设计人员认为基本CXL IDE规范为他们的需求提供了足够的安全级别，尽管根据应用程序的敏感性(例如，军事或金融用例)可能需要额外的安全性。
然而，系统设计人员还必须考虑系统的性能需求。对于CXL，我们已经解决了与其他互连技术相比，选择这种互连主要是因为其低延迟。在系统中引入IDE实际上会引入额外的延迟，这取决于所选择的特定IDE，这与实现低延迟链接的目的是相悖的。如果系统设计者要插入一个典型的3理查德·道金斯如果在CXL数据路径中使用了AES-GCM引擎，则可能会有额外的延迟。在1GHz时，标准AES-GCM解决方案可能会增加至少14ns的延迟，这意味着延迟将增加40%或更多。但是，CXL控制器内部IDE的紧密集成可以实现零延迟解决方案。Rambus通过我们的CXL 2.0控制器IDE引入了这样一个解决方案，为CXL提供了零延迟性能。cache和CXL。mem协议。
系统设计人员需要问一个问题——如果我选择的IDE给CXL链路增加了延迟，增加的延迟还能让系统满足其设计目标吗?如果是这样，有什么替代方案可以让我更好地解决CXL子系统的安全性和延迟需求?
额外的资源:
|
|
|
|
|
|
|
|
|
|
留下回复