CXL數(shù)據(jù)加解密技術(shù)學(xué)習(xí)

開始本章之前，需要對(duì)加密技術(shù)有所了解。

在數(shù)據(jù)傳輸中，有兩點(diǎn)需要注意，一個(gè)是數(shù)據(jù)的保密性。如果發(fā)送方A以明文方式發(fā)送消息給接收方B，則容易被第三方C截獲并分析出其中的內(nèi)容。為了提高數(shù)據(jù)的安全性，需要對(duì)消息加密。

第二點(diǎn)是數(shù)據(jù)的完整性。發(fā)送方A將消息加密發(fā)送給接收方B，但是如果這個(gè)過程中有第三方C截獲并且加以篡改（比如更改其中的一些bit或是更改密文塊的順序，此時(shí)C無需解密數(shù)據(jù)），然后再發(fā)送B，在B端是無法感知數(shù)據(jù)已經(jīng)被破壞。這就需要有機(jī)制保證數(shù)據(jù)的完整性，即在傳輸過程中沒有被破壞。單純的數(shù)據(jù)校驗(yàn)不能保證完整性，這是因?yàn)镃可以根據(jù)修改后的數(shù)據(jù)重新生成校驗(yàn)。

綜上，安全的數(shù)據(jù)傳輸方式是A將數(shù)據(jù)加密，并且給加密后的數(shù)據(jù)打上一個(gè)特有的標(biāo)簽（tag），然后將密文和標(biāo)簽一起發(fā)送給B；B接收到數(shù)據(jù)后，先要檢查標(biāo)簽，看看數(shù)據(jù)是否被修改過，確認(rèn)數(shù)據(jù)的完整性后再將數(shù)據(jù)解密。

常見的加密可以分為兩類，即對(duì)稱加密和非對(duì)稱加密。

• 對(duì)稱加密，也稱單密鑰加密，同一個(gè)密鑰既可以用作加密也可以用作解密。因此對(duì)稱加密的安全性不僅取決于加密算法本身，也和密鑰管理相關(guān)。采用對(duì)稱加密，收發(fā)雙方需要在通信前協(xié)商一個(gè)密鑰，并且雙方負(fù)責(zé)該密鑰的安全性。
• 非對(duì)稱加密算法使用兩把完全不同但又是完全匹配的一對(duì)鑰匙，公鑰（public key）和私鑰（private key）。加密明文時(shí)采用公鑰加密，解密密文時(shí)使用私鑰才能完成，而且發(fā)送方（加密者）知道接收方的公鑰，只有接收方（解密者）才是唯一知道自己私鑰的人。采用不對(duì)稱加密，收發(fā)雙方在通信之前，接收方必須將自己早已隨機(jī)生成的公鑰送給發(fā)送方，而自己保留私鑰，留待解密用。

CXL采用的是AES-GCM加密方式。

AES屬于對(duì)稱加密。加密技術(shù)包括兩個(gè)元素：算法和密鑰。以下圖為例，發(fā)送方將明文P（plain text）和密鑰K（key）通過加密函數(shù)，生成密文C（cipher text）；接收方在接收到密文C后，與密鑰K通過解密函數(shù)，恢復(fù)明文P。

AES是一種分組加密技術(shù)，所謂分組就是將明文P分成長(zhǎng)度相同的若干組，每次加密一組數(shù)據(jù)，直到加密完全部的明文。在AES規(guī)范中規(guī)定，分組長(zhǎng)度只能是128-bit。AES支持的密鑰長(zhǎng)度可以是128-bit，192-bit或256-bit，密鑰越長(zhǎng)，加密輪數(shù)越多，安全性越高，當(dāng)然消耗的時(shí)間也越多。

再來看加密模式，因?yàn)槊看沃荒芗用芤唤M數(shù)據(jù)，而實(shí)際的明文可能很長(zhǎng)，會(huì)分為很多組，此時(shí)就需要對(duì)這些分組進(jìn)行迭代，已完成整個(gè)明文的加密。迭代的方法就是加密模式。

