解决的问题：

现代的云要求用户相信服务提供商的整体软件栈。这个假设大得有些不合理。为了保护用户的私有数据，提供公平对等的可信执行环境，除了VPC等方案之外，微软团队提出了基于硬件的隔离方案。

贡献点：

第一个借助硬件能力对应用程序进行保护的工作：
1. 定义了什么是”受防护的执行环境（Shielded Execution, SE）”，一种反向沙盒。为了满足这个目标，需要什么样的硬件条件；并阐明如何借助已有的SGX实现这个目标。
2. 设计并实现了一个系统（Haven），给应用程序提供SE。这种容器设计融合了各种机制，包括私有调度策略、自主内存管理、加密文件系统，彻底杜绝宿主系统对容器内应用程序的窥测。（说明了工作量）
3. 针对常用的服务器软件SQL和Apache分别进行了性能测试，证明该系统的可用性。
4. 提出可以优化的方案，需要硬件更进一步的支持（指明未来TPM硬件的发展方向）。

模型假设：

攻击者拥有云设备的硬件访问权，对内存和I/O可以任意控制（如内存探测、流量劫持）；
攻击者拥有宿主系统整体软件栈的控制权（包括OS、Hypervisor、固件、中间件），可以随时中断系统任务、修改隔离边界的输入；
CPU没有生产缺陷，可以保证SGX的可用性；
不考虑旁路攻击。

目标：

容器内部负责对数据的保密性和完整性进行检查；
用户使用Haven系统时无需修改其二进制程序。

设计细节：

picoprocess限制了应用程序可以使用的ABI接口，主要用于保护host。
LibOS的设计实际是用户态内核，调用picoprocess提供的ABI接口，提供Windows8的系统接口。
本文称这是一种双向沙盒，具有同虚拟化媲美的安全特性（强隔离），但享有容器级别的低性能损失。

局限性：

SGX对Guest OS的保护还不够，会暴露异常和缺页处理，甚至Cache等旁路也会被利用。
Host可以进行时钟欺骗，需要enclave内的系统自行设计一个周期计数器用作时钟源。
无法对抗”回滚攻击”。（说明，假设系统要求最多3次身份认证，恶意主机可以借助不断使用早先的镜像来暴力破解其验证信息，可参考Defending against VM Rollback Attack）。
SGX的内存管理不支持对镜像的按需加载，在启动时引入过多时空开销。

个人评价：

微软14年的假设在15年被证明出仍有问题。宿主软件可借助高并发时的控制流劫持窃取enclave的数据。
作为操作系统起家的微软，自然对操作系统的设计了然于胸。在SGX提供的enclave创造一个用户态内核以及运行时，不是一件难事。方法并不巧妙，主要是工作量大，不论是论文调研（64篇引用）还是系统实现（35061LoC）。描述思路也很清晰，需要读者较多的基础知识。为14年OSDI的最佳论文。

重新审视Haven工作

为什么Haven决定使用如此硕大的LibOS，一方面希望在Enclave内提供Windows的完整支持，保证原生二进制的顺利迁移；另一方面是希望尽量避免OS的 Iago Attack。

Iago攻击举例：

系统malloc()返回地址是用户程序的栈空间，让用户自己破坏栈数据和返回地址；
调度器允许用户进程的两个线程产生竞争，破坏其同步逻辑；
系统返回诡异值，导致用户程序的数组索引地址非法；
文件系统返回EROFS，表示为不可修改。

针对以上每种攻击，Haven的做法是，尽量不依赖底层不可信的OS，自己实现：

自己进行内存管理，shield模块负责返回可用的内存页，检查访问权限；
自己实现线程调度器；
对所有不可信OS的返回值做sanity检查；
私有文件系统：加密VHD。

微软Haven的这些设计直接影响了英特尔SGX v2的硬件设计：

允许Enclave在运行时增减页了（EADD），从而支持动态内存分配；
支持在Enclave内注册异常服务程序，响应缺页中断；
在Enclave内支持TLS，允许多线程模型。
提供RDTSC/RDTSCP指令，方便实用性和性能评测。

在OSDI大会演讲的最后一个问题，有人提到，VT-x当初不支持嵌套页表，需要软件自己模拟和管理；而SGX的引入产生了更加严格的模型，SGX是不是不支持多进程地址空间。答曰：是的。只能在用户态的一个进程内部使用。不然这个模型可能会很复杂，会发生多个安全边界的切换。不过未来很有可能还是会实现（long-term）。现在最好把它视为一个难题（因为安全模型尚不明确）。