（第3部分）Memory Wall：为什么你的 Enclave 运行缓慢以及如何修复

Source: Dev.to

内存墙

在第 2 部分我们已经让 Enclave 运行起来了，但一旦超越 “Hello World”（例如图像处理算法或小型数据库），就会迅速碰到一个字面意义上的、硬件层面的砖墙：内存墙。

什么是内存墙

• 在传统应用中，你把 RAM 当作无限的海洋——malloc 一个 gigabyte，操作系统通常会说 “可以”。
• 在 SGX 中，CPU 为 Enclave 保留了一块特殊的、隔离的 RAM 区域，称为 Enclave Page Cache (EPC)。
  • 在较旧的机器（Ice Lake 之前）中，EPC 的上限是 128 MiB。
  • 扣除管理开销后，实际可用于代码、栈和堆的只有大约 90 MiB。

“90 MiB？我的 Node.js 应用刚启动就用了这么多！”
正是如此。SGX 旨在实现 机密计算，而不是 懒惰计算。

SGX 中的分页

如果超过 EPC 限制，硬件不会直接崩溃——它会开始 分页：

1. Enclave 页面被加密后移到普通 RAM。
2. 需要时再拉回，解密并验证完整性哈希。

这种 SGX 分页比标准操作系统分页慢 10×–100×，因为始终伴随加解密开销。跨过 128 MiB 阈值会导致性能出现巨大的悬崖式下降。

在 90 MiB 盒子里生存

内存管理规则

1. 一次分配，永久复用——malloc/free 开销大且会导致内存碎片。如果需要 1 MiB 缓冲区，请在启动时分配并一直复用。
2. 绝不在 Enclave 中加载大数据集——把大文件（例如 500 MiB 数据库）放在不可信的 RAM 中。分块拉取数据（例如 64 KiB），处理后通过 OCALL 返回结果。把 Enclave 当作 处理工厂，而不是 存储仓库。
3. 调优 Enclave 配置——默认的 Enclave.config.xml 参数可能会严重限制性能。

  0
  0
  0x4000000   
  0x40000   
  0x1000000 

Max 的黄金法则

将堆大小设置在机器 EPC 硬件上限以下，以避免分页陷阱。

练习：感受痛苦

为 SGX 编码就像在 64 KB RAM 的 1980 年代游戏机上编程。
这迫使你思考数据局部性、缓冲区管理以及开销。在开发者们把 RAM 当作解决问题的万金油的时代，能够把安全的机器学习模型塞进 90 MiB，就像是安全行业的独角兽。

接下来是什么？

我们已经掌握了内存。下一个挑战是证明我们的 Enclave 实际运行在真实硬件上且未被篡改。

即将推出：远程认证

远程认证是 信任的数字握手，它让你能够在不信任远端的情况下，通过互联网证明你的 Enclave 身份。