Intel SGX入门（三）——SGX保护框架、软件层改进篇

其实SGX应用也包括，SGX保护框架，SGX软件层改进，单独拎出来

先说说SGX保护框架（SGX Shield Framework）

Haven(OSDI’14) 微软

SGX已经硬件实现了，但是，很多老的APP并没有用上SGX。并且SGX的代码开发和原来不太一样了，得把代码划分成Enclave内外两个部分。那么意味着老的APP很难用上SGX了，因为不是所有人都愿意花力气把原来的APP移到SGX上。那么怎么把老的APP放到SGX上呢软提供了Haven方案。

Haven架构如图：Enclave（APP->LibOS->Shield模块）->uRTS->OS的栈结构（LibOS在这里的作用相当于自己租的卧室内搭建一个小厨房等设施，尽可能的不与外界打交道，尽可能不用外面的大厨房）。这样子，整个APP都是Enclave内部的，APP和LibOS打交道就行，LibOS或者直接满足APP的需求，或者向外让Host OS完成具体需求。总之APP就不用改代码了。

如上所说，Enclave仍然会有小部分的比如系统调用需要与外界接触（好比小厨房的电、气还是得走总的房子的电、气）。此外，SGX还有一些细节限制：EPC大小有限（比如256M），页错误等异常仍然由外界OS来处理，还有很多硬件指令Enclave内不能调用……。

上述这种有Enclave与外界接触的情况，就有被攻击的风险，只要SGX与外部有啥共享的机制，就可能被攻击，SGX侧信道很多就是基于共享机制（后面会讲）。

LibOS和库直接塞入SGX会导致TCB过大的问题，小结处会讨论Haven和他的小伙伴们，进行一个横向对比。

SCONE(OSDI’16)

SCONE的初衷应该就是想让容器能够由SGX进行安全加固。同时最好就是容器可以直接在Enclave中跑，不需要修改，因此它提出如上图架构。

它发现其实并不需要整个LibOS都移进来也能完成对容器的支撑，因此将LibOS概念移除，移除了包含网络和文件Shield层、多线程（不支持多进程）、MUSL等。

另外它还实现了一套异步系统调用的机制（可能是处于安全考虑前尚不清楚）。

可以看到SCONE的架构和Haven就有一些区别了，SCONE的TCB相对Haven更小（Haven的LibOS代码、库的代码量很大），同时效率也得到了提升。不过SCONE架构中，Enclave与外界的接口更多了，因为SCONE里面删除了很多东西，意味着这些东西都得找HostOS提供。

Ryoan(OSDI’16)

这个当时看懂的有点少。大概是说作者认为SGX原来的机制不够安全（的确存在非常多SGX攻击），于是作者在Enclave再防一个沙箱来执行代码。这个沙箱在SGX基础增强安全性，并且提供了一些软件侧信道的防御手段（比如与外界输入输出加密、系统调用的模拟、检查点）。

Panoply(NDSS’17)

为了让传统程序能够不改代码的移植到Enclave中，Haven、Graphene-SGX中将LibOS移入Enclave，并仿真地提供系统调用、线程、事件处理、Forking等功能（最终会转换到Host OS的系统调用），但是也会导致TCB太大（主要是库比较大），效率低等。SCONE、Ryoan使用容器、沙箱来向上支撑传统程序，但是如Fork/Exec等功能无法仿真（因为本身并不是像Haven那样整个LibOS都搬进SGX），这种选择一般来说TCB很小（主要是库不在Enclave内），效率个人猜测会高于Haven这种。

Panoply另辟蹊径，或者说上述两种综合一下，将Libssl等库（Haven中将其放在Enclave中）专门用一个Enclave来执行，目的是为了实现复用（不需要每个Enclave保留一份，降低TCB），然后想要调库，就向库Enclave发出申请，库Enclave返回结果。可以放心的是Enclave间的调用(通信)走的是加密信道，同时彼此实现相互认证。

另一个点和SCONE还是有点像，就是Enclave留一个Shim来执行系统调用来实现各种丰富的功能，具体实现放到不可信的Host OS中。

Panoply这种库Enclave的想法一定程度实现代码复用，降低TCB，不过应该会导致面向HostOS的接口变多，Haven中Enclave与HostOS的接口只有20+。

总之，Haven、Panoply都能帮助传统程序不改代码移植，间接提供系统调用、线程等功能，区别在于Haven通过LibOS实现了很多OS功能，Panoply留了个接口给Enclave，让有些功能由HostOS来做。Panoply库Enclave的概念挺新颖，用来实现代码复用。

Panoply的库Enclave思想其实和RPC有点接近。

Graphene-SGX(ATC’17)

个人觉得这个和Haven类似，或者说Haven架构的Linux下实现，Haven是Win下的实现。Haven应该是20个固定系统调用，Graphene-SGX是28个固定系统调用（18个系统调用会有检查）。除了向上支持Linux传统软件，后来还能够支持容器（这一点可能挺有意思），未来将支持EDMM（Enclave Dynamic Memory Management）。

