企业官网建设流程全解析

ide简介

为CXL链路上传输的数据提供机密性（Confidentiality，防止窃听）、完整性（Integrity，防止篡改）和重放保护（Replay protection，防止攻击者截获并重新发送旧数据包）

CXL.io IDE的定义，包括CXL.io IDE密钥建立，均基于PCIe IDE；CXL.cachemem IDE可以使用基于CXL.io的机制，通过标准流程进行发现、协商、设备证明和密钥协商

Assert：需要保护的对象。在此场景中，就是CXL链路上传输的原始数据及其附属信息（如地址、控制信号）。位于物理链路每一侧的代理（Agent）均处于其所在设备/硬件模块的信任边界之内。

可信计算基（TCB）：

• 链路两侧实现链路加密和完整性功能的功能模块。

• 用于配置链路两侧功能模块中加密引擎的代理。例如，可信固件/软件代理和/或实现密钥交换协议或协助密钥编程的安全代理硬件及固件。

• 设备中可能直接或间接访问资产的其他硬件模块，包括执行复位、调试和链路电源管理等操作的模块。

点对点保护。存在于主机与端点之间，或两个端点之间的路径上的任何交换机（Switches）都必须支持本规范。在这些情况下，此类交换机将被纳入TCB。

不负责DOS。防御攻击者通过发送海量垃圾数据包、破坏链路协议状态等方式，让CXL链路拥塞或设备瘫痪的情况。

CXL.io IDE

PCIe IDE保留的子流编码之一（1000b）已被分配用于CXL.cachemem用途。

CXL.cachemem IDE

当以68B模式运行时：

• CXL链路上的数据传输以flit为单位。协议规定，只有协议层可retry的才会被加密和完整性保护。

• 换句话说，链路层自身的一些管理控制信息（比如用于链路维护的握手信号）是不加密的——它们本身不携带用户数据，加密它们没有意义，反而会增加延迟。

当以256B模式运行时：

• 链路层控制信息、片头部以及CRC/FEC不被加密，也不进行完整性保护。这些内容没有机密性保护、完整性保护或retry保护。

• 链路CRC应在加密后的flit上计算。链路重传首先发生，只有通过链路CRC检查的才会被解密，然后再进行完整性检查。

必须支持多数据头（Multi-Data Header）能力。这允许将多个（最多4个）数据头打包到一个槽位中，随后紧跟16个全数据槽位。

AES-GCM

IDE使用高级加密标准-伽罗瓦/计数器模式高级加密与解密功能（本文简称AES-GCM），如NIST特别出版物800-38D中所定义。必须使用256位密钥长度的AES-GCM来实现机密性保护、完整性保护和重放保护。AES-GCM功能接受三个输入：

• 明文（P）：要加密的原始数据。

• 附加认证数据（AAD）：这部分数据不加密，但会参与完整性校验计算（比如数据包的头部信息，它不需要保密，但不能被篡改）。

• 初始化向量（IV）：一个随机数，确保即使同样的明文用同样的密钥加密，每次生成的密文也不同，防止攻击者通过观察模式来破解。

密钥刷新

• 场景一：设备迁移：在多租户云环境中，一个硬件加速器（如AI芯片）可能先被分配给VM1（虚拟机1），后来被释放并重新分配给VM2。为了防止VM1通过残留数据或密钥访问到VM2的数据，必须在重新分配前更换加密密钥。

• 场景二：密钥磨损（Key Wear-out）：任何对称加密算法在加密大量数据后，理论上都存在“密钥使用过度”的风险（虽然AES-256在现实中几乎不可能被穷举，但安全策略上会有合规要求）。定期更换密钥是一种安全最佳实践，可以降低长期使用同一密钥带来的潜在风险。

频率：密钥刷新不频繁发生（可能几分钟、几小时甚至几天一次），所以性能开销不是首要考虑。

代价：允许在刷新过程中短暂牺牲延迟或带宽（例如暂停新事务，集中处理密钥交换）。

要求：绝对不能丢数据。

PCRC（加密循环冗余校验）机制