說完AES，再來看看什么是MACs（Message Authentication Codes，消息認(rèn)證碼）。消息認(rèn)證碼是一種允許對(duì)接收到的消息進(jìn)行身份驗(yàn)證的信息，確保消息來自聲稱的發(fā)送者，而不是偽裝成他們的第三方，同時(shí)確保消息沒有以某種方式修改，以提供數(shù)據(jù)完整性。

消息認(rèn)證碼的輸入為任意長(zhǎng)度的消息和一個(gè)發(fā)送者與接收者之間共享的密鑰，它可以輸出固定長(zhǎng)度的數(shù)據(jù)，這個(gè)數(shù)據(jù)稱為MAC 值。用于生成消息認(rèn)證碼的密鑰與用于驗(yàn)證消息認(rèn)證碼的密鑰相同。從這個(gè)意義上講，它類似于對(duì)稱加密系統(tǒng)，并且密鑰必須由所有通信方事先商定或以某種安全方式共享。

回過頭來看AES-GCM，GCM是認(rèn)證加密模式中的一種，其中G指的是GMAC，即利用伽羅華域(Galois Field，GF，有限域)乘法運(yùn)算來計(jì)算消息的MAC值；C指的是CTR。

11.1 CXL IDE

CXL完整性和數(shù)據(jù)加密（Integrity and Data Encryption，IDE）定義了為傳輸CXL鏈路的數(shù)據(jù)提供機(jī)密性、完整性和重播保護(hù)的機(jī)制。加密方案與當(dāng)前行業(yè)最佳實(shí)踐保持一致。它支持各種使用模型，同時(shí)提供廣泛的互操作性。CXL IDE可用于在由多個(gè)組件組成的可信執(zhí)行環(huán)境（TEE）中保護(hù)流量，然而，這種組合的框架不在本規(guī)范的范圍內(nèi)。

11.1.1 范圍

本章重點(diǎn)介紹通過鏈路傳輸?shù)腃XL.cache和CXL.mem流量傳輸，以及對(duì)控制CXL.io流量的PCIe基本規(guī)范的更新/限制。

• CXL.io IDE的定義基于PCIe的IDE規(guī)范
• CXL.cachemem IDE可以使用基于CXL.io的機(jī)制進(jìn)行發(fā)現(xiàn)（discovery）、協(xié)商（negotiation）、設(shè)備證明（device attestation）和密鑰協(xié)商（key negotiation）。

本規(guī)范中，CXL IDE指代保護(hù)CXL.io，CXL.cache，CXL.mem數(shù)據(jù)流的機(jī)制，CXL.cachemem IDE指代保護(hù)CXL.cache，CXL.mem數(shù)據(jù)流的機(jī)制。如果沒有明確指出，則遵循PCIe規(guī)范。CXL.io基本上與PCIe IDE的要求一致。拒絕服務(wù)攻擊（denial of services）不在范圍內(nèi)。

11.1.2 CXL.io IDE

CXL.io IDE遵循PCIe IDE定義。

解釋幾個(gè)名詞。IDE流（IDE stream）指的是，使用完整性和數(shù)據(jù)加密定義的機(jī)制建立的端口到端口連接，以保護(hù)兩個(gè)端口之間的TLP流量（traffic）。IDE流可以是selective IDE stream形式，IDE TLP可以在不影響其安全性的情況下流經(jīng)交換機(jī)；也可以是Link stream形式，兩個(gè)端口必須在沒有中間交換機(jī)的情況下連接，也就是直連。參考下圖，端口C和G之間以及端口G和H之間的selective IDE stream在通過交換機(jī)時(shí)是安全的。

Flow-Through 指的是對(duì)switch和RC，TLP從入口端口傳遞到出口端口而不進(jìn)行修改的行為。

IDE terminus，作為與一個(gè)或多個(gè)IDE流相關(guān)聯(lián)的IDE TLP的發(fā)起方或最終目的地的端口。