EDMM这是个SGX v2新增的机制，背后由新增的硬件指令实现，目的是说SGX v1时候，我一开始声明Enclave多大，那加载起来的Enclave就那么大，大小不能再改了，SGX v2增加EDMM，让Enclave可以建立以后，也就是运行的时候动态申请新的EPC页，满足Enclave大小的变化。

SGX软件层改进

Eleos(EuroSys’17)

文章首先讲了SGX带来的开销。第一点，SGX带来的直接开销：进出Enclave要3300/3800周期，而系统调用也就250周期；LLC Miss开销是非Miss下的5.6~9.5倍；EPC页换入换出硬盘Swap区需要40,000周期。第二点，SGX带来的间接开销：由于安全期间进出Enclave会刷新TLB（LLC我忘了是否刷新，L1在Intel的微码补丁之前是不刷新，Foreshadow的出现导致Intel也做L1的刷新了。），LLC污染会造成2倍延迟、TLB污染可能造成6倍延迟。

上述实验结果主要说明了进出Enclave开销大。无论是正常的Enclave退出还是页错误之类的问题导致Enclave退出（AEX）都会带来很大的延迟，因此通过非Enclave退出的方式——RPC，来替换Enclave退出的功能；而关于页错误则通过一个安全的用户空间页表机制SUVM（见下图，大概是说软件实现了虚实地址翻译工作，Enclave页表也放在Enclave内部，原来都是统一用的内核页表，如果发现有页被换出到普通内存，那么就Enclave内部仿真一个错误处理机制，将换出到普通内存的EPC页再放回EPC中，并完成完整性度量。也就是说Enclave内部做了一个软件的用户态页表机制，将硬件页表机制架空。）来避免Enclave退出。相比与改进之前的SGX，Eleos RPC增加23%带宽，Eleos RPC+SUVM增加50%带宽，可喜可贺。

这里让我联想到了SGX的Switchless模式，Switchless模式大概是说我先专门弄一个线程出来让他们直接跑在Enclave环境，然后把他们称为ECALL工人线程，工人线程自然是用来干活的。现在我们运行APP，然后APP调用一个ECALL函数，那么ECALL任务放到任务池，并通知（通过发送Signal）之前一直空转的ECALL工人起床干活了，然后ECALL工人将ECALL任务跑起来。

Eleos和Swithless的区别我还没细究。

CoSMIX(ATC’19)

以前，SQLite的fast_read_db之类的函数依赖内存映射文件（mmap），这会通过调用OS错误句柄将内容从硬盘带到内存，但是OS不可信，因此OS的错误处理也不可信。如果使用请求页面指令，这个指令的功能和流程定死了，不灵活。如果使用用户自定义处理句柄，由于会通过OS来调用Enclave内部用户自定义句柄，流程很长，效率低（而且个人认为给了OS攻击的可能性）。

CoSMIX在Enclave内部仿真了页表机制来完成虚实地址转换，目标虚拟地址转变成不可信的物理地址，然后将内容取回EPC，该页的数据同时会保留到缓存（Foreshadow中说，可以利用这个缓存造成攻击）中，可以加快访问“内存”（怎么听着很像SUVM）。

总的感觉是将页表机制移入Enclave，通过LibOS来实现，并完成加密内存的解密等操作。会想起Sectum将页表移入Enclave的做法。

这也体现了有些SGX漏洞就是由于Enclave部分功能需要通过OS来完成（比如页表机制）产生泄露。通过LibOS实现部分机制可以缓解此类漏洞。

Rust-SGX SDK(CCS’19)百度

Rust语言号称是一个能够实现内存安全（不会出现指针越界之类由于指针这个东西导致的问题）的语言，SGX又是个能抵抗特权攻击CPU特性，两者优势互补，就是Rust-SGX了。不过当然不只是这样，除了能够用上Rust语言的内存安全性和SGX提供的安全内存，Rust-SGX还让开发者多了一个使用Rust语言的机会。

看上图，Rust-SGX下，Enclave可以使用Rust语言书写，然后会调用Rust库来使用SGX，Rust库通过Rust-to-C FFI调用C语言的SGX SDK。

Rust-SGX有一个近亲，Fortanix的Rust EDP SDK方案，它将SGX SDK也用Rust重写，这可以将Rust的内存安全特性实现地更充分。但是百度的Rust-SGX SDK能够避免SGX SDK的上游更新导致后续又要用Rust重写，同时C语言的SGX SDK效率比Rust更高（安全性降低）。

百度的Rust-SGX能够保证除SGX SDK以外的其他部件都是安全的，不会引入新的漏洞，且经过形式化验证。

Fortanix Rust EDP SDK

以本人浅见发表自身对Intel SGX调研情况，不能保证某些细节均正确，不定期进行内容补充、修正。

如有高见，欢迎讨论！

本文为原创文章。转载请注明出处，仅供学习，禁止用于出版、发表文章等用途，禁止用于商业用途。侵权者必究。

来源：小气球归来