普通的CRC只能检测物理传输过程中的随机位错误（例如信号干扰导致的比特翻转）。但无法检测出加密引擎内部硬件逻辑错误导致的“加密结果出错”或“解密错误”。

PCRC的作用：

• 它集成到标准的MAC（消息认证码）检查流程中，专门用来检测加密/解密硬件自身内部产生的故障：

  • 硬故障（Hard Faults）：硬件电路永久性损坏，导致加密结果永远错误。

  • 软故障（Soft Faults）：瞬时故障，例如宇宙射线导致寄存器位翻转，临时产生错误结果。

PCRC的优势：

• 不消耗额外链路带宽：它巧妙地复用了现有的数据包字段，不会增加传输数据量。

• 低延迟：硬件实现时可以做到几乎不增加额外时延。

68B Flit模式下的CXL.cachemem IDE架构

AES-GCM算法需要三个输入：A（附加认证数据，不加密但防篡改）、P（明文，加密）、IV（初始化向量）。规范指定了如何把flit中的数据填充到A和P里：

通俗理解：既有“控制信息”（好比快递单上的地址），也有“数据内容”（好比包裹里的货物）。地址需要明文以便交换机/路由器查看和转发，但不能被篡改（所以放A里做完整性保护）；货物则必须完全加密（所以放P里）。

链路CRC的计算时机

• 链路CRC既不被加密，也不受完整性保护。CRC是在flit内容被加密之后，基于加密后的flit内容计算的。

MAC周期（MAC Epoch）：多个聚合加密

AES-GCM的一个特点是，如果为每个flit单独做加密，会产生大量的认证标签（MAC）开销，占用带宽。为了提高效率：

• 多个（例如5个）被聚合在一起，作为一个整体进行一次AES-GCM加密/认证操作，这个聚合体称为一个“MAC周期”（MAC epoch）。

• 聚合flit的具体数量由“聚合微片计数”（Aggregation Flit Count）寄存器配置。

• 这样做的好处是：多个flit共享一个MAC标签（完整性校验值），节省了链路带宽。

PCRC如何参与加密

• 如果启用了PCRC（加密循环冗余校验，用于检测加密引擎内部硬件故障），PCRC的32位值会被追加到聚合flit内容的末尾，并一起被纳入P中进行完整性保护。

• 但PCRC值本身不在链路上传输——它只是接收端在解密后内部计算比对用的，不占用实际带宽。这体现了前面提到的“不消耗增量链路带宽”的设计。

错误处理流程

规范强调了一个重要顺序：

发送端：加密 → 算CRC → 发送
接收端：检查CRC → 解密 → 检查完整性

MAC（Message Authentication Code消息认证码）

MAC不是独立的数据包，而是嵌入在Slot 0头部中，且该头部的类型必须为H6（这是CXL协议中预定义的一种特殊头部格式）。规范规定MAC必须为96位（12字节）。发送端用密钥对数据（P）和附加认证数据（A）计算出这个MAC值，附在密文后面一起发送。接收端收到后用同样的密钥重新计算MAC，如果与收到的MAC一致，则证明数据未被篡改、来源可信。MAC本身不加密、不完整性保护

在一个MAC周期中，多个微片中所有需要加密的数据部分（P）会被按传输顺序首尾拼接成一个连续的字节流，然后统一进行AES-GCM加密和MAC计算；而只做完整性保护（不加密）的头部字段（A）则单独处理，用于参与MAC计算但不进入密文流。

• 发送端：按 Flit0 → Flit1 → Flit2 → Flit3 → Flit4 的顺序拼接P → AES-GCM加密 → 生成密文和MAC

• 接收端：收到同样顺序的微片 → 按同样顺序拼接P → AES-GCM解密 → 验证MAC

来自多个 Flit（流控制单元）的头部信息（每个 Flit 头部包含 16 字节）按顺序拼接起来，形成一个 64 字节的 AAD 缓冲区。由于最后一个 Flit 头部（Flit3）较短，剩余的 AAD 空间被强制填充为 0