11.1.3 CXL.cache/CXL.mem IDE高層概覽

• 所有協(xié)議級(jí)別的重試flit都經(jīng)過加密并受到完整性保護(hù)。
• 鏈路層控制flit和flit CRC沒有加密，也沒有完整性保護(hù)。
• LCRC應(yīng)該在加密flit上計(jì)算。
• 任何完整性檢查失敗的數(shù)據(jù)流都應(yīng)被放棄。
• 必須支持多數(shù)據(jù)頭功能。這允許將多個(gè)（最多4個(gè)）數(shù)據(jù)頭打包到一個(gè)slot中，然后緊接著是所有數(shù)據(jù)的16個(gè)slot。
• 采用256-bit密鑰的AES-GCM加解密
• 必須支持在不丟失任何數(shù)據(jù)的情況下進(jìn)行密鑰刷新
• 密鑰刷新預(yù)計(jì)不經(jīng)常發(fā)生。延遲/帶寬受到影響是可以接受的，但不能有任何數(shù)據(jù)丟失。
• 支持加密PCRC機(jī)制。加密PCRC集成到標(biāo)準(zhǔn)MAC檢查機(jī)制中，不消耗額外鏈路帶寬，不增加顯著額外延遲。PCRC對(duì)于CXL.cachemem IDE是強(qiáng)制性的，并且在默認(rèn)情況下是啟用的

11.1.4 CXL.cache/CXL.mem IDE架構(gòu)

• IDE應(yīng)當(dāng)以flit為單位，使用AES-GCM模式。AES-GCM采用三個(gè)輸入，分別為附加身份驗(yàn)證數(shù)據(jù)（Additional Authentication data，AAD，在AES-GCM規(guī)范中指定為A）、明文（P）和初始化矢量（IV）。在CXL.cachemem協(xié)議中，32-bit的數(shù)據(jù)包頭作為slot 0的一部分，映射到A——它沒有加密，但受到完整性保護(hù)。Slot 0/1/2/3的映射到P，P經(jīng)過加密并受到完整性保護(hù)。CXL.cachemem協(xié)議也支持僅有數(shù)據(jù)（data-only）的flit，在這種情況下，flit中的所有4個(gè)slot映射到P。
• LCRC不加密且不受到完整性保護(hù)。在flit被加密之后，對(duì)其計(jì)算CRC
• IDE flit也遵守用于檢測(cè)和糾正錯(cuò)誤的鏈路層機(jī)制。
• AES-GCM可以應(yīng)用于多flit聚合，這些flit組成一個(gè)MAC_Epoch?？梢跃酆系膄lit數(shù)目取決于Aggregation Flit Count。如果啟用PCRC，則32-bit的PCRC值應(yīng)這些聚合的flit的末尾，以產(chǎn)生受完整性保護(hù)的最終P值。然而，PCRC的32-bit并不在鏈路上傳輸?shù)?。下圖顯示了在5個(gè)flit聚合MAC的情況下，flit內(nèi)容到A和P的映射。圖中深灰色部分是flit header，映射到A；淺灰色部分是數(shù)據(jù)，映射到P。

• MAC是96-bit，MAC必須在H6類型的slot 0報(bào)頭中傳輸。MAC本身既沒有加密，也沒有完整性保護(hù)。下圖顯示了在5個(gè)flit聚合MAC的情況下，flit內(nèi)容到A和P的映射，其中一個(gè)flit攜帶MAC。圖中橙色部分是MAC。

• 下圖給出了5個(gè)flit組成MAC Epoch示例的更詳細(xì)視圖。頂部顯示的Flit 0是在該MAC Epoch中要發(fā)送的第一個(gè)flit。該圖描繪了僅受完整性保護(hù)的標(biāo)題字段，以及加密和受完整性防護(hù)的文本內(nèi)容。Flit 0明文0字節(jié)0是明文的第一個(gè)字節(jié)。Flit 1明文0字節(jié)0應(yīng)緊跟在Flit 0明文0字節(jié)11之后。

