服务器无感知计算作为一种全新的云计算范式，在公有云服务上的应用越来越普遍，如Amazon AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等。服务器无感知应用可以处理来自用户的敏感数据，如人脸识别、语音识别等场景。体系结构支持下的硬件飞地可以很好地保护此类敏感应用免受不可信云的影响，保证用户隐私数据的机密性和处理过程的完整性。Intel SGX是一种典型的硬件飞地，提供了内存加密、远程验证、物理隔离等诸多安全特性，目前也在云上得到了较为广泛的部署。

本文工作首次系统性地研究了在硬件飞地平台运行服务器无感知应用的性能问题。本文作者在Intel SGX中运行了开源的服务器无感知应用程序。性能分析报告表明，在飞地保护下的安全应用程序的性能损失高达5.6～422.6倍。进一步分析得出，性能损失主要和硬件的架构特性有关，具体来自硬件飞地的初始化过程（包括地址空间的创建和远程验证哈希的生成）。本文工作重新审视了Intel SGX的硬件设计，并对其飞地模型进行了适当扩展。本文提出了名为插件飞地（plugin enclave，该方案简写为PIE）的硬件原语，插件飞地可以映射到多个宿主飞地（host enclave）的地址空间，从而在多个安全应用之间重用公共状态。通过在同一宿主飞地中映射不同的插件飞地，机密数据可以实现“原位计算”，进而避免了服务器无感知函数链式调用导致的昂贵的数据移动开销。实验表明，本文设计能将飞地运行服务器无感知函数的延迟降低94.74%～99.57%，并将自动缩放吞吐量提高19～179倍。

服务器无感知计算允许开发人员编写细粒度的函数作为服务，让开发人员能够更好地专注于业务逻辑，同时最小化开发者对部署、管理、可扩展性的投入。随着服务器无感知计算平台的蓬勃发展，服务器无感知计算正成为新时代云计算的主流。

服务器无感知计算中的函数是由事件触发的实例：只有在请求到来时才会被生成并被调用，生成时会启动在任意一台可用的服务器上。这便是其“服务器无感知”的名字由来。触发的事件可以是用户请求，也可以是另一个函数的调用（即链式调用），函数间通过组织成链来处理复杂的业务逻辑。

服务器无感知计算的函数实例通常有低时延的要求。先前的相关工作研究了Microsoft Azure云平台上真实场景下的服务器无感知应用程序特点。研究结果表明54%的服务器无感知应用程序仅包含一个函数，而50%的函数执行时间不到1秒，因此服务器无感知应用程序对服务的延迟非常敏感。工业界和学术界一直在尝试优化服务器无感知计算的性能。

服务器无感知应用程序可能会处理隐私敏感的工作负载。根据Amazon AWS Lambda和Google Cloud Functions的用例，服务器无感知计算可用于安全或隐私相关的应用程序，如Auth0（用于身份验证）、Alexa聊天机器人（用于分析用户意图）、人脸识别（用于获取生物信息）等。在复杂的云环境中，需要小心谨慎地保护用户隐私，使其免受存在漏洞的云软件栈、恶意的租户甚至是可疑的云管理员的破坏。可信执行环境（trusted execution environment，TEE），如Intel SGX，能很好地提供与系统其余部分完全隔离的安全飞地，并允许远程用户通过身份验证确认飞地内容的真实性。因此，TEE被认为是一种颇有前景的隐私保护技术，可用于服务器无感知应用程序的隐私保护。现在学术界已提出一部分基于Intel SGX的服务器无感知计算平台。

在本文工作中，作者将5个真实世界的服务器无感知工作负载（如表1所示）移植到安全飞地内的库操作系统中（类似于Graphene-SGX，但支持SGX2功能）。

表1

经过详尽的性能剖析，作者发现大部分开销来自飞地的初始化：创建硬件飞地和生成验证哈希所花费的时间占据飞地函数启动时间的绝大部分（如图1所示）。此外，性能分析结果还表明了另一个导致性能下降的因素，即函数之间的数据传输，占据端到端执行时间的4.4%～29.8%。对于长函数链的调用情况，性能影响将变得更加明显。函数链式调用下的开销情况如图2所示。

图1

图2

通过回顾Intel SGX的硬件设计，作者发现基于飞地的服务器无感知应用效率低下的根本原因是当前的SGX设计（无论是1代还是2代）都禁用了飞地实例之间的内存共享。这种无共享设计提供了强大的安全保证，但会导致显著的启动延迟，这不适合当今服务器无感知计算的低时延要求。

基于以上飞地内服务器无感知应用程序的性能问题，本文提出了一种全新的飞地模型PIE，它使面向服务器无感知计算的安全应用变得高效。

