【CXL协议-安全（11）】

拓展：
什么是 AES-GCM 加密？
AES-GCM是一种高级加密标准（AES）的加密模式，同时使用加密和身份验证（AEAD）功能。它使用加密算法AES和Galois Counter Mode（GCM）计数器模式，以实现高效的加密和身份验证，同时提供保密性、完整性和认证性。AES-GCM的加密和身份验证是同时进行的。它采用一种称为“GHASH”的Galois域上的乘法操作来计算消息的身份验证标记（MAC），并使用一个称为“CTR”的计数器模式来加密消息。下面是AES-GCM的详细流程：
分离密钥和初始向量：AES-GCM使用128位的AES加密算法，因此密钥长度为128位、192位或256位。另外，它需要一个唯一的初始向量（IV）来确保每次加密都是不同的。IV的长度可以是96位或更大，基本上96位足够了。
初始化计数器：计数器是一个值，用于在加密和身份验证期间迭代生成密钥流，以加密和解密消息。在AES-GCM中，计数器使用CTR模式初始化。CTR模式是一种流式加密模式，它将计数器的值作为输入，并使用AES算法来生成密钥流。在AES-GCM中，计数器被初始化为IV的值。
生成密钥流：使用AES算法生成密钥流。对于每个64位的密钥流块，计数器值将递增，以产生不同的密钥流块。
加密明文：使用异或操作将明文和生成的密钥流块混合在一起，以生成密文。加密的过程是逐个字节进行的。
计算身份验证标记（MAC）：使用一个称为GHASH的算法来计算MAC。GHASH是一种基于Galois域的算法，用于计算消息的身份验证标记。它将消息划分为64位块，并使用乘法和异或操作将它们混合在一起，最终生成一个128位的MAC。
生成完整的密文：将密文和MAC组合在一起，以生成完整的密文。
解密：使用相同的密钥、IV和MAC密钥流，使用异或操作对密文进行解密。
验证MAC：使用相同的密钥、IV和明文，重新计算MAC，并将计算出的MAC与原始MAC进行比较。如果MAC匹配，则说明密文未被篡改。
11.1 CXL IDE
CXL完整性和数据加密（Integrity and Data Encryption，IDE）定义了为传输CXL链路的数据提供机密性、完整性和重播保护的机制。加密方案与当前行业最佳实践保持一致。它支持各种使用模型，同时提供广泛的互操作性。CXL IDE可用于在由多个组件组成的可信执行环境（TEE）中保护流量，然而，这种组合的框架不在本规范的范围内。
11.1.1 范围
本章重点介绍通过链路传输的CXL.cache和CXL.mem流量传输，以及对控制CXL.io流量的PCIe基本规范的更新/限制。
● CXL.io IDE的定义基于PCIe的IDE规范
● CXL.cachemem IDE可以使用基于CXL.io的机制进行发现（discovery）、协商（negotiation）、设备证明（device attestation）和密钥协商（key negotiation）。
本规范中，CXL IDE指代保护CXL.io，CXL.cache，CXL.mem数据流的机制，CXL.cachemem IDE指代保护CXL.cache，CXL.mem数据流的机制。如果没有明确指出，则遵循PCIe规范。CXL.io基本上与PCIe IDE的要求一致。拒绝服务攻击（denial of services）不在范围内。
11.1.2 CXL.io IDE
CXL.io IDE遵循PCIe IDE定义。

①IDE流（IDE stream）指的是，使用完整性和数据加密定义的机制建立的端口到端口连接，以保护两个端口之间的TLP流量（traffic）
②
● Link IDE stream：PCIe IDE 定义中的流式传输模式，用于在 PCIe 链路上传输 IDE 命令/数据。
● Selective IDE stream：用于在 CXL.io 中传输具有选择性的数据流。
● Aggregation：PCIe 定义的聚合级别，用于将多个 PCIe 事务捆绑成一个更大的事务。
● Switches with flow-through selective IDE streams：支持流式传输的 CXL.io Switch，可以将 CXL.io 数据流向终端设备。