上面示例中，flit包頭字節(jié)映射到AAD如下圖。在上圖中，只有Flit 0，2，3有flit包頭。

11.1.5 加密的PCRC

使用系數(shù)為0x1EDC6F41的多項(xiàng)式進(jìn)行PCRC計(jì)算。PCRC計(jì)算應(yīng)從初始值0xFFFFFFFF開始。應(yīng)在作為給定MAC Epoch的一部分的聚合flit中的所有明文字節(jié)上計(jì)算PCRC。PCRC計(jì)算應(yīng)從flit明文內(nèi)容的比特0字節(jié)0開始，并依次包括映射到明文的flit內(nèi)容的每個(gè)字節(jié)的比特0-7。在跨flit內(nèi)容累積32位值之后，應(yīng)通過對(duì)累積值的位取1的補(bǔ)碼來最終確定PCRC值，以獲得PCRC[31:0]。

在發(fā)送端，PCRC值應(yīng)附加到聚合的flit明文內(nèi)容的末尾，進(jìn)行加密并包含在MAC計(jì)算中。加密的PCRC值不在鏈路上傳輸。

在接收端，應(yīng)根據(jù)接收到的解密密文重新計(jì)算PCRC值。當(dāng)前MAC epoch的最后一個(gè)flit已被處理時(shí)，累積的PCRC值應(yīng)與AES密鑰流比特進(jìn)行異或（加密），AES密鑰流位緊跟在用于解密所接收的密碼flit的值之后。為了MAC計(jì)算的目的，該加密的PCRC值應(yīng)被附加到接收到的密文的末尾。

11.1.6 CXL.cachemem加密密鑰和IV

CXL.cachemem IDE流的初始化涉及多個(gè)步驟。第一步是建立包含兩個(gè)端口的組件的標(biāo)識(shí)和認(rèn)證，這兩個(gè)端口充當(dāng)CXL.cachemem IDE流的端點(diǎn)。第二步是建立IDE流的密鑰。在某些情況下，這兩個(gè)步驟可以合并。第三，配置IDE。最后，開始IDE流傳輸。

CXL.cachemem IDE可以利用CXL.io IDE機(jī)制進(jìn)行設(shè)備認(rèn)證和密鑰交換。CXL.cachemem IDE的IV（初始化矢量）構(gòu)造應(yīng)遵循CXL.io PCIe規(guī)范。根據(jù)AES-GCM規(guī)范，使用確定性結(jié)構(gòu)的96-bit IV。

• [95:92]位包含子流標(biāo)識(shí)符，1000b，[91:64]位均為0。相同的子流編碼用于發(fā)送和接收的flit，但端口在發(fā)送和接收流期間使用的密鑰必須不同。
• [63:0]位包含一個(gè)單調(diào)遞增的計(jì)數(shù)器。在建立IDE流時(shí)，每個(gè)子流的調(diào)用字段最初設(shè)置為值0000_0001h，并且每次使用IV時(shí)都會(huì)遞增。

11.1.7 CXL.cache/CXL.mem IDE模式

CXL.cachemem IDE支持兩種操作模式。

• Containment模式：此模式下，只有在完整性檢查通過后，數(shù)據(jù)才會(huì)發(fā)布以供進(jìn)一步處理。此模式會(huì)影響延遲和帶寬。延遲影響是由于在接收并檢查完完整性值前，需要緩沖多個(gè)flit。帶寬影響是由于完整性值被頻繁發(fā)送。如果支持并啟用了containment模式，則設(shè)備（和主機(jī)）將使用Aggregation Flit Counter為5。因?yàn)榇四Ｊ叫枰彌_接收到的flit，所以AFC數(shù)量不會(huì)太大。
• Skid模式：滑動(dòng)模式允許釋放數(shù)據(jù)進(jìn)行進(jìn)一步處理，而無需等待完整性值的接收和檢查。這樣可以減少完整性值的傳輸頻率?；瑒?dòng)模式允許接近零的延遲開銷和非常低的帶寬開銷。在此模式下，被惡意修改的數(shù)據(jù)可能會(huì)被軟件所接受和處理，但當(dāng)接收并檢查完整性值后才會(huì)檢測(cè)到此類攻擊。因此，當(dāng)使用此模式時(shí)，軟件和應(yīng)用程序堆棧必須能夠在狹窄的時(shí)間窗口內(nèi)容忍攻擊，否則結(jié)果是未定義的。如果支持并啟用了skid模式，則設(shè)備（和主機(jī)）將使用Aggregation Flit Counter為128。

