Eleos

Posted by Maxul's Sketch Notes on June 25, 2017

题目: Eleos: ExitLess OS Services for SGX Enclaves

作者: Meni Orenbach, Pavel Lifshits, Marina Minkin, Mark Silberstein

单位: Technion - Israel Institute of Technology

出版: EuroSys 2017

要解决的问题、面临的挑战:

  • 摘要:对于SGX保护的应用,如果应用属于I/O密集型,则进出Enclave的开销很大。
  • 动机:分布式机器学习有一个中心参数服务器,存储共享的模型参数,讨论该计算模式下的性能开销:9倍延迟,分析得知性能瓶颈主要在系统调用上,为此得到分布式理想最佳配置,并有了目标:减少Enclave内系统调用次数。文章作者将系统调用开销分为两部分:一个是进出Enclave调用指令带来的直接开销(指令周期),另一个是系统调用切换时Cache、TLB失效带来的额外开销。这部分其实是__作者将自己如何剖析性能的过程描述为论文,体现自己工作量的一种方式__。另一个开销在于EPC缺页中断。由此引出作者要解决的问题。目的明确,我们很容易看出,减小系统调用次数和用户态内存管理是比较直接的思路
  • 背景:1) 由于不能再Enclave内直接调用内核服务,因此导致了异步的页缺失和信号管理。**这层_过渡_是必须要解决的。2) processor reserved memory (PRM) 大小限制在128MB以内,因此在Enclave内要使用虚拟内存的话,必须引入自己的按需分页子系统。

    初衷和意义:

    The main observation that drives our work is that enclave exits are an impediment to application performance.

快问快答:

问:摘要中提到的Secure User-managed Virtual Memory (SUVM),是不是就是SGX和Dune工作的结合?

答:不是。本文的SUVM为纯软件算法,缺乏硬件加速。其思路借鉴自:ActivePointers: A Case for Software Address Translation on GPUs (ISCA 2016)。

问:如何减少系统调用次数?和异步思路有何差别?

答:RPC。殊途同归,都是Enclave外部的线程(内核线程或用户态线程)代理。异步方案见SCONE图6。

问:效果如何?

答:读写速率提高,高速缓存清理次数降低。

相关工作:

本文团队声称,并没有调研到任何有过用户态、减少系统调用型的虚拟内存管理的工作。言下之意,自己是第一个。

  • HavenGraphene以及Panoply是在不修改二进制程序的基础上,将其放置在Enclave中的Library OS工作。本文工作是它们的一个互补,旨在提高效率。
  • VC3Ryoan都是在分布式情况下使用SGX实现的隐私保护工作,都涉及大量I/O操作和内存管理。作者认为自己的工作可以加速他们的方案。
  • SCONE的工作相比,作者认为自己详细地分析性能问题,对 exits (AEX) 进行了大量测验,这个工作量不可忽视。而且还对内存管理进行了优化,有点在SCONE基础上加入了包含VM子系统的LibOS的意味。 RPC的思路来自FlexSC的异步系统调用。问:那么FlexSC的工作和SCONE的异步有何差别???
  • 本文的很多思路借鉴自其它工作。如ELI(ASPLOS 2012):软件思路,减少宿主对中断的过多接管,让虚拟机获取原生性能。具体见原文图1。

贡献点:

  • 系统调用时,降低高速缓存污染发生的次数;
  • 用户自定义分页;这一点Dune的工作可以借鉴。
  • 低开销地址转换;
  • 多实例下低缺页次数,以及页面优化策略。

后者主要在谈自己算法的优势。

当前工作的不足之处:

SUVM当前实现方案的局限性:

  1. 空间开销大:指针构成的元数据占用了地址空间;
  2. 元数据没有特殊缓存策略,容易失效(due to eviction);
  3. 虚拟内存管理的外存储直接访问_和_不对其的序列化问题
  4. EPC++(enclave page cache) resizing;
  5. SUVM缺乏对代码缓存失效时的管理。

设计与实现中吸引我的地方:

  1. 减少系统调用次数:使用RPC机制;
  2. 缺页代价太高?那就自我维护:SUVM。

性能和小TCB是两个常见目标。 除此之外,由于引入UVM,那么UVM对开发者的友好也成了目标:好用易调。 最后是安全,不要给SGX增加攻击面。

  • 设计图见原文图3。
    1. RPC,和异步系统调用思路很像。内部维护多线程做代理。##具体细节需要再补充##。
    2. SUVM,乍一看主要是软件层面的优化算法,和Dune相比还是有很大劣势。因此内存管理的性能空间依然有很大空间。 SUVM地址翻译

思考与总结:

  • SGX对进出Enclave的数据是进行加解密的,这部分开销会随着出入次数的减少而避免。
  • 用性能剖析工具分析得知瓶颈在哪再做优化,这是本文工作的动因。
  • 本文提到“反向沙盒”的说法,可见还是受14年Haven的影响。
  • 这个方案没有提供LibOS或LibC,因此需要对应用程序做些微调,如memcached的内存分配器。
  • 本文属于高性能(HPC)领域。该工作是主要目标是__提高性能__。工作量主要在剖析性能和算法优化上面。从本文相关工作可看出,有大量的思路是借鉴自其它优秀工作的。这也给我们很好的科研思路:结合优秀相关工作方案,解决手头想解决的有价值的问题。

可参考资料:

https://en.wikipedia.org/wiki/Memory_footprint https://www.systor.org/2017/slides/eleos_systor17.pdf