1. CXL switch必须要支持 Link IDE stream。
2. CXL switch可以作为 CXL.io 数据的终端或者将其转发到终端设备。
3. 支持 Selective IDE stream 的 CXL switch可以作为选择性 IDE 流的终端或将其转发到终端设备。 ● PCRC mechanism：可以选择性地为 CXL.IO 端口启用 PCRC (Packet CRC) 机制。 11.1.3 CXL.cache/CXL.mem IDE高层概览 ● 所有协议级别的重试flit都经过加密并受到完整性保护。 ● 链路层控制flit和flit CRC没有加密，也没有完整性保护。(将链路层的控制 flit 和 flit CRC 加密和完整性保护可能会引入额外的延迟和复杂性，对于链路层的正常操作并不是必需的。而且链路层通常有其他机制来确保数据的可靠传输，如重试机制(见4.2.8)。因此，在设计上，这些控制信息通常被视为需要快速、高效传输的数据，不需要加密和完整性保护。) ● LCRC应该在加密flit上计算。(为什么LCRC应该在加密flit上计算：LCRC只在加密分片上进行计算的原因是为了确保在链路层重试（Link retries）之前，只有通过了链路CRC验证的分片才会被解密和进行完整性检查。当使用加密算法对flit进行加密时，flit的内容会发生改变。如果在加密之前计算LCRC，那么在链路层接收到flit时，LCRC值会与接收到的加密flit不匹配，从而导致链路层验证失败。) ● 任何完整性检查失败的数据流都应被放弃。（确保没有脏数据） ● 必须支持多数据头功能。这允许将多个（最多4个）数据头打包到一个slot中，然后紧接着是所有数据的16个slot。 ● 采用256-bit密钥的AES-GCM加解密 ● 必须支持在不丢失任何数据的情况下进行密钥刷新 ● 密钥刷新预计不经常发生。延迟/带宽受到影响是可以接受的，但不能有任何数据丢失。 ● 支持加密PCRC机制。加密PCRC集成到标准MAC检查机制中，不消耗额外链路带宽，不增加显著额外延迟。PCRC对于CXL.cachemem IDE是强制性的，并且在默认情况下是启用的。（由于 PCRC 计算是在加密过程中进行的，并且是并行地进行的，所以它不会引入额外的链路传输开销。） 11.1.4 CXL.cache/CXL.mem IDE架构 ● IDE应当以flit为单位，使用AES-GCM模式。AES-GCM采用三个输入，分别为附加身份验证数据（Additional Authentication data，AAD，在AES-GCM规范中指定为A）、明文（P）和初始化矢量（IV）。在CXL.cachemem协议中，32-bit的数据包头作为slot 0的一部分，映射到A——它没有加密，但受到完整性保护。Slot 0/1/2/3的映射到P，P经过加密并受到完整性保护。CXL.cachemem协议也支持仅有数据（data-only）的flit，在这种情况下，flit中的所有4个slot映射到P。 ● LCRC不加密且不受到完整性保护。在flit被加密之后，对其计算CRC ● IDE flit也遵守用于检测和纠正错误的链路层机制。 ● AES-GCM可以应用于多flit聚合，这些flit组成一个MAC_Epoch。可以聚合的flit数目取决于Aggregation Flit Count。如果启用PCRC，则32-bit的PCRC值应这些聚合的flit的末尾，以产生受完整性保护的最终P值。然而，PCRC的32-bit并不在链路上传输的。下图显示了在5个flit聚合MAC的情况下，flit内容到A和P的映射。图中深灰色部分是flit header，映射到A；浅灰色部分是数据，映射到P。 MAC_Epoch：是指将多个flit（或者说数据包）聚合在一起并应用AES-GCM加密算法处理的过程

● MAC是96-bit，MAC必须在H6类型的slot 0报头中传输。MAC本身既没有加密，也没有完整性保护。下图显示了在5个flit聚合MAC的情况下，flit内容到A和P的映射，其中一个flit携带MAC。图中橙色部分是MAC。

● 下图给出了5个flit组成MAC Epoch示例的更详细视图。顶部显示的Flit 0是在该MAC Epoch中要发送的第一个flit。该图描绘了仅受完整性保护的标题字段，以及加密和受完整性防护的文本内容。Flit 0明文0字节0是明文的第一个字节。Flit 1明文0字节0应紧跟在Flit 0明文0字节11之后。
（第一个flit（Flit0）中的数据从byte0到byte11是被AES-GCM加密算法加密和完整性保护的部分。而第二个flit（Flit1）中的数据应该是Flit0中明文数据的连续部分。为了确保正确性和完整性，Flit1的plaintext0 byte0必须直接跟在Flit0的byte11后进行传输。）