11.1.7.1 完整性模式的發(fā)現(xiàn)和設(shè)置

每個(gè)端口應(yīng)通過CXL IDE的capability寄存器枚舉其支持的模式和其它能力。所有符合本規(guī)范的設(shè)備應(yīng)支持containment模式。

11.1.7.2 操作模式的協(xié)商和設(shè)置

在啟用CXL.cachemem IDE之前，在CXL IDE的capability寄存器中配置操作模式和時(shí)序參數(shù)。

11.1.8 MAC聚合規(guī)則

• MAC_Epoch：一組連續(xù)的flit用于flit聚合。給定的MAC報(bào)頭應(yīng)包含恰好一個(gè)MAC_Epoch的標(biāo)簽。在發(fā)送之前，發(fā)送方應(yīng)在一個(gè)MAC_Epoch（最多N個(gè)flit）中積累flit上的完整性值。
• 在所有情況下，發(fā)送方必須按照與MAC Epochs相同的順序發(fā)送MAC。
• 下圖顯示了在存在背靠背協(xié)議流量的情況下，一個(gè)MAC_Epoch的MAC生成和傳輸示例。要發(fā)送或接收的最早的flit顯示在圖的頂部。因此，屬于MAC_EPOCH 1的flit 0到N-1（以黃色顯示）按該順序發(fā)送。MAC是在flit 0到N-1上計(jì)算的。

• 發(fā)送方應(yīng)盡早發(fā)送包含該完整性值的MAC報(bào)頭。本規(guī)范允許在當(dāng)前MAC_Epoch的最后一個(gè)flit的傳輸和該MAC_EpochMAC報(bào)頭的實(shí)際傳輸之間傳輸屬于下一個(gè)MAC_Epoch的協(xié)議flit。這可以避免由于MAC計(jì)算延遲而導(dǎo)致的帶寬浪費(fèi)。建議發(fā)送方在MAC計(jì)算完成后立即在第一個(gè)可用的Slot 0報(bào)頭上發(fā)送MAC報(bào)頭。在所有情況下，允許在發(fā)送先前MAC_Epoch MAC之前發(fā)送當(dāng)前MAC_Epoch的最多5個(gè)協(xié)議flit。上圖右側(cè)就是發(fā)送了5個(gè)當(dāng)前屬于MAC_Epoch flit的情況。
• 接收方可以期望在先前MAC_Epoch的最后一個(gè)flit之后的從第一到第六個(gè)協(xié)議flit中的任一個(gè)flit接收到先前MAC_Epoch的MAC。還是對(duì)應(yīng)上面的最多5個(gè)flit。

• 在containment模式中，接收方必須不釋放（即給后續(xù)的功能模塊）給定MAC_Epoch的flit，直到已經(jīng)接收到包含這些flit的完整性值的MAC報(bào)頭并且完整性檢查已經(jīng)通過。由于在接收先前MAC_Epoch的MAC報(bào)頭之前，接收器可以接收屬于當(dāng)前MAC_Epoch的5個(gè)協(xié)議flit，因此接收方應(yīng)緩沖當(dāng)前MAC_Epoch的flit，以確保沒有數(shù)據(jù)丟失。
• 在skid模式中，一旦接收到flit，接收器就可以解密并釋放flit。MAC值應(yīng)根據(jù)需要進(jìn)行累積，并在MAC_Epoch中的MAC報(bào)頭到達(dá)時(shí)進(jìn)行完整性檢查。

