Confidential Serverless Made Efficient with Plug-In Enclaves
问题：在SGX飞地中运行现有的无服务器应用程序，并观察到性能下降可能高达5.6×甚至422.6×
观察：我们的调查发现这些减速与架构功能有关，主要来自页面安全区初始化。
方案：使用新的基元-Plug-In Enclaves扩展 SGX，该飞地可以映射到现有飞地中，以便在函数之间重用经过验证的通用状态。通过重新映射插件安全区，安全区就地处理，避免在函数链中移动昂贵的数据。
结果：将安全区函数延迟降低了94.74-99.57%，自动伸缩吞吐量提高了19-179×。
1 介绍
无服务器计算：功能即服务（FaaS）。无服务器函数是事件驱动的，通过用户请求或其他函数的调用（以链方式）。54% 的无服务器应用程序仅包含一个函数，50% 的函数执行时间不到 1 秒；因此，无服务器应用程序对服务延迟极其敏感。
TEE被认为是实现实用的隐私保护无服务器应用程序的有前途的技术。
但是，现有的 TEE 设计无法很好地适应无服务器工作负载。
观察实验：将五个现实世界的隐私关键型无服务器工作负载（表 I）移植到内部飞区库操作系统中（类似于 Graphene-SGX ，但支持 SGX2 功能），并观察到性能从 5.6× 显著下降到 422.6×。
观察分析：部分开销源于安全区初始化，硬件安全区创建和证明测量生成都主导着安全区函数的启动，范围从 92.3% 到 99.6%。结果还表明了另一个性能下降因素，它源于函数之间的秘密数据传输，占据了端到端执行时间的 4.4% 到 29.8%；对于长链函数调用，情况会变得更糟。
得出结论：基于隔区无服务器的效率低下的根本原因是当前的 SGX 设计（SGX1 [16] 和 SGX2 [17]）禁用了安全区实例之间的内存共享。这种无共享设计提供了强大的安全保证，但会产生明显的启动延迟，这不适合当今的无服务器计算。
提出方法：PIE提出了一种新的硬件内存原语：共享安全区，可以不可变地映射到不同的隔离飞地中，实现安全共享。利用此硬件原语，基于 enclave 的无服务器平台可以创建两种类型的逻辑安全区：插件安全区和主机安全区。插件安全区完全由共享的飞区区域组成，并且可以容纳非敏感公共环境。主机安全区与当前的 SGX 设计一样，彼此严格隔离，但可以将插件安全区映射到自己的安全区地址空间，以便重用插件安全区加载的内容及其容易生成的度量。主机安全区可以进一步重新映射插件安全区以适应不同的应用程序逻辑，而无需迁移其机密数据。
优势分析：PIE 对效率的关键改进是基于 PIE 的映射是按区域而不是按页面的，主机飞地可以通过轻量级函数调用（5~8 个周期）调用插件飞地的过程。PIE 设计与 SGX1 和 SGX2 语义完全兼容，并重用大多数现有硬件设计，以最大程度地降低其实现复杂性。
实现：PIE对SGX的架构扩展包括一个新的页面类型来指示共享安全区内存，以及两个新的指令EMAP和EUNMAP，用于将插件飞地映射到主机飞地/从主机飞地映射/取消映射。
实验：使用真正支持 SGX 的云计算机，并通过向 EMAP/EUNMAP 操作添加周期精确的延迟来模拟 PIE 指令。对常见的无服务器基础架构进行分区，例如插件飞地中的语言运行时、第三方库和用户函数，以及主机飞地中的机密数据。对于无服务器函数之间的输入/输出数据流，重新映射插件飞地以避免秘密数据移动。
实验结果：PIE可以降低94.74-99.57%的函数启动时延，在函数自动伸缩方面实现19-179×的吞吐量提升，在函数链的数据传输方面实现16.6-20.7×的加速。此外，与当前的 SGX 硬件相比，基于 PIE 的无服务器可以扩展到 4-22× 个安全区实例。
贡献：
- 对无服务器应用，观察找到问题
- 设计优化，并且实现了
- 实验结果也很不错，性能提高很多
2 背景
A. 英特尔软件防护扩展 （SGX）
SGX CPU 将安全区与各种威胁隔离开来，包括 （1） 来自外围设备的直接内存访问 （DMA），（2） 固件、虚拟机管理程序和操作系统等特权系统软件，（3） 与安全区位于同一地址空间中的应用程序，（4） 共享同一托管应用程序的飞地，其中一个的错误或错误不会危及另一个。
安全区访问控制模型。安全区内存被命名为安全区页面缓存 （EPC），EPC 是从 DRAM 的物理连续区域分配的，称为处理器保留内存 （PRM）。一个EPC只属于一个安全区实例。每个安全区实例都有一个唯一的安全区标识符 （EID） 存储在其 SGX 安全区控制结构 （SECS） 中。EPC 页面添加到安全区时，SGX CPU 将此 EPC 页面与名为 EPC 映射 （EPCM） 的元数据相关联。任何软件都无法访问 SECS 和 EPCM 等安全区元数据。
远程和本地证明。
SGX 为远程安全区用户提供了一种硬件机制来证明其身份。在启动过程中，CPU 通过测量每个 EPC 页来计算 SHA-256 哈希，并在受硬件保护的寄存器中最终确定此测量值。对此过程的任何篡改都将导致不同的测量结果。SGX 为同一 CPU 上的安全区提供了另一种有效的本地证明，以相互识别，从而建立相互信任。
B. 无服务器计算
无服务器计算为开发人员提供了编写细粒度、简单和独立函数来组合复杂业务逻辑的优势。函数可以组织成一个链来处理组合。无服务器应用程序是一种事件驱动、面向请求的交互式服务，需要低延迟和高吞吐量。之前的工作已经探索了优化传统云环境中无服务器启动的延迟【“SAND： Towards High-Performance Serverless Computing”， USENIX ATC 2018.】【 “SOCK： Rapid Task Provisioning with Serverless-Optimized Containers”， USENIX ATC 2018.】
3 动机
传统的无服务器平台利用容器或虚拟将功能限制在沙箱中。 他们的威胁模型是保护云免受不受信任的函数执行的影响，并保护函数免受托管租户的影响。
SGX飞地采用反向沙箱，使用硬件来防止云检查或干扰敏感计算。英特尔 SGX 可以保护用户级工作负载免受不受信任环境的影响，适合保护机密的无服务器计算工作负载。
修改函数的入口点以调用在安全区内受保护的函数映像。安全区无服务器实例的工作流如图所示。在将秘密数据发送到安全区进行安全处理之前，用户必须对安全区的环境进行认证。软件初始化包括语言运行时、框架和第三方库的加载时间。功能的执行可能涉及模块/包的动态加载。端到端延迟只包含实心箭头。
A. 定量评价
观察：SGX 安全区保护无服务器功能会在性能方面的问题：
- 启动引入的开销：安全区保护引入了巨大的性能开销，从 5.6×到 422.6× 不等。
- 无服务器自动缩放在安全区中受到保护时如何执行
无服务器计算的一个有前途的功能是云供应商提供与调用速率相对应的实例自动缩放。为了实现高资源利用率，云供应商需要高吞吐量。并发安全区启动会导致极高的 EPC 争用，这甚至会降低其他并发运行的飞地的性能。性能损失可高达8.2×（从原来的39.1秒到322.07秒）。（显示了聊天机器人应用程序，其他无服务器应用程序的延迟分布相似）
- 创建过程的性能分析
- 在SGX1中，安全区创建过程中观察到两个主要性能因素：（1）硬件安全区创建和（2）安全区测量生成。
- （1）CPU 必须使用 EADD 添加具有指定权限和虚拟地址 （VA） 的每个页面。这不仅为目标飞地分配了一个 EPC 页面，还需要更新相应的 EPCM 条目来跟踪此 EPC。EADD 不允许并发添加到同一安全区实例，因为并发模型会增加硬件形式验证的复杂性。
- （2）CPU 需要生成一个基于 SHA-256 的测量，从 ECREATE 初始化，在每个 EPC 页面上初始化到 EADD 和 EEXTEND，并由 EINIT 完成。在此过程中，最昂贵的是EEXTEND，它一次测量5字节的EPC数据块需要5.256K周期。要测量整个EPC页面，总共需要大约88K个周期。
- 在 SGX2 中，安全区允许使用 EAUG → EACCEPT 流动态增加其大小。此流程对于堆密集型工作负载特别有效。对于代码密集型工作负载，它还需要基于软件的测量，并通过 EMODPE（向右扩展“x”）和 EMODPR（限制“w”）将 EPC 页面权限从“rw-”修改为“r-x”。SGX2 不提供任意修改权限的有效方法。EMODPR 需要再有一个 EACCEPT 来验证修改后的 EPC 权限。
- 测量 SGX 无服务器函数链
进行微基准测试，在函数之间改变数据传输大小。这些过程包括 （i） 函数 A 和函数 B 之间的相互证明，（ii） A 和 B 之间的 SSL 握手，（iii） 函数 B 分配一个足够大的堆来容纳机密数据，（iv） 在 A 和 B 之间传输机密数据（双重复制和数据 en/decrypting）。
当数据大小达到 94MB 时，由于昂贵的 EPC 逐出开销，安全区内堆分配的开销超过 SSL 传输。
对于函数之间的小消息传递，与安全区初始化时间（在 100 秒到 12 秒之间变化）相比，秘密传输的成本可以忽略不计（几乎在 29 毫秒内）。对于安全区之间的大型消息传递 （>32MB），数据移动可能是一个瓶颈。
B. 软件优化
- 基于模板的启动。启动涉及多轮加载共享库文件，这不可避免地会产生大量的 EENTER/EEXIT 开销，我们可以构建一个包含所有所需状态的模板映像，并将入口点设置为用户逻辑的第一行，库加载时间可以优化，但硬件安全区创建（在 4.2 秒到 18.2 秒之间）仍然主导着启动延迟。
- 基于重用的启动。传统的启动延迟优化技术是重用现有实例，而不是从头开始创建新实例。这在无服务器中称为热启动，在 enclave 的上下文中，如果最后一个功能的信息泄露或环境损坏危及下一个功能，则必须重置环境；尽管基于重用的启动是一种可行的优化，但并不能解决并发请求超过预热实例时自动缩放的延迟问题，并且不可避免地会占用大量资源。
- 基于共享的启动。共享是高效无服务器计算的关键。不幸的是，这是不可能的，因为SGX硬件设计禁止在飞地之间共享EPC。另一个优化思路是在单个地址空间中运行共享相同语言运行时的多个函数。由于不同的用户相互不信任，因此使用相同的地址空间需要安全区内隔离。先前的研究依赖于基于编译器的检测或基于运行时的限制，实现了基于软件的飞地隔离，将大量代码引入可信计算库（TCB）。基于软件的隔离可能是一个次优的解决方案，因为安全区用户更喜欢只信任硬件来保证安全。
C. 吸取的教训
见解 1：硬件 EADD 和软件哈希实现最快的安全区启动。
对于代码密集型工作负载，SGX2 EAUG并不比SGX1 EADD更好。更有效的方法是使用 SGX1 EADD（强制就地“r-x”权限）和硬件/软件组合测量。英特尔 SGX SDK 使用昂贵的 EEXTEND 来测量 EADD 分配的初始堆页面，这可以在使用前通过软件清零（例如 C 库 calloc（））进行安全优化，从而为 EPC 页面节省 78.8K 个周期。
见解 2：常见的无服务器状态是非敏感的，可以在函数之间共享。
SGX假设属于飞地的所有EPC内容都是私有的。然而，在无服务器计算的上下文中，我们发现函数环境，包括语言运行时、第三方库，甚至函数本身，通常是开源的，因此不包含任何机密。遗憾的是，当前的 SGX 硬件不支持在安全区实例之间共享 EPC;安全区函数必须始终从头开始初始化其语言运行时。通过基于软件的优化，对于 12 MB 安全区，安全区初始化和基于模板的库加载仍会产生 25.800 秒的延迟。
见解 3：在安全区函数之间传输机密数据的成本很高。
安全区功能链涉及丰富的堆分配和昂贵的数据通信。而由于额外的 EPC 逐出，安全区内堆分配对 >94MB 的机密数据产生影响。EPC 逐出涉及分页内容的硬件重新加密，并导致处理器间中断 （IPI） 用于线程间同步。理想的解决方案是在链中的不同功能之间共享相同的秘密数据，以消除这种数据传输费用，即所谓的现场处理。这在当前的 SGX 硬件中也是不可能的。
受安全保护的无服务器功能可以从安全共享中受益。当前的 SGX 硬件不支持此功能。
4 PIE设计
PIE 扩展了 SGX 设计，以支持高效灵活的飞地模型。PIE 引入硬件原语：共享 EPC。
- 共享 EPC 组成的plug-in enclave，可以运行语言运行时、框架、共享库，或容纳可由其他 enclave 重用的初始通用状态
- 私有 EPC 组成的host enclave 运行处理用户密钥的安全沙箱。
- 主机 enclave 可以共享通用的插件plug-in enclave，通过重用现成加载的内容并避免昂贵的测量生成，从而提高空间和时间效率。
PIE 引入新指令：EMAP按区域分配的指令，允许host enclave 访问plug-in enclave 的整个虚拟地址空间。EUNMAP 回收已分配的虚拟地址空间区域。
通过重新映射不同应用程序的plug-in enclave 来消除昂贵的数据传输瓶颈，同时保留要就地处理的秘密数据，即所谓的原位处理。为了保留安全属性，PIE 会阻止对插件 enclave 的写入尝试，并使用硬件强制执行的写入时复制机制。当共享插件 enclave 的初始状态有助于提高性能时，需要 copy-on write。从本质上讲，PIE 通过正常的 DRAM 操作（即动态映射和写入时复制）启用飞地内存。PIE 证明此扩展对实际应用程序是实用的，并且可以使 enclave 应用程序的低延迟受益。
性能评估
相关工作
无服务器领域和其他方法的比较
- Microkernel-like Sharing：Conclave建议使用多个服务器 enclave 在应用程序 enclave 之间共享。
- 无服务器计算所需的低延迟属性很难实现
- 使用类似 SSL 的安全通道跨 enclave 边界重新加密，高开销
- 无法处理跨多个函数 enclave 共享的重量级语言运行时 （LR）
- Unikernel-like Sharing：Occlum在许多基于软件的隔离任务之间共享库操作系统，在单个 enclave 地址空间内实现高效的多任务处理。
- Occlum 支持快速 spawn（） 系统调用，适用于无服务器自动扩缩容
- Occlum 的 inenclave 隔离由软件保证，需要全面的代码检测和复杂的完整性检查，很难证明 Occlum 基于软件的隔离是足够的
- Nested-library Sharing：Nested Enclave在 Enclave 中引入基于硬件的分层隔离。
- 嵌套 Enclave 将共享库放置在可共享的外部 enclave 中，同时在独立的内部 enclave 中运行每个用户逻辑
- 共享时，外部无法访问内部；PIE 和嵌套 Enclave 都可以通过快速实例化使无服务器自动缩放受益
- 嵌套围圈可能不适合无服务器计算：（1）不可能在外部安全区共享 LR（例如，Node.js、Python），因为这些运行时必须访问内部安全区中的用户脚本。（2） 嵌套 Enclave 用 enclave 调用替换库调用，这需要修改代码并产生运行时上下文切换开销（6K∼15K 周期）。相比之下，PIE 允许主机 enclave 通过快速函数调用（5∼8 周期）调用插件 enclave。
基于飞地的无服务器框架
Se-Lambda：利用 WebAssembly 沙盒环境作为无服务器函数的双向函数。
S-FaaS： 将硬件事务（ Intel TSX）和 SGX 结合在一起，用于可信的无服务器资源帐户
T-FaaS：将 JavaScript 引擎移植到 SGX 中，以构建安全的无服务器平台。
Clemmys： 对 SGX2 EAUG 操作进行批处理，以快速创建大型堆无服务器飞地。无法优化大代码 enclave 初始化和测量引入的延迟，PIE 通过安全地重用不可变插件 enclave 解决了这个问题。
无服务场景初始化延迟优化
为了降低函数启动成本，SAND 利用细粒度沙箱和高局部消息总线，而 SOC建议使用简化容器。Catalyzer通过写入时复制和内存快照共享实现亚毫秒级函数启动。FAASM利用共享内存来避免函数之间昂贵的数据移动。通过PIE扩展，Catalyzer和FAASM的优化技术可以直接安全地应用于安全区保护功能。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，可以在下面评论区评论