上面示例中，flit包头字节映射到AAD如下图。在上图中，只有Flit 0，2，3有flit包头。

11.1.5 加密的PCRC
使用系数为0x1EDC6F41的多项式进行PCRC计算。PCRC计算应从初始值0xFFFFFFFF开始（0xFFFFFFFF是一个32位全1的数值，在PCRC计算中具有良好的特性。通过使用全1的初始值，可以确保计算过程中每个位的初始状态都会被考虑在内，并且在遍历数据时能够检测到更广泛的错误情况。）。应在作为给定MAC Epoch的一部分的聚合flit中的所有明文字节上计算PCRC。PCRC计算应从flit明文内容的比特0字节0开始，并依次包括映射到明文的flit内容的每个字节的比特0-7。在跨flit内容累积32位值之后，应通过对累积值的位取1的补码来最终确定PCRC值，以获得PCRC[31:0]。
在发送端，PCRC值应附加到聚合的flit明文内容的末尾，进行加密并包含在MAC计算中。加密的PCRC值不在链路上传输。
在AES-GCM加密中包含PCRC机制：

流程：1.数据准备阶段–>2.预计算的PCRC值–>3.加密过程–>4.最终校验计算将初始PCRC值与PCRC计算中得到的最后一轮PCRC值进行异或运算，得到最终的PCRC校验值MAC
GHASH(H):GHASH是一个具有特殊结构的多项式哈希函数。它使用一个128位的密钥H，并针对输入数据进行异或和乘法运算，生成一个128位的校验值。校验值与明文数据一起被用于验证数据的完整性。在AES-GCM中，GHASH(H)用于计算附加身份验证数据（Additional Authentication Data，AAD）的校验值。AAD是一个可选的输入，用于提供关于数据的附加信息，但不会被加密。（H）：它使用一个128位的密钥
AES-CTR(K):在AES-CTR(K)中，K代表密钥，可以是128位、192位或256位的密钥。CTR模式中，对于每个要加密的数据块，计数器被递增，然后通过AES算法对计数器进行加密得到密钥流。密钥流与明文数据进行异或运算，从而实现加密。同样，解密过程也是通过对密文和密钥流进行异或运算得到明文。
MSB96:MSB96 是指数据的最高有效位（Most Significant Bits）的前 96 位。在AES-GCM加密中，MSB96 通常用于计算 GHASH 的输入。
GHASH 是用于计算数据的完整性校验值的多项式哈希函数，它接受两个输入：H 密钥和数据。当输入数据长度超过 64 位时，GHASH 会对数据进行分块处理。
在接收端，应根据接收到的解密密文重新计算PCRC值。当前MAC epoch的最后一个flit已被处理时，累积的PCRC值应与AES密钥流比特进行异或（加密），AES密钥流位紧跟在用于解密所接收的密码flit的值之后。为了MAC计算的目的，该加密的PCRC值应被附加到接收到的密文的末尾。