1. 威胁模型

PIE遵循当前SGX的威胁模型：所有飞地内代码和数据都是可信的，包括插件飞地中的代码和数据。与先前旨在提高飞地性能的其他方案相比，PIE旨在提供更好的兼容性和实用性。

PIE的信任根由硬件供应商提供。用户在发送他们的机密数据前必须远程认证宿主飞地的状态（包括代码和数据）。PIE利用信任链模型，由宿主飞地负责在本地证明所有使用的插件飞地，以提供整个飞地的安全保证。任何由特权软件发起的对插件飞地管理行为的非法干扰都可以被检测或中止。

侧信道问题（如Spectre、L1TF）和CPU实现漏洞（如基于功率的故障注入）不在考虑范围内。这部分架构上的问题可以通过改进处理器的内部电路设计来解决，或者通过更新相应微码（Microcode）来缓解。不考虑拒绝服务，因为远程用户可以很容易地检测到云服务的不可用性。

2. 观察

通过对现有服务器无感知函数实例的分析，本文作者得出如下两个观察。

（1）服务器无感知应用程序普遍使用高级语言进行开发，如Python、JavaScript。这些应用程序使用了大量第三方库。而这些共享库虽然参与了隐私数据的处理，但本身并不是隐私数据。其“共享库”的名字也暗含着这些库本该在不同实例间进行共享。

（2）高级语言的共享库占据了大量的代码段，TensorFlow的机器学习程序的代码段大小甚至可达100MB。这些代码段在安全飞地的启动过程中都必须参与验证度量，因此在启动过程中会消耗大量时间。

综合以上两点观察，本文作者认为，对服务器无感知计算的安全实例提供共享库的共享，这本身并不会泄露隐私数据（因为大量共享库是开源的），其次如果能提供共享库的复用，可以很好地规避函数频繁启动时必要的哈希验证时间，为应用程序提供低时延的保证。

3. 设计描述

当前SGX仅提供私有的安全内存页：EPC。每个EPC只能由一个飞地实例访问，不存在共享的可能。PIE引入了新的安全内存页的硬件抽象：共享EPC。这个抽象允许飞地开发人员构建两种逻辑飞地：一种是由共享EPC组成的插件飞地，包含可复用的公共状态，如Python语言运行时、TensorFlow机器学习框架和第三方共享库（如OpenSSL）等；另一种是宿主飞地，宿主与当前的SGX设计一样，由私有EPC组成，彼此严格隔离，但可以将插件飞地映射到自己的飞地地址空间内。宿主飞地用于处理用户的隐私信息，并保护整体的函数处理流程。为了支持高效映射，PIE引入了新指令：EMAP。与SGX现有的逐页映射指令（一次只处理一个EPC页）不同，EMAP是一种基于“域”的操作指令，能将一整块插件飞地一次性映射到宿主飞地中。映射后的插件飞地允许访问宿主飞地的整个虚拟地址空间，如图3所示。为了有选择地解除不必要的插件飞地的映射，PIE提供了另一条反向指令：EUNMAP。EUNMAP用于回收先前分配的插件飞地的对应区域。 

图3

EMAP/EUNMAP这对指令也提供新的优化机会：通过重新映射不同应用逻辑的插件飞地，可以将隐私数据保留在同一个宿主飞地内不变，而通过动态改变插件飞地来实现新的函数调用链。这一做法很好地消除了数据传输瓶颈。我们称该新型函数调用链的计算模型为面向服务器无感知计算的“原位计算”模型，如图3所示。第一阶段中，宿主对插件的修改触发了写时复制（COW）；第二阶段中，宿主用EUNMAP将插件移除，并复用现有EREMOVE指令移除COW页面；第三阶段中，宿主用EMAP加载了新的插件。全过程隐私数据不参与移动。

为了保证整体模型的安全性，PIE必须保证插件飞地的度量和内容之间的一致性，否则复用一个可以被任意修改的插件飞地是没有意义的。为此，PIE会阻止对插件飞地的任何更新，使用硬件强制的写时复制机制来确保插件飞地的不可更改特性。本质上，PIE使飞地内存具有正常内存操作的能力，即动态映射和写时复制。

（本文选取了文章部分章节，更多精彩内容请阅读《网络安全国际学术研究进展》一书。）

作者简介

李明煜，上海交通大学IPADS实验室博士研究生。他的主要研究方向为系统安全、机密计算，其研究成果发表于OSDI、ISCA等系统方向和体系结构方向的学术会议。

版权声明：本书由网络安全研究国际学术论坛（InForSec）汇编，人民邮电出版社出版，版权属于双方共有，并受法律保护。转载、摘编或利用其它方式使用本研究报告文字或者观点的，应注明来源。