CXL.cachemem IDE 在 256B Flit 模式下的架构

头部槽位的双重角色：控制 vs 协议

在256B模式下，“头部槽位”（header slot）有两种用法：

填充（Padding）机制：对齐AES块大小

AES是一种分组密码，它要求输入数据（明文P）的长度必须是128位（16字节）的整数倍。但实际数据长度往往不正好是16字节的倍数，因此需要填充。

• 在头部槽位携带协议信息时，明文（P）从第20位（bit 20）开始。

• 为了凑够128位，在头部槽位内容前面填充20个0，使总长度达到128位（20位填充 + 108位实际内容 = 128位）。

• 加密后的填充数据不会在链路上发送——接收端知道规则，会在本地重建这些填充的密文，以便正确解密。

CRD（信用返回）字段

• CRD（Credit Return）是链路层流量控制用的字段，用于告知对端“我有多少缓冲区可用”。

• 它不包含机密数据，所以不需要加密。

• 但它需要完整性保护——因为如果CRD被篡改，可能导致链路死锁或数据丢失。所以CRD映射到A（附加认证数据），参与MAC计算但不加密。

延迟优化的特殊处理规则

延迟优化（latency-optimized flits）是256B模式中为了降低延迟而设计的特殊格式。其处理规则：

同样地，填充数据不传输，接收端需本地重建密文用于MAC计算。

A的对齐：填充到32位

• 每个微片的AES-GCM输入A（附加认证数据）也需要填充0以对齐到32位（4字节）边界。这是为了硬件实现方便，32位是常见的寄存器/总线位宽。

头部槽位的格式速记

• 协议头：slot_type|CRD|012

  • slot_type（4 bits）：槽位类型，映射到A

  • CRD：信用返回字段，映射到A

  • 012：表示其他位（从bit 20开始），映射到P

• MAC头：CRD|016

  • 当头部槽位携带MAC（认证标签）时，slot_type不再存在，因为整个槽位用于传输96位MAC加上一些CRD等控制信息

  • 016表示16位其他内容

LLCTRL (H8) 格式和正常的协议头的安全保护策略

CRC的安全保护策略

LLCTRL (H8) 格式和正常的协议头的flit标准型和延迟优化的安全保护策略

加密PCRC

PCRC 的计算参数

发送端流程

1. 计算PCRC：对当前MAC周期中所有flit计算PCRC，得到32位的PCRC值。

2. 追加到明文末尾：将PCRC值附加到聚合明文的末端，形成一个“明文 + PCRC”的扩展数据块。

3. 加密并纳入MAC：整个“明文 + PCRC”一起被AES-GCM加密，生成的密文和MAC覆盖了包括PCRC在内的所有内容，被送入GHASH(H)（GMAC 计算），加密后的 PCRC（在密文 C 的最末尾）不被发送到物理链路上。

接收端流程

1. 解密数据：接收端使用AES-GCM的密钥流（keystream）对收到的密文进行解密，还原出明文内容（即发送端的“明文 + PCRC”）。

2. 重新计算PCRC：基于解密后的明文部分（不包括PCRC区域），按照与发送端相同的算法重新计算PCRC值。

3. 加密PCRC（关键步骤）：将重新计算出的PCRC值与AES密钥流中紧跟在数据解密之后的那一段进行XOR（异或）操作。这相当于用AES密钥流对PCRC进行了“加密”，得到加密后的PCRC。

4. 追加并验证MAC：将加密后的PCRC追加到接收到的密文末尾，然后计算MAC。如果发送端和接收端的PCRC计算结果一致，且传输过程中数据未被篡改，MAC校验就会通过。

加密密钥和初始化向量（IV）

IDE流初始化的四个步骤

规范将初始化过程划分为清晰的四个阶段：

CXL.cachemem IDE可以利用CXL.io IDE机制，通过标准流程进行设备证明和密钥交换

CXL.cachemem IDE的IV构造

AES-GCM要求每次加密使用一个唯一的IV（初始化向量），以确保相同的明文用相同的密钥加密后产生不同的密文，防止攻击者通过模式分析破解。