11.1.6 CXL.cachemem加密密钥和IV
CXL.cachemem IDE流的初始化涉及多个步骤。第一步是建立包含两个端口的组件的标识和认证，这两个端口充当CXL.cachemem IDE流的端点。第二步是建立IDE流的密钥。在某些情况下，这两个步骤可以合并。第三，配置IDE。最后，开始IDE流传输。
CXL.cachemem IDE可以利用CXL.io IDE机制进行设备认证和密钥交换。CXL.cachemem IDE的IV（初始化矢量）构造应遵循CXL.io PCIe规范。根据AES-GCM规范，使用确定性结构的96-bit IV。
● [95:92]位包含子流标识符，1000b，[91:64]位均为0。相同的子流编码用于发送和接收的flit，但端口在发送和接收流期间使用的密钥必须不同。
● [63:0]位包含一个单调递增的计数器。在建立IDE流时，每个子流的调用字段最初设置为值0000_0001h，并且每次使用IV时都会递增。
11.1.7 CXL.cache/CXL.mem IDE模式
CXL.cachemem IDE支持两种操作模式。
● Containment模式：此模式下，只有在完整性检查通过后，数据才会发布以供进一步处理。此模式会影响延迟和带宽。延迟影响是由于在接收并检查完完整性值前，需要缓冲多个flit。带宽影响是由于完整性值被频繁发送。如果支持并启用了containment模式，则设备（和主机）将使用Aggregation Flit Counter为5。因为此模式需要缓冲接收到的flit，所以AFC数量不会太大。
● Skid模式：滑动模式允许释放数据进行进一步处理，而无需等待完整性值的接收和检查。这样可以减少完整性值的传输频率。滑动模式允许接近零的延迟开销和非常低的带宽开销。在此模式下，被恶意修改的数据可能会被软件所接受和处理，但当接收并检查完整性值后才会检测到此类攻击。因此，当使用此模式时，软件和应用程序堆栈必须能够在狭窄的时间窗口内容忍攻击，否则结果是未定义的。如果支持并启用了skid模式，则设备（和主机）将使用Aggregation Flit Counter为128。
11.1.7.1 完整性模式的发现和设置
每个端口应通过CXL IDE的capability寄存器枚举其支持的模式和其它能力。所有符合本规范的设备应支持containment模式。
(containment模式是CXL协议中一种重要的工作模式，可以实现对多个设备的集中管理和控制。通过该模式，可以将多个设备组成一个逻辑集合，由一个主设备进行控制。这使得高性能计算和存储设备的互连和管理更加灵活和高效。因此，根据CXL协议的规范要求，所有设备都必须支持containment模式)
11.1.7.2 操作模式的协商和设置
在启用CXL.cachemem IDE之前，在CXL IDE的capability寄存器中配置操作模式和时序参数。
11.1.8 MAC聚合规则

1. For a x16 link operating at 32 Gbps, a 32 bit IV will take longer than 1000 years to roll over. (在一个运行速度为32 Gbps的x16连接中，一个32位的IV（Initialization Vector，初始化向量）在滚动完一次周期所需要的时间将超过1000年。意思是对于一个x16连接，它的传输速率为32 Gbps。根据这个标准，为了确保加密安全性，IV需要足够长，以避免在连接持续使用期间重复。) ● MAC_Epoch：一组连续的flit用于flit聚合。给定的MAC报头应包含恰好一个MAC_Epoch的标签。在发送之前，发送方应在一个MAC_Epoch（最多N个flit）中积累flit上的完整性值。 ● 在所有情况下，发送方必须按照与MAC Epochs相同的顺序发送MAC。 ● 下图显示了在存在背靠背协议流量的情况下，一个MAC_Epoch的MAC生成和传输示例。要发送或接收的最早的flit显示在图的顶部。因此，属于MAC_EPOCH 1的flit 0到N-1（以黄色显示）按该顺序发送。MAC是在flit 0到N-1上计算的。

● 发送方应尽早发送包含该完整性值的MAC报头。本规范允许在当前MAC_Epoch的最后一个flit的传输和该MAC_EpochMAC报头的实际传输之间传输属于下一个MAC_Epoch的协议flit。这可以避免由于MAC计算延迟而导致的带宽浪费。建议发送方在MAC计算完成后立即在第一个可用的Slot 0报头上发送MAC报头。在所有情况下，允许在发送先前MAC_Epoch MAC之前发送当前MAC_Epoch的最多5个协议flit。上图右侧就是发送了5个当前属于MAC_Epoch flit的情况。
● 接收方可以期望在先前MAC_Epoch的最后一个flit之后的从第一到第六个协议flit中的任一个flit接收到先前MAC_Epoch的MAC。还是对应上面的最多5个flit。

