私はメモリデバイスの不揮発性メモリ制御やホストIFなどを扱うソフト屋をやっております。
仕事でCXL(Compute Express Link)まわりの技術に関わっています。
CXL技術に関連するメモ書きを残していこうと思います。
ホストのCPUとOS/Applicationまわりの経験・知識共に乏しいので、親切な方は教えて下さると幸いです。
また、間違い、アドバイス、その他、ご意見やご要望ありましたらお気軽にどうぞ。
今回は、CXLの通信路上のデータ保護機能であるCXL IDE (Integrity and Data Encryption)について簡単に書きます。この機能はオプショナルの機能です。
CPUベンダーの話を聞く限り、IntelのSGXやAMDのSEVといったCPUによるデータの暗号化機能があるため、少なくとも初期段階ではCPUがCXL IDE対応をすることはなさそうです。しばらくは、仕様として定められているけど対応機器がない状態になると思われます。
1. CXL IDE
CXL IDEで保護される対象となるデータは、CXL.io、CXL.cache、CXL.memで転送されるデータです。CXL IDEで防ぐ攻撃は、通信路上のデータの盗聴や改竄、なりすましです。DoS攻撃は対象外です。
CXL.ioについては、PCIeのECNで規定され、PCIe6から仕様書に入ったPCIE IDEに従います。
CXL.cache、CXL.memが、CXLの仕様書で扱われています。CXL.cache、CXL.memでデータ保護の対象となるのはControl FlitとAll Data Flitです。Protocol Flitはデータ保護の対象ではありません。
CXL.ioとCXL.cache/CXL.memのいずれもAES-GCMを使って、通信路上のデータの暗号化と完全性の確認を行います。
Control FlitとAll Data Flitの暗号化範囲と完全性確認範囲を下図に示します。
CXL IDEでは、セッション鍵共有のプロトコルは仕様範囲としていません。暗号化されたデータと完全性チェック値(MAC)のやり取りのみが、CXLの仕様で扱われる範囲です。PCIe IDEのセッション鍵の共有方法などを使用するよう記載されています。
CXL IDEで定められている暗号化・完全性の確認の流れの概略を下図に示します。
MACは、Header Slotを1つ消費して転送されます。Initial Vectorとして使われる値を下表に示します。
| Bit | Description |
|---|---|
| 95:92 | Sub-streamd ID (1000b固定) |
| 91:64 | All Zero |
| 63:0 | Invocation Field: カウンター |
カウンターはリプレイアタックを回避のために使われるカウンターです。MACの生成毎にインクリメントされます。
また、MAC算出に使用されるAAD(Additional Authentication Data)は、FlitのHeaderが使用されます。
MACは複数のFlitから算出されます。MAC算出に使用されるFlit数は、使用されるモードによって決定されます。
CXLでは以下に示す2つのモードが定められています。
-
Containment Mode
(MACの算出に使用された)FlitとMACが全て揃い、MACの一致の確認後にFlitに含まれるコマンドやデータが使用できるモードです。5個のFlitからMACが生成されます。 -
Skid Mode
MACの一致の確認前に、Flitに含まれるコマンドやデータが使用できるモードです。128個のFlitからMACが生成されます。
基本的には、Containment Modeでは5個のFlitが転送された後にMACが含まれるFlitが転送され、Containment Modeでは128個のFlitが転送された後にMACが含まれるFlitが転送されます。
CXLメモリデバイスでは、Containment Modeが使用された場合、MACの一致確認後にFlit内のコマンドの処理を行うことになるので、レイテンシに大きな影響を与えることになります。Skid Modeは、レイテンシに影響が少ないですが、Read/Writeのコマンド処理を行った後に、MAC値の不一致が確認されるとセキュリティ上の問題が発生する可能性があります。
CXL3.0の仕様書は、2022/6/14から45日間の内部レビューが始まっています。
今回までの記事で、主なCXL2.0の仕様について書いたように思います。CXL2.0の仕様に関するメモ書きは一旦終わりにします。
ご質問等ありましたら、できるだけお答えします。