11.1.9提前終止MAC

當(dāng)前MAC_Epoch中傳輸?shù)腇lit少于聚合Flit計(jì)數(shù)時(shí)，允許發(fā)射機(jī)提前終止MAC_Epoch并在截?cái)嗟腗AC_Epoch中傳輸Flit的MAC。這是鏈路空閑（Link Idle）處理的一部分。在當(dāng)前MAC_Epoch中傳輸了少于聚合Flit計(jì)數(shù)的多個(gè)協(xié)議Flit之后，鏈路可以準(zhǔn)備進(jìn)入空閑。

以下規(guī)則應(yīng)適用于MAC_Epoch的提前終止和MAC的傳輸

當(dāng)且僅當(dāng)目前MAC_Epoch中的flit數(shù)少于Aggregation Flit Counter的數(shù)目（5或128，根據(jù)IDE模式），發(fā)送端才可以提前終止MAC。

下圖是在3個(gè)協(xié)議flit之后截?cái)喈?dāng)前MAC Epoch的示例。當(dāng)前MAC Epoch中的flit可以是任何有效的協(xié)議flit，包括用于先前MAC Epoch的MAC的報(bào)頭flit。對(duì)當(dāng)前MAC Epoch的MAC使用截?cái)郙AC Flit發(fā)送。截?cái)嗟腗AC flit將在當(dāng)前MAC Epoch的三個(gè)協(xié)議flit之后發(fā)送，而沒有來自下一個(gè)MAC Epoch的其它協(xié)議flit。

對(duì)于在鏈路在發(fā)送Aggregation Flit Count數(shù)量后變?yōu)榭臻e的情況下，則不得使用如上定義的截?cái)郙AC flit。MAC標(biāo)頭必須是下一個(gè)MAC Epoch的一部分。允許使用截?cái)嗟腗AC Flit提前終止此新的MAC Epoch，見下圖。規(guī)范在這里說的很拗口，直白一點(diǎn)就是，僅當(dāng)MAC_Epoch中的flit數(shù)少于Aggregation Flit Counter的數(shù)目時(shí)才可以使用截?cái)嗟腗AC flit。

在提前MAC終止和傳輸截?cái)郙AC之后，發(fā)射機(jī)必須發(fā)送至少TruncationDelay數(shù)量的IDE空閑flit，然后才能傳輸任何協(xié)議flit。TruncationDelay計(jì)算公式如下：

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

Remaining Flits= Aggregation Flit Count - Number of protocol flits received in

current MAC Epoch

11.1.10 Handshake to Trigger the Use of Keys

每個(gè)端口都公開了一個(gè)寄存器接口，軟件可以使用該接口對(duì)發(fā)送和接收密鑰及相關(guān)參數(shù)進(jìn)行設(shè)置。在激活之前，這些密鑰在寄存器中保持掛起狀態(tài)。當(dāng)密鑰在上游和下游端口中交換和配置時(shí)，鏈路可以主動(dòng)使用先前配置的密鑰。

下面描述的機(jī)制用于將備份密鑰切換到活動(dòng)狀態(tài)。

在密鑰被編程到鏈路兩側(cè)的掛起寄存器中后，每個(gè)端口上的每個(gè)發(fā)射機(jī)上都應(yīng)有一個(gè)特定于設(shè)備的動(dòng)作，以觸發(fā)IDE.Start鏈路層控制微片的傳輸。