● 在containment模式中，接收方必须不释放（即给后续的功能模块）给定MAC_Epoch的flit，直到已经接收到包含这些flit的完整性值的MAC报头并且完整性检查已经通过。由于在接收先前MAC_Epoch的MAC报头之前，接收器可以接收属于当前MAC_Epoch的5个协议flit，因此接收方应缓冲当前MAC_Epoch的flit，以确保没有数据丢失。
● 在skid模式中，一旦接收到flit，接收器就可以解密并释放flit。MAC值应根据需要进行累积，并在MAC_Epoch中的MAC报头到达时进行完整性检查。
11.1.9 提前终止MAC
当前MAC_Epoch中传输的Flit少于聚合Flit计数时，允许发射机提前终止MAC_Epoch并在截断的MAC_Epoch中传输Flit的MAC。这是链路空闲（Link Idle）处理的一部分。在当前MAC_Epoch中传输了少于聚合Flit计数的多个协议Flit之后，链路可以准备进入空闲。
以下规则应适用于MAC_Epoch的提前终止和MAC的传输
当且仅当目前MAC_Epoch中的flit数少于Aggregation Flit Counter的数目（5或128，根据IDE模式），发送端才可以提前终止MAC。
下图是在3个协议flit之后截断当前MAC Epoch的示例。当前MAC Epoch中的flit可以是任何有效的协议flit，包括用于先前MAC Epoch的MAC的报头flit。对当前MAC Epoch的MAC使用截断MAC Flit发送。截断的MAC flit将在当前MAC Epoch的三个协议flit之后发送，而没有来自下一个MAC Epoch的其它协议flit。(在MAC Epoch中，所有的flits都按照一定的顺序传输，且相邻的flit之间必须满足一定的连续性要求。为了保证MAC计算的正确性，当一个发送器使用截断的MAC flit提前终止当前的MAC Epoch时，截断的MAC flit必须在当前MAC Epoch的所有协议flits传输完毕后再传输。因为截断的MAC flit与实际数据传输无关，它的传输不应该对当前MAC Epoch中正常的协议数据传输造成干扰)

IDLE or control flit can not be protocol flit belonging to nex EPOCH:
IDLE（空闲）或控制flit不能是属于下一个EPOCH的协议flit
在特定情况下，当一个EPOCH结束后，即将进入下一个EPOCH之前，可能会发送IDLE或控制flit。然而，这句话指出，这些IDLE或控制flits不能是属于下一个EPOCH的协议flits。换句话说，它们不应该包含下一个EPOCH的有效数据传输或协议信息。
这个规定的目的是确保在EPOCH之间的过渡期间，发送的flits不会被错误地解释为下一个EPOCH的协议flits，从而避免在传输中产生混淆或错误。

对于在链路在发送Aggregation Flit Count数量后变为空闲的情况下，则不得使用如上定义的截断MAC flit。MAC标头必须是下一个MAC Epoch的一部分。允许使用截断的MAC Flit提前终止此新的MAC Epoch，见下图。仅当MAC_Epoch中的flit数少于Aggregation Flit Counter的数目时才可以使用截断的MAC flit。(这意味着，当在MAC_Epoch中传输的协议flits数量正好等于Aggregation Flit Count时，如果链路在此之后变为空闲，那么下一个MAC Epoch将会包含上一个MAC Epoch的MAC头部，并且使用截断的MAC flit来提前终止。这种情况下，不会插入额外的截断MAC flit，以确保下一个MAC Epoch的连续性。)
11.1.9.1传输聚合Flit Count后链路空闲情况

在提前MAC终止和传输截断MAC之后，发射机必须发送至少TruncationDelay数量的IDE空闲flit，然后才能传输任何协议flit。TruncationDelay计算公式如下：
TruncationDelay = Min(Remaining Flits, Tx Min Truncation Transmit Delay)
Remaining Flits= Aggregation Flit Count - Number of protocol flits received in
current MAC Epoch
(TruncationDelay的计算中，使用了Min函数来对比剩余Flits数量和发送最小截断传输延迟，选择较小的值作为TruncationDelay。这意味着如果剩余Flits数量比发送最小截断传输延迟更小，那么TruncationDelay会等于剩余Flits数量；如果发送最小截断传输延迟比剩余Flits数量更小，那么TruncationDelay会等于发送最小截断传输延迟。)
11.1.10 Handshake to Trigger the Use of Keys
(“Handshake to Trigger the Use of Keys” 是一个过程，用于在发送方和接收方之间协调使用加密密钥。在该过程中，发送方首先会发送 IDE.Start flit，以指示使用新的密钥。在接收方收到 IDE.Start flit 后，它会切换到使用新密钥。但在此之前，为了确保接收方准备好使用该密钥，发送方需要发送一些空闲的 flit，以确保接收方已做好了使用新密钥的准备。在发送这些空闲 flit 后，有一个协商过程，以便发送方和接收方共同确认可以使用新的密钥。这个过程被称为 “Tx / Rx handshaking”，在完成后，随后所有的通讯都将使用新的密钥来保护。)
每个端口暴露的寄存器接口，软件可以使用该接口来编程传输和接收的密钥以及相关参数。这些编程的密钥将保留在寄存器中，直到激活为止。当密钥正在交换和配置时，链接可能正在使用先前配置的密钥。新的密钥直到执行下面所描述的操作后才会生效。
下面描述的机制用于将备份密钥切换到活动状态。这是为了确保发送器和接收器协调地切换到使用已编程密钥。
在链路的两端将密钥编程到待定寄存器之后，每个传输端口上的每个发射器都需要进行设备特定操作，以触发 IDE.Start链路层控制 flit（见表54）。确定并确保双方都完全配置的机制不属于本规范。

