解决问题：

云服务提供商提供的基础软件（系统栈）对于云用户而言是不可以信的。
我们不仅要保护用户的代码，还要保护用户代码和I/O设备通信的渠道。
当前SGX仅支持ME(Management Engine)，建立的可信路径称为Protected Audio Video Path (PAVP)。
本工作就是要建立通用的可信通道（Trusted Paths）。

贡献点：

第一个在SGX上实现可信路径的工作；
无需多余硬件即可验证可信路径；
给出新颖的零开销、非交互型密钥传输方案。

假设：

攻击者拥有系统所有权；
攻击者掌握所有软件的配置信息；
能任意加载用户程序和驱动并运行，创建新的进程通信实例；
可信用户程序、安全驱动和Hypervisor（形式化验证过的seL4）都是正确实现的；
硬件（CPU、电路、外围设备）工作正常；
不考虑物理设备攻击；
DoS攻击和旁路攻击不考虑。

_后两条是因为第一条假设太强，物理设备已不受控制。 _

挑战：

Hypervisor Attestation：如何衔接SGX的Enclave和Hypervisor的安全域。
如何在可信的Hypervisor和不可信的OS之间切换时，保护Enclave。

局限：

驱动代码的复杂性：以USB协议栈为例，由于其代码的复杂度高，因此需要手工识别出和安全具体相关的代码放到保护域中。
旁路攻击：SGX的分页容易泄露地址信息，同时Cache和DRAM也都容易被时序攻击（timing attacks）。

设计：

SGXIO由两部分组成：一个叫Trusted Stack，另一个是跑不可信OS的VM。Trusted Stack的具体又分为：可靠的HV（VMM）、可信的启动模块TB以及若干个安全I/O驱动程序。这相当于是一个全新的系统架构，和vmOS、QubesOS的思路很像。
可信路径会在应用程序和设备驱动间架设一条安全桥梁。整体涉及的内存不应由OS（假设为不可信）管理，同时避免DMA的访问（恶意攻击）。
同时文章提出，安全I/O设备驱动应该和其他在内核中的驱动隔离开来。该工作有点像16年《Isolating Operating System components with Intel SGX》一样，想保护内核中的组件。
1. 如何隔离 untrusted OS：将其放置于VM中，由Hypervisor来调度。
2. 防范DMA攻击：DMA中断产生时，会绕过任何MMU/MPU保护机制，直接访问物理内存数据，破坏数据的保密性，可能还会破坏数据完整性（个人思考：中断处理出现问题，导致时序逻辑错误）。本文指出：硬件SGX保证DMA无法访问Enclave中的内存；同时现代芯片上的IOMMU（Intel VT-d）也能对DMA可访问的内存区域进行限制。可以交由Hypervisor来配置IOMMU。
3. 路径隔离：密码学加密的对象不仅有应用程序和设备驱动，还有驱动和设备的交互。文中提到的驱动和设备的绑定非常像Exokernel中的Secure Binding，可能思想就是借鉴过来的。
4. 设备隔离：恶意系统可以借助对设备驱动的错误配置，使得MMIO映射的内存有所交集，来破坏受保护驱动的完整性。本文借鉴了部分其他工作提出的策略（policies），由Hypervisor来检查并防范此类错误。

VMM设计：

作用：
1. 在VM中运行不可信的OS；
2. 装载驱动程序；
3. 绑定设备。
隔离要求：
1. Trusted Stack彼此隔离；
2. 负责搭建设备和驱动的绑定通道（可信路径）；
3. 设备驱动间彼此隔离。
  - 对此，本文推荐经过形式化验证的seL4，以及CMU和Google一起研究的工作XMHF，即Design, Implementation and Verification of aneXtensible and Modular Hypervisor Framework（IEEE Symposium on Security and Privacy 2013）。

驱动程序设计：

多路复用：驱动要负责对绑定域的多路转发；
可移植性：系统组件间借助虚拟设备通信（内存模拟），提高对现有商用系统的可移植性。但高吞度量需求的驱动除外。

应用程序设计：

可信路径的通信依赖的是加密信道：密码学，Diffie-Hellman密钥交换，本地验证。
编程模型：不可信的系统负责内存管理、进程管理和Enclave调度（这里作者对SGX的安全性做了相当大的依赖，也相当于是假设之一）。

个人体会：

本文为TU Graz的IoT安全项目的展示成果之一。
不得不说，这是我近期读到的一篇好文章（主观看法）。对我个人知识拓展和思考还是挺有帮助的。
本工作对全系统进行了重新思考和设计，这种做法个人还是比较欣赏的。一味地为过去犯下的错误买单，固然是一种继续生存下去的思路，但是“劣币驱逐良币”实在不可取。让好的设计脱颖而出，优胜劣汰，更有利于整个生态圈的发展。对于淘汰的代价，我们主要考虑更迭新旧设备、新旧技术带来的资金成本、培训成本等。长期演进来看，过时技术终将会被取代。

第二次阅读回顾总结

简要回顾：

从本质上来说，SGXIO的安全I/O是通过可信Hypervisor引入的。
这个Hypervisor负责隔绝内存（借助对MMU的配置）、绑定驱动程序、隔绝驱动代码。
而驱动代码是在Enclave中执行的。为此本文引入了Enclave之间的相互通信，在这里是App Enclave和Driver Enclave的通信渠道（可信路径）。

一个根本问题是，我们如何保证Hypervisor没有被Compromise呢？这就是为什么架构中要设计TB(trusted boot)的原因。这个想法和TPM中用到的安全启动（或称为“可信启动”）的思路一模一样。

总结：

这是我看到的第一个将SGX和虚拟化结合的好工作。
为此，本文的驱动称为User Driver，这是一个非常好的切入点，也是很好的工作尝试。但个人认为，本文提出的方案还只能是过渡性的，我们可以提出新的一篇文案《Did SGXIO do well enough?》。
建议阅读国外Adrian Colyer对本文做的阅读笔记： https://blog.acolyer.org/2017/04/07/sgxio-generic-trusted-io-path-for-intel-sgx

Sgxio

解决问题：

贡献点：

假设：

挑战：

局限：

相关工作：

设计：

VMM设计：

驱动程序设计：

应用程序设计：

个人体会：

第二次阅读回顾总结

简要回顾：

总结：