在發(fā)送了IDE.Start之后，所有后續(xù)的協(xié)議flit都將受到新密鑰的保護(hù)。為了讓接收器準(zhǔn)備好接收用新密鑰保護(hù)的微片，發(fā)送器需要在發(fā)送任何帶有新密鑰的協(xié)議flit之前，發(fā)送IDE.idle flit。表54中定義了，在發(fā)送具有新密鑰的任何協(xié)議flit之前，由寄存器字段Tx Key Refresh Time指定的flit數(shù)量。這些空閑的flit沒有被加密或受到完整性保護(hù)。發(fā)射器中的TxKey Refresh Time必須配置為高于接收器中最壞情況延遲的值，以便準(zhǔn)備使用新密鑰，接收器通過Rx Min Key Refresh Time寄存器字段公布新密鑰。在接收到IDE.Start flit之后，接收器必須切換到使用新的密鑰。IDE.start flit應(yīng)針對(duì)協(xié)議flit進(jìn)行排序。在鏈路級(jí)retry的情況下，接收器應(yīng)在處理IDE.start flit并切換到新密鑰之前完成先前發(fā)送的協(xié)議flit的retry。

11.1.11 錯(cuò)誤處理

CXL IDE不會(huì)影響或是要求對(duì)鏈路CRC錯(cuò)誤處理和鏈路retry流程進(jìn)行任何更改。

有關(guān)CXL.cachemem錯(cuò)誤的詳細(xì)信息記錄在CXL IDE的Error Status寄存器中。當(dāng)檢測(cè)到CXL.cachemem IDE錯(cuò)誤時(shí)，也會(huì)設(shè)置Uncorrectable Error Status寄存器中的相應(yīng)位，并使用標(biāo)準(zhǔn)的CXL.cachemem協(xié)議錯(cuò)誤信號(hào)機(jī)制發(fā)出錯(cuò)誤信號(hào)。

在檢測(cè)到完整性失敗時(shí)：

• 在錯(cuò)誤報(bào)告寄存器中記錄完整性檢查失敗，并使用標(biāo)準(zhǔn)CXL.cachemem協(xié)議錯(cuò)誤信號(hào)機(jī)制發(fā)出錯(cuò)誤信號(hào)。
• 丟棄任何緩沖的協(xié)議flit，并丟棄所有后續(xù)的數(shù)據(jù)流，直到鏈路重置。
• 設(shè)備應(yīng)防止密鑰或用戶數(shù)據(jù)泄露。設(shè)備可能需要實(shí)現(xiàn)清除數(shù)據(jù)/狀態(tài)的機(jī)制，或者具有訪問控制以防止機(jī)密泄露。

以下情況必須視為完整性失?。?/p>

• 當(dāng)鏈路不處于安全模式時(shí)接收到MAC包頭
• 未收到預(yù)期的MAC包頭
• 接收到未預(yù)期的截?cái)郙AC Flit
• 在截?cái)郙AC flit之后，協(xié)議flit的接收時(shí)間早于預(yù)期
• 密鑰切換后，協(xié)議flit的接收時(shí)間早于預(yù)期

我的理解，以上的情況均為可能鏈路收到攻擊。

11.1.12 交換機(jī)支持

支持CXL.cachemem IDE的CXL交換機(jī)必須支持用于CXL.io的Link Stream IDE。

交換機(jī)可以選擇性地支持CXL.io的Selective Stream IDE。對(duì)于CXL.io，CXL交換機(jī)可以僅支持流通（flow-through）模式下的Selective Stream IDE。在這種情況下，不能在主機(jī)端啟用CXL.cachemem IDE。

對(duì)具有多VCS功能的交換機(jī)，可以在每個(gè)根端口的基礎(chǔ)上啟用CXL IDE。但是，一旦任何根端口啟用了CXL IDE，從交換機(jī)到支持CXL IDE的MLD設(shè)備的下游鏈路就必須啟用鏈路IDE。因此，來自未啟用CXL IDE的根端口的數(shù)據(jù)流將被加密，并在交換機(jī)和設(shè)備之間受到完整性保護(hù)。

總結(jié)：本章內(nèi)容為CXL數(shù)據(jù)加解密。CXL采用AES-GCM模式進(jìn)行數(shù)據(jù)加解密，CXL.io的IDE基本與PCIe的IDE一致，因此本章主要是對(duì)CXL.cachemem IDE進(jìn)行約束。