发送 IDE.Start 后，所有未来的协议 flit 都将由新密钥保护。为了让接收器准备好接收带有新密钥保护的 flit，发送器需要发送 IDE.idle flit，在发送任何带有新密钥的协议 flit 之前，按照表格54中定义的 flit 数量发送。这些空闲 flit 不加密也不完整性保护。发送器中的 Tx Key Refresh Time 寄存器字段（参见第8.2.5.14.7节）必须配置为比接收器的最长延迟更高的值，从而准备好使用新的密钥，而接收器通过 Rx Min Key Refresh Time 寄存器字段（第8.2.5.14.5节）广播其最长延迟。

收到 IDE.Start flit 后，接收器必须切换到使用新密钥。IDE.start flit 必须与协议 flit 有序。在链接级重试的情况下，接收器必须在处理 IDE.start flit 并切换到新密钥之前完成先前发送的协议 flit 的重试。只要保持上述排序，其他事件（如链路重新训练）可以发生在此流程中。

11.1.11 错误处理
CXL IDE不会影响或是要求对链路CRC错误处理和链路retry流程进行任何更改。
有关CXL.cachemem错误的详细信息记录在CXL IDE的Error Status寄存器中。当检测到CXL.cachemem IDE错误时，也会设置Uncorrectable Error Status寄存器中的相应位，并使用标准的CXL.cachemem协议错误信号机制发出错误信号。
在检测到完整性失败时：
● 在错误报告寄存器中记录完整性检查失败，并使用标准CXL.cachemem协议错误信号机制发出错误信号。
● 丢弃任何缓冲的协议flit，并丢弃所有后续的数据流，直到链路重置。
● 设备应防止密钥或用户数据泄露。设备可能需要实现清除数据/状态的机制，或者具有访问控制以防止机密泄露。
以下情况必须视为完整性失败：
● 当链路不处于安全模式时接收到MAC包头
● 未收到预期的MAC包头
● 接收到未预期的截断MAC Flit
● 在截断MAC flit之后，协议flit的接收时间早于预期
● 密钥切换后，协议flit的接收时间早于预期
我的理解，以上的情况均为可能链路收到攻击。
11.1.12 Switch支持
支持CXL.cachemem IDE的CXL Switch必须支持用于CXL.io的Link Stream IDE。(这是因为CXL.cachemem IDE 和 Link IDE 是两种不同的安全机制，用于保护 CXL 数据的机密性和完整性。CXL.cachemem IDE 用于加密和完整性保护 CXL 缓存和内存访问的数据，而 Link IDE 用于加密和完整性保护 CXL.io 流量在Swtich之间的传输过程中所携带的数据。因此，如果一个 CXL Swtich支持 CXL.cachemem IDE，它必须也支持 Link IDE，以确保在 CXL.io 流量中传输的数据也得到适当的保护。)
Switch可以选择性地支持CXL.io的Selective Stream IDE。对于CXL.io，CXL Swtich可以仅支持流通（flow-through）模式下的Selective Stream IDE。在这种情况下，不能在主机端启用CXL.cachemem IDE。(当 CXL Switch 仅支持流通模式下的 Selective Stream IDE 时，它只能对 CXL.io 流量进行流通模式下的选择性流控和数据带宽控制，而无法对 CXL 数据进行加密和完整性保护。这意味着 CXL.io 流量在通过不支持 CXL.cachemem IDE 的 CXL Switch 时，数据是不安全的，可能会被未经授权的访问或篡改。)
对具有多VCS（Virtual Channel Set）功能的Switch，可以在每个根端口的基础上启用CXL IDE。但是，一旦任何根端口启用了CXL IDE，从Switch到支持CXL IDE的MLD设备的下游链路就必须启用链路IDE。因此，来自未启用CXL IDE的根端口的数据流将被加密，并在Switch和设备之间受到完整性保护。
多VCS功能的Switch是指能够支持多个虚拟通道集的交换机。VCS 是一种用于在交换机内部进行流量隔离和管理的技术。