题目： PANOPLY: Low-TCB Linux Applications with SGX Enclaves

作者： Shweta Shinde, Dat Le Tien, Shruti Tople, Prateek Saxena

单位： National University of Singapore and University of Oslo

出版： NDSS 2017

解决问题：

1. SGX无法让被保护应用进行系统调用，缺少抽象。
2. 针对商用Linux系统，将SGX原生抽象和OS丰富抽象进行衔接，提供micro-container，一样具备POSIX抽象。
3. 在Enclave交互间提供强完整性保护。
4. 相比Graphene，TCB数量级减少两位数，但还有20KLOC。

目标：

• 特权分离
• 基于隔离

挑战：

1. 提供丰富的系统抽象（这点和BROWSIX很像）；
2. 在enclave间提供安全交互渠道；
3. 很小的TCB（这是本工作相比于之前工作的最大区别，也是本工作的点题处）。

贡献点：

1. 对SGX SDK进行了丰富的POSIX抽象补充，第一个允许用户在Enclave内部启用任意多线程、多进程和事件机制（event）的系统；
   1. 对fork-exec语义进行了扩充；
   2. 支持pthread同步语义接口；
   3. 能对跨Enclave的IFC进行静态检查。
2. 对4款应用进行移植，确定可用性。平均只要修改900行代码；
3. 完成评估：比之前工作（Graphene-SGX）在TCB上少两个量级，性能低5-10%。

工作量：

• 实现的OS抽象：见原文TABLE II。

• TCB代码量：见原文TABLE V。

• 实验结果（Microbenchmark）：见原文TABLE III。

相关工作比较：

见原文TABLE IV。

1. 和SCONE的比较：
   1. SCONE提供系统调用，PANOPLY提供POSIX API；
   2. PANOPLY的TCB不包含libc库；
   3. PANOPLY使用同步系统调用，性能逊色于SCONE；
   4. PANOPLY使用按需线程模型，扩展性好；而SCONE使用m:n线程模型（和多对多模型类似）；
   5. PANOPLY从设计上就支持多进程模型，因此对fork-exec语义支持较好，同时提供inter-enclave通信（这一点值得借鉴，本文考虑了认证加密、重放攻击以及silent-drop拒绝服务攻击）。从这点上看，SCONE的单容器进程支持是PANOPLY的子集。
2. 和Ryoan比较：
   1. Ryoan针对分布式环境提供沙盒，enclave间彼此假设互不可信（考虑重放攻击）；而PANOPLY假设同一个应用内的各个enclave互信，因此TCB相对包含更多。笔者思考：对于分布式，FlowTap对于互不可信的分布式执行环境也做了相同的假设，只不过工作是针对网络通信的；
   2. Ryoan的系统调用、缓冲区以及所有文件I/O操作都是在enclave内存区完成的（syscall有待确认）。

补充说明：

1. 为了提供fork语义，PANOPLY的LibOS实现多线程支持，在外部设置了线程管理器。
2. 同VC3一样，进行了编译器扩展。借助插桩，保证一个应用的不同Micron实例间的通信控制流、数据流完整性。

个人体会：

1. 尽管别的工作提供的Library OS组成TCB很大，但都是按需链接。可能不会用到那么多代码。但在提供相同能力下减小TCB代码量，是正确思路。
2. 我们的目标也是尽可能最小化TCB，但不是为了提供系统抽象，而是提供硬件级别的虚拟化能力。
3. PANOPLY的目标是小TCB，文中坦言，以牺牲性能为代价。其设计哲学为：代理而非模拟delegate-rather-than-emulate。本意是很多操作还是转发给内核完成，这里的切换开销会比较多。Dune的内核模块也是这么完成任务的：libdune基本是内存管理抽象，别的服务交给内核来完成。
4. 评估模块的表格非常值得学习。
5. 本文的思考和工作都很好地结合了现有工作的不足，而且工作量不低。其设计与实现十分值得借鉴。值得回顾。
6. 本工作主页：https://shwetasshinde24.github.io/Panoply/，开源。

---

• Previous
  Os Outlook
• Next
  Hotcalls