• IV长度：96位（12字节），符合NIST 800-38D标准。

• 构造方式：确定性构造（Deterministic construction），意味着IV不是随机生成的，而是通过固定规则计算得出，保证唯一性和可预测性。

• 发送和接收密钥必须不同，虽然发送和接收使用相同的子流标识（1000b），但用于加密（发送）和解密（接收）的AES密钥必须不同

96位的IV被划分为两个部分：

IV =[固定头: 1000b + 28个0] + [64位计数器]。

计数器回滚（Rollover）的处理

• 64位计数器从1开始递增，最大到 264−1264−1，然后回滚到0再继续。

• 规范明确：发送端和接收端都不需要检测回滚，也不需要采取任何特殊动作。

• 为什么可以这样？因为 264264 是一个天文数字（约 1.8×10191.8×1019）。即使链路以最高速率持续运行，也需要极其漫长的时间才会发生回滚

非默认IV构造（可选能力）

• 如果端口在CXL_QUERY_RESP中报告CXL.cachemem IV Generation Capable = 1，表示该端口支持将IV初始设置为非默认值。

• 这允许上层软件（如通过CXL_KEY_PROG消息）指定一个自定义的初始IV值，而不是从1开始。这在某些多租户场景下可能有用（例如确保不同租户的IV空间不重叠）。

• 但无论如何定制，每次消耗IV后计数器必须递增的规则不变。

CXL.cachemem IDE 模式

封装模式（Containment mode）

• 在封装模式下，数据只有在完整性检查通过后才会被释放用于进一步处理。这种模式会影响延迟和带宽。

• 延迟影响：由于需要缓存多个“flit”（数据单元）直到完整性值被接收并检查，因此会引入延迟。

• 带宽影响：完整性值需要频繁发送，从而占用带宽。

• 如果启用了封装模式，所有设备（包括主机）在 68B Flit 模式下应使用聚合 Flit 计数（Aggregation Flit Count）为 5，在 256B Flit 模式下为 2。

滑移模式（Skid mode）

• 滑移模式允许数据在不等待完整性值接收和检查的情况下被释放用于进一步处理。这可以减少完整性值的传输频率。

• 优点：延迟接近于零，带宽开销也较低。

• 风险：如果攻击者篡改了数据，这些数据可能会被软件消费；但当完整性值最终被接收和检查时，这种攻击会被检测到。

• 如果启用了滑移模式，所有设备（包括主机）在 68B Flit 模式下应使用聚合 Flit 计数为 128，在 256B Flit 模式下为 32。

运行模式与设置

• 在 CXL（Compute Express Link）协议中，设备通过“能力结构”（Capability Structure）向系统报告其支持的功能。这里的“完整性模式”指的是数据传输中用于保证数据完整性的机制（如 MAC，消息认证码）。端口必须通过寄存器告知系统它支持哪些模式。所有合规设备都必须支持“包含模式”。

• 在启用 CXL 的缓存内存（cachemem）IDE 功能前，必须先配置好运行模式（如传输速率、协议类型等）和定时参数（如延迟、时钟同步等）。这些配置信息存储在 CXL IDE 能力结构中，供系统读取和协商。

MAC 聚合规则

• MAC（Message Authentication Code） 是用于验证数据完整性和来源的机制，常用于防止数据在传输中被篡改。

• Flit 是 CXL 协议中最小的数据传输单元，类似“数据片”。

• MAC epoch 是一个“计算周期”，即一组连续的 flit，用于计算一个 MAC 值。这个周期长度由协议定义（N 个 flit）。

• 发送端必须在传输前，对一个 MAC 时期内的所有 flit 计算完整性值（MAC），并将其附在数据流中。

• 传输顺序必须与 MAC 时期的顺序一致，保证数据完整性校验的正确性。

图 11-17 展示了一个典型场景：在连续数据流中，MAC 的计算和传输如何与数据流同步，确保在数据发送前完成校验。

