Add deep review of AIORE CXL security paper

docs/papers/aiore-cxl-security.md

@@ -0,0 +1,425 @@
+---
+title: Efficient Security Support for CXL Memory through Adaptive Incremental Offloaded (Re-)Encryption
+authors: Chuanhan Li, Jishen Zhao, Yuanchao Xu
+year: 2025
+venue: MICRO '25
+tags:
+  - cxl
+  - memory-security
+  - tee
+  - systems
+  - computer-architecture
+status: published
+---
+
+# Efficient Security Support for CXL Memory through Adaptive Incremental Offloaded (Re-)Encryption
+
+> [DOI 链接](https://doi.org/10.1145/3725843.3756119)
+
+## 一句话总结
+
+这篇论文针对 **CXL memory 在 TEE 场景下的高安全开销**问题，提出了 **AIORE**：按页在 **XTS** 与 **CTR** 两种加密方式间自适应切换，并结合 **增量式重加密** 与 **内存侧卸载重加密**，在保证安全属性的同时显著降低了 secure CXL 的性能损失。
+
+## 这篇论文在解决什么问题？
+
+随着 DRAM 扩展越来越困难，CXL 被视为提升内存容量和带宽的重要方向。问题在于：
+
+- CXL memory 会把内存扩展到 **CPU 之外的设备/节点**；
+- 公有云环境里又必须考虑 **机密性、完整性、重放保护、链路攻击**；
+- 现有方案通常把 **TEE 内存加密** 和 **CXL IDE 链路加密**叠加使用；
+- 但这种“安全全开”的代价很高，尤其是在 **memory-intensive workloads** 上。
+
+论文的核心观察是：
+
+> 现有 secure CXL 的主要瓶颈不只是“要不要加密”，而是**哪种加密适合哪类页，以及切换/重加密怎么做才不把系统拖垮**。
+
+作者重点针对一种主流基线：
+
+- 主机侧使用 **XTS-based TEE** 保护内存内容；
+- CXL 链路使用 **CXL IDE（AES-GCM）** 保护传输；
+
+虽然安全属性完整，但 **XTS 解密在读路径上延迟很高**，对 CXL 这种本来就更远的内存尤为敏感。
+
+## 背景：为什么 secure CXL 会慢？
+
+论文把问题拆成两层：
+
+### 1. CXL 链路层安全：CXL IDE
+
+CXL IDE 用 **AES-GCM** 在 Flit 级别提供：
+
+- 机密性
+- 完整性
+- 唯一性
+- 重放保护
+
+这解决的是 **CPU ↔ CXL 设备链路被窃听/篡改/重放** 的问题。
+
+### 2. 内存内容安全：TEE memory encryption
+
+现有 TEE 常见有两类：
+
+- **XTS / counterless encryption**
+- **CTR / counter mode encryption**
+
+它们的性能特点不同：
+
+#### XTS 的优点
+- 不需要 per-line counter metadata
+- 结构简单
+
+#### XTS 的缺点
+- 读请求返回后还要做 XTS 解密
+- 解密延迟在关键路径上，很难完全隐藏
+
+#### CTR 的优点
+- 如果 counter cache hit，可以**并行生成 OTP**，数据一到就 XOR 得到明文
+- 命中时延迟很接近 insecure case
+
+#### CTR 的缺点
+- 依赖 counter cache
+- miss 时要额外取 counter，带来更多带宽和延迟
+- 如果使用 split counter，又会带来 counter overflow 和 page re-encryption 的开销
+
+论文的出发点正是：
+
+> **XTS 稳，但慢；CTR 快，但并不是所有页都适合。**
+
+所以与其全局只选一种，不如按页自适应。
+
+## 核心思路：AIORE 到底是什么？
+
+AIORE = **Adaptive Incremental Offloaded (Re-)Encryption**
+
+作者提出了三件配套设计：
+
+### 1. Per-page adaptive encryption
+
+对每个 page 动态选择：
+
+- **XTS**：适合低复用/冷页
+- **CTR**：适合高访问频率/热页
+
+这样做的原因是：
+
+- 对热页，CTR 更容易从 counter cache hit 中获益；
+- 对冷页，如果也上 CTR，它们的 counters 反而会污染 counter cache；
+- 冷页明明复用不高，却要承担 counter metadata 成本，得不偿失。
+
+也就是说，AIORE 的第一个关键点不是“发明一种新加密算法”，而是：
+
+> **把页面访问热度纳入加密模式选择。**
+
+这是很有 systems 味道的设计：不在算法层死磕，而是在机制层把不同工作负载特征分流。
+
+### 2. Incremental re-encryption
+
+仅仅支持“页模式切换”还不够，因为：
+
+- XTS ↔ CTR 切换需要重加密；
+- split counter overflow 也可能触发整页重加密；
+
+如果每次都停下来整页读出、解密、再加密、写回，代价很大。
+
+因此作者提出 **incremental re-encryption**：
+
+- 不一次性粗暴重加密整个页；
+- 而是把重加密工作和**程序本来就会发生的访问**结合起来；
+- 在正常数据访问与加解密流程中，逐步完成该页转换。
+
+核心思想是：
+
+> **把本来必须发生的访问利用起来，顺手完成重加密。**
+
+这能显著降低模式切换和 counter overflow 带来的突发开销。
+
+### 3. Offloaded re-encryption
+
+但仍有一种情况：
+
+- 某页只被访问了一部分 cachelines；
+- 剩余 cachelines 长时间不再被程序触碰；
+- 这样 incremental re-encryption 会“卡尾巴”。
+
+所以 AIORE 进一步把剩余的 re-encryption **卸载到 memory node**：
+
+- 当某页在一段时间内未完成重加密；
+- 由 CXL memory 侧计算单元完成剩余部分；
+- 减少 host 额外参与和链路往返。
+
+这一步非常关键，因为它把“安全维护成本”从 host 关键路径中继续剥离出去。
+
+## 论文的技术判断为什么成立？
+
+我觉得这篇最好的地方，是它没有简单喊一句“CTR 比 XTS 快”，而是认真分析了 **什么时候快，什么时候反而会变慢**。
+
+论文指出了两个典型 inefficiency：
+
+### inefficiency 1：CTR 不适合所有页
+
+如果所有页都采用 CTR：
+
+- 热页和冷页都要占用 counter cache；
+- 冷页 counter 复用很低；
+- 它们会污染 cache，伤害真正该受益的热页。
+
+### inefficiency 2：split counter 虽然省空间，但 overflow 很贵
+
+使用更紧凑的 split counter：
+
+- 能提升 counter cache hit rate；
+- 但 minor counter 更容易 overflow；
+- overflow 后整页重加密会非常贵，尤其在 CXL memory 环境下更贵。
+
+所以 AIORE 的真正贡献不是“CTR + XTS 混合”这么简单，而是：
+
+> **把 page hotness、counter cache pressure、re-encryption cost、memory-node compute 这几件事统一到一个机制里。**
+
+## 安全性上做了什么保证？
+
+论文的 baseline threat model 大体延续现有 TEE + CXL IDE 体系：
+
+- 可信部分包括 CPU、memory controller、CXL controller 等 TCB；
+- 不可信部分包括 off-chip memory、OS、hypervisor；
+- 还考虑物理窃听、篡改、重放等链路攻击；
+- side-channel、DoS、CPU bugs 不在本文范围内。
+
+作者比较了多种设计的安全/性能权衡：
+
+- **XTS TEE + CXL IDE**：安全完整，但性能较差；
+- **CTR TEE + CXL IDE**：在 counter hit 时更快；
+- **CTR + integrity tree**：有不同的安全/性能特点，但不完全等价于当前基线；
+- **AIORE**：希望在维持所需安全属性下逼近 insecure performance。
+
+从论文表述看，AIORE 不是牺牲安全换性能，而是通过：
+
+- 按页选择加密模式
+- 更低代价完成模式切换/重加密
+- 减少 host 关键路径上的冗余工作
+
+来获得性能收益。
+
+## 评估方法与结果
+
+作者在 **Gem5** 上实现并评估 AIORE，和 **7 个 baselines** 比较，工作负载来自：
+
+- SPEC2017
+- SPEC2006
+- 图计算应用
+
+### 论文给出的主要结果
+
+- 相比各类安全基线，AIORE 平均减少 **62.8%** 的 security overhead
+- 相比 insecure CXL：
+  - 单核平均开销约 **3.2%**
+  - 多核平均开销约 **4.3%**
+- 摘要和正文中也强调其总体 overhead 大致可控制在 **3%~4%** 量级
+
+这是一个相当强的结果，因为它意味着：
+
+> secure CXL 不再是“安全一开，性能明显掉一截”，而是可以逼近不加密时的表现。
+
+## 我认为这篇最重要的贡献
+
+如果让我提炼成一句话，这篇论文的价值在于：
+
+> 它把“secure CXL 性能差”的问题，从单一的密码学延迟问题，重新建模成了一个**页级冷热性驱动的体系结构优化问题**。
+
+更具体一点，有三个层面的贡献：
+
+### 1. 重新定义了优化对象
+
+不是只优化某一次加密，而是优化：
+
+- 哪些页值得用 CTR
+- 哪些页继续留在 XTS
+- 切换代价如何被平摊
+- 剩余维护工作如何卸载到 memory node
+
+### 2. 体现了 CXL 时代 memory-side compute 的价值
+
+这篇论文不是把 memory node 当被动设备，而是当成一个可以承担系统维护工作的参与者。
+
+这和传统“CPU 主导一切”的思路不同，很符合 CXL / disaggregated memory 未来的发展方向。
+
+### 3. 证明 secure disaggregated memory 不一定天然高开销
+
+过去大家常默认：
+
+- 内存一旦跨节点/跨链路
+- 又叠加完整安全机制
+- 性能肯定会非常难看
+
+AIORE 的结果表明这并非必然，只要机制设计合理，secure CXL 可以接近 insecure baseline。
+
+## 局限与可能问题
+
+虽然这篇论文做得很漂亮，但我觉得也有几个值得继续追问的地方。
+
+### 1. 依赖访问模式稳定性
+
+AIORE 的收益来自“按页冷热性做选择”。
+
+如果一个 workload：
+
+- 相位变化特别快；
+- 页面冷热频繁翻转；
+- 访问行为高度不稳定；
+
+那么模式切换判断是否还能稳定获益，需要更仔细验证。
+
+### 2. 增量重加密与卸载重加密引入了更复杂的状态机
+
+相比传统单一加密模式，AIORE 明显更复杂：
+
+- 页当前使用什么模式
+- 重加密进行到哪一步
+- 哪些 lines 已切换，哪些未切换
+- 何时由 host 完成，何时交给 memory node
+
+这种复杂性在真实硬件中会带来：
+
+- 更高设计验证成本
+- corner case 处理难度增加
+- 故障恢复/一致性维护更麻烦
+
+### 3. Gem5 结果与真实硬件之间仍有落差
+
+这是 architecture 论文常见问题，不是这篇独有的缺点。
+
+但对 CXL 而言，真实部署时还会叠加：
+
+- 控制器实现细节
+- 链路拥塞
+- NUMA 行为
+- 固件/驱动软件栈
+- 多租户云环境干扰
+
+这些可能影响最终收益。
+
+### 4. 安全边界仍继承自现有 TEE/CXL IDE 假设
+
+本文并没有试图解决：
+
+- side-channel
+- DoS
+- 更强对手模型下的攻击
+
+所以它更准确的定位是：
+
+> **在既有 TEE + CXL IDE 安全框架内，提高 secure CXL 的效率。**
+
+而不是重新定义 secure memory 的全部安全边界。
+
+## 和相关工作的关系
+
+这篇论文和已有工作最关键的差异在于两点：
+
+### 它不是单纯比较 XTS 与 CTR
+
+很多工作会问：
+- XTS 好还是 CTR 好？
+
+这篇的答案是：
+- **看页的访问行为，不能一刀切。**
+
+### 它不是只优化 counter structure
+
+很多 memory encryption 论文会重点优化：
+- counter cache
+- integrity tree
+- split counter layout
+
+AIORE 更进一步，把：
+- encryption mode selection
+- re-encryption scheduling
+- memory-side offload
+
+一起纳入设计。
+
+## 对研究者有什么启发？
+
+如果你做的方向包括：
+
+- CXL / memory expansion
+- TEE / confidential computing
+- architecture-security co-design
+- near-memory / memory-side compute
+
+这篇论文都值得认真读。
+
+我觉得最值得借鉴的不是某个具体公式，而是它的方法论：
+
+### 启发 1：性能瓶颈常常来自“机制交界面”
+
+AIORE 优化的不是单个模块，而是：
+
+- TEE memory encryption
+- CXL link security
+- counter metadata
+- page migration / re-encryption
+
+这些机制交会的地方。
+
+### 启发 2：冷热分化是 systems 优化的常见抓手
+
+“热页/冷页不同处理”其实是系统设计中非常有生命力的套路。
+
+AIORE 把它用到 secure CXL 上，效果很好。
+
+### 启发 3：offload 不只是把计算移走，而是把关键路径缩短
+
+真正重要的不是“工作移到 memory node”，而是：
+
+- host 关键路径上少做了什么
+- 链路往返减少了什么
+- 程序感知延迟下降了什么
+
+## 我的评价
+
+这是一篇很典型、也很扎实的 **architecture + security co-design** 论文。
+
+我对它的总体评价是：
+
+- **问题选得准**：secure CXL 确实是未来重要问题
+- **观察很到位**：XTS 与 CTR 各有适用场景
+- **方案设计有层次**：自适应选择 + 增量重加密 + 卸载重加密
+- **结果也够硬**：把安全开销压到接近 insecure baseline
+
+如果说不足，我认为主要还是：
+
+- 机制复杂度较高
+- 对真实系统落地还需要进一步验证
+
+但从论文质量和研究价值看，这篇是很值得收藏的。
+
+## 适合继续追的问题
+
+如果沿着这篇继续做研究，我会关注：
+
+1. **更动态的页分类策略**
+   - 是否能更细粒度、更低开销地做在线冷热判断？
+
+2. **和 page placement / migration 联合优化**
+   - 安全模式选择能否与 CXL page placement 一起做？
+
+3. **多租户与 QoS 场景**
+   - 多 VM / 多 tenant 共享 CXL memory 时是否仍稳定？
+
+4. **与完整性树/新型 metadata 组织结合**
+   - 是否还能进一步减少 metadata traffic？
+
+5. **真实硬件原型验证**
+   - 尤其是 memory-side offload 的工程成本与收益比
+
+## 适合谁读？
+
+推荐给：
+
+- 做 **CXL / disaggregated memory** 的研究者
+- 做 **confidential computing / TEE** 的研究者
+- 做 **系统结构与安全协同优化** 的研究者
+
+如果你只想快速知道这篇 paper 的核心结论，那么一句话就是：
+
+> **AIORE 通过按页自适应混用 CTR 和 XTS，并把重加密做成增量式、可卸载的后台工作，把 secure CXL memory 的开销显著压低到了接近 insecure baseline。**

docs/papers/index.md

@@ -2,6 +2,11 @@
 
 这里汇总结构化的论文阅读笔记。
 
+## 已发布
+
+- [Efficient Security Support for CXL Memory through Adaptive Incremental Offloaded (Re-)Encryption](aiore-cxl-security.md)
+- [Attention Is All You Need](attention-is-all-you-need.md)
+
 ## 建议模板
 
 每篇论文尽量包含以下部分：