图 (a)：最早传输 MAC (Earliest MAC Header Transmit），一旦计算完成，立刻插入。

图 (b) ：最晚传输 MAC (Latest MAC Header Transmit)，遇到特定的空档（Multi-Data Header）才插入，尽可能晚地发送。

• Containment mode（遏制模式 - 严格安全）：

  • 规则：在当前 MAC 周期的 MAC 校验值被验证通过之前，接收端绝对不允许将属于该周期的数据（Flit）交给上层。

  • 原因：为了防止错误数据或攻击数据泄露到系统中。

  • 例子（结合图 11-17(b)）：如果 MAC 直到周期结束后的第 5 个 Flit 才插进来，那么接收端必须一直缓存（Buffer）前面所有的黄色 Flit 和绿色 Flit，直到 MAC 到来并校验通过。对于 68B Flit，接收端最多需要缓存 5 个 Flit 的深度来防止数据丢失。

  • 细节：即使 MAC 到达，如果校验失败，所有缓存的数据都会被丢弃。

• Skid mode（滑动模式 - 性能优先）：

  • 规则：接收端可以边接收边解密并释放数据供消费，无需等待 MAC 校验。

  • 原因：降低延迟，允许数据以流水线方式流动。

  • 具体操作：Flit 0 到达时：接收端不管 MAC 还没到，直接解开这个 Flit 的数据，释放给上层使用。Flit 1 到达时：同上，继续释放并累计计算 MAC。Flit 2、3、4 到达时：一直释放，一直计算。Flit 5（带黄方块）到达时：发送端终于把 MAC 送来了。接收端拿着自己这 5 个 Flit 算出来的结果，跟送来的 MAC 对一下，对不上（或 MAC 没来）：系统立刻发出警报

• 68B和256B错误检测机制

1. MAC头必须在规定时间内被接收，否则视为错误。

2. 允许一定数量的“提前”Flit传输

3. 在前一个MAC周期的MAC头还未发送时，可以先发送少量属于当前MAC周期的Flit，但数量有限（68B模式最多5个，256B模式最多1个）

4. 68B模式：如果在前一个MAC周期结束后的6个Flit内未收到MAC头 → 错误。

5. 256B模式：如果在前一个MAC周期结束后的2个Flit内未收到MAC头 → 错误。

提前终止 MAC 周期

MAC 聚合（MAC Aggregation）通常要求凑齐 N 个 Flit 才算一个周期。但如果链路即将空闲（Idle），或者没有足够的数据填满一个完整的周期，发送端就可以“提前收工”，发送一个“截断的 MAC Flit”（Truncated MAC Flit）来关闭当前的 MAC 周期。

当前 MAC 周期的协议 Flit 数量少于聚合 Flit 计数（N）

提前终止 MAC 周期和传输 MAC 必须遵循以下规则：

1. 前提条件：发送端只有在当前 MAC 周期的协议 Flit 数量少于聚合 Flit 计数（N）时，才被允许提前终止该周期。此截断周期内的 MAC 必须由发送端通过IDE.TMAC链路层控制帧（一种特殊的控制子类型，称为Truncated MAC Flit）自身来传输。

2. 周期隔离：随后（截断之后）的任何协议 Flit 将属于一个新的 MAC 周期，并且必须在截断的 MAC Flit 传输之后进行传输。

3. 计算规则：除了计算累计的 Flit 数量较少之外，截断周期的 MAC 计算方法与正常周期完全相同。

• 黄色部分：MAC_EPOCH 1，只传输了 M 个 Flit（M < N）。

• 灰色部分 (Idle)：链路没有更多数据要发了，准备空闲。

• 橙色+黄色部分 (Truncated MAC Flit)：发送端不再等待凑齐 N 个 Flit，而是针对前面那 M 个 Flit 计算出 MAC，并专门生成一个“截断的 MAC Flit”发送出去。

截断周期内，数据在 AES-GCM 加解密引擎中的具体输入输出。尽管周期提前结束了，但加密引擎的运作流程没有改变。

• 上方框：代表实际在链路上传输的 Flit 序列（包含 Flit Header 和截断的 MAC Flit）。

• 下方框（AAD 和 P-Plain text）：展示了发送端如何在内部处理这些数据：

  • 图中的箭头表明，除了 MAC 块（橙色）之外，所有的 Flit Header 都会作为AAD（附加认证数据）参与完整性计算。

  • 所有的 Flit 数据内容（Payload）都会作为P-Plain text（明文）被加密成密文（P 域），并送入 PCRC 生成器。

当前 MAC 周期的协议 Flit 数量 等于聚合 Flit 计数（N）

• 黄色部分：MAC_EPOCH 1 刚好发送了完整的 N 个 Flit。

• 绿色部分：接收端开启了下一个周期（MAC_EPOCH 2）。因为 EPOCH 1 是完整的，所以 EPOCH 1 的 MAC 被放在了EPOCH 2 的第一个 Flit（Flit 0）中（黄色 MAC 块）。

• 再次截断：由于链路即将空闲，EPOCH 2 刚发了 1 个 Flit 就要结束了。所以，发送端再次使用“截断机制”，发送了一个橙色 MAC 块的Truncated MAC Flit，用于结算并终止 EPOCH 2。

剩余 Flit 数计算

• Remaining Flits = Aggregation Flit Count - Number of protocol flits transmitted in current MAC epoch

• 解释：剩余 Flit 数 = 标准周期总量 N - 当前周期已经发送的 Flit 数。这表示如果按照正常流程，链路还需要等待多少个 Flit 才能凑满一个周期。

截断延迟计算

• TruncationDelay = Min(Remaining Flits, Tx Truncation Transmit Delay)

• 解释：截断延迟取“剩余 Flit 数”和“发送端配置的截断传输延迟”中的较小值。

• 为什么需要这个延迟？注释提到：“Tx Truncation Transmit Delay 是一个配置参数，用于应对可能发生的AES 密钥流（Keystream）丢弃。” 因为加密引擎（AES-CTR）通常是按流式（Streaming）处理的，它可能已经为“原本应该在后面传输的 Flit”预生成了密钥流。既然决定提前截断，就必须留出时间让硬件把这些预生成但不再使用的密钥流彻底清除，以保证后续新周期的加密不会错位。

密钥切换的完整握手流程

密钥的“待处理”与“激活”状态

• 软件通过寄存器接口将新密钥写入端口，但这些密钥不会立即生效，而是处于“待处理”（pending）状态。

• 在待处理期间，链路继续使用旧密钥传输数据。这样可以做到无中断密钥刷新——旧密钥服务旧数据，新密钥等待切换命令。

切换触发：CXL_K_SET_GO 请求

• 当链路两侧都已完成新密钥的编程后，软件发送CXL_K_SET_GO请求。

• 这个请求同时通知两侧的发送端：开始密钥切换流程。

切换流程的三步

为什么需要IDE.Idle

• 接收端切换密钥需要时间：硬件解密引擎在切换密钥时可能需要重置流水线、加载新密钥、清除旧状态等操作。

• 发送端必须等待：Tx Key Refresh Time必须配置为≥ 接收端宣告的最坏情况延迟（通过Rx Min Key Refresh Time字段获取）。

• 这些IDE.Idle明文传输，不加密——因为它们不包含用户数据，只是“时间填充物”。

接收端的响应

• 收到IDE.Start后，接收端必须切换到新密钥（前提是发送端满足了AES-GCM的要求）。

• 建议发送端在IDE.Start之前先发一个IDE.TMAC（测试MAC），用于让接收端验证新密钥是否正确。

关键约束：不得在MAC周期中间发送IDE.Start

• AES-GCM的核心要求：在一个MAC周期内，所有flit必须使用同一个密钥进行加密和MAC计算。

• 如果发送端在MAC周期中间插入IDE.Start，就相当于一部分用旧密钥、一部分用新密钥，违反AES-GCM规范。

• 违反的后果：接收端丢弃IDE.Start，记录错误状态，可能转入“不安全状态”。

IDE.Start与协议flit的顺序关系

• IDE.Start 必须在 MAC 边界处发送：要么在MAC周期结束后、新MAC周期开始前发送；要么在MAC周期结束后、但MAC头部传输之前发送。

• 如果涉及链路重传：接收端必须先完成旧协议flit的重传，再处理IDE.Start和切换密钥。确保旧数据全部妥善处理后，再换新钥匙开门。

其他事件（如链路重训练）的容错

• 链路重训练（link retraining）等事件可以发生在密钥切换流程中间，只要顺序约束得到满足。这体现了流程的健壮性，不会因为链路层运维事件而中断密钥刷新。

错误处理

与链路层错误处理的关系

• 链路CRC错误和链路重传流程不受CXL IDE影响。

• 原因：这两者是链路层的职责，在数据到达解密引擎之前就已经处理完毕（如前面提到的“先CRC检查，后解密”顺序）。CXL IDE只关心“解密后”的安全错误，不干预链路层的物理错误恢复。

错误分类与记录

CXL.cachemem IDE的错误主要分为三类，记录在CXL IDE Error Status寄存器中：

当这些错误发生时：

• Uncorrectable Error Status寄存器中的对应位也会被置位（这是一个PCIe/CXL通用的不可纠正错误状态寄存器）。

• 同时，错误会通过标准的CXL.cachemem协议错误信令机制上报给软件或系统管理程序（如通过中断或错误消息）。

状态转换：Active → Insecure（“零容忍”策略）

• 默认规则：如果当前IDE流处于Active（激活）状态，一旦记录到上述错误，就会立即转换到Insecure（不安全）状态。

为什么要转换到 Insecure 状态？

• 因为一旦MAC校验失败或检测到解密异常，说明密钥可能已经被破坏、数据可能已被篡改，或者加密引擎已经不可信。继续使用当前密钥传输数据是极度危险的。

Insecure 状态下的行为

当进入 Insecure 状态时，硬件必须执行以下操作：

流程示意

正常状态 (Active) │ ▼ 检测到 IDE 错误（MAC失败/解密异常等） │ ▼ 记录错误 → 置位错误状态寄存器 → 上报错误信号 │ ▼ 转换到 Insecure 状态 │ ├─ 丢弃所有缓冲和后续流量 ├─ 防止密钥/数据泄露 └─ 等待链路复位后才能恢复

Switch

CXL交换机（Switch）在CXL IDE架构中扮演着关键角色，因为它位于主机和设备之间，需要处理加密流量。

三种模型对比总结

IDE终止握手

IDE终止的触发条件

• 触发源：软件发送CXL_K_SET_STOP请求。

• 前提条件：

  • 端口必须支持IDE.Stop功能（这是256B Flit模式的可选能力）。

  • 该功能必须通过编程CXL IDE Control寄存器来启用。

• 响应动作：发送端发送一个IDE.Stop控制flit。

终止流程

接收端的处理要求

• 收到IDE.Stop后，接收端必须：

  1. 完成当前MAC周期的所有待处理操作（如解密、MAC验证）。

  2. 然后才禁用IDE引擎，切换到非加密模式。

• 这样确保在关闭加密前，所有已接收的加密数据都已被正确处理。

IDE.Idle的作用

• 发送端发送IDE.Stop后，接收端需要时间清理内部状态（如清除预计算的密钥流、重置计数器等）。

• 发送端发送指定数量的IDE.Idle（数量由Tx Key Refresh Time控制），给接收端留出准备时间。

• IDE.Idle本身不加密，因为此时IDE已进入终止过程。

非法IDE.Stop的处理

规范列举了三种非法/意外IDE.Stop的场景，全部会被丢弃并记录错误：

流程状态图

加密活跃状态 (Active) │ ▼ 软件发 CXL_K_SET_STOP │ ▼ 发送端发 IDE.TMAC → 终止当前MAC周期 │ ▼ 发送端发 IDE.Stop（中间无协议微片） │ ▼ 发送端发 IDE.Idle（N个，等待接收端就绪） │ ▼ 双方切换为非加密模式 │ ▼ 发送无加密保护的协议微片