PANOPLY:Low-TCB Linux Applications with SGX Enclaves笔记

最近在看一些SGX相关论文。
本文主要对所选论文的Abstract、Introduction、Problem、Solution进行梳理。
Abstract：

  Intel SGX是新兴CPU的安全能力，它允许用户级应用程序代码在硬件隔离的enclave中运行。
  但enclave们功能有局限性，如：没有对系统调用和标准操作系统抽象的本地访问，而在现实应用中操作系统的抽象往往很重要。
  本文提出了一个叫PANOPLY新系统，以消除原生SGX抽象与商用Linux应用程序需要的OS抽象的差距：
 1.PANOPLY提供了一个名叫“micro-container”的新抽象，是一些在enclave中被隔离的代码和数据，Mircons可以提供应用逻辑的标准POSIX抽象，包括对文件系统、网络、多线程、多处理和线程同步原语的访问。
 2. PANOPLT为内部enclave间的交互强制了一个强完整性属性。即使操作系统出现错误，应用程序的执行也会遵循合法的控制和数据流。
 与之前的系统相比，PANOPLY提供了两个数量级的低TCB(总计约20 KLOC)；

1. Introduction：

 在本文中，我们设想通过特权分离和隔离的好处，建立了一条强大的防线以防御系统恶意软件。基于可信计算原语的防御将敏感的用户级应用从低防御能力的操作系统中隔离开来。对于这个原语体的硬件支持已经以Intel SGX的形式出现在商用CPU上，它可以在enclaves中运行这种硬件隔离的应用程序实例。Intel SGX提供了一个可以远程验证的硬件隔离内存区域。SGX硬件支持同时执行多个enclave。
 目前已有研究的适用性仅限于小的、选定的应用程序逻辑片段，而不是端到端应用程序。对于更大、更丰富的应用程序，最著名的方法是使用os库。
  在本文中，我们提出了一个名为PANOPLY的新系统，其设计着眼于最小化TCB，同时为封装的代码提供丰富的操作系统抽象。 PANOPLY将最小TCB置于性能之上作为目标。它使用了一种简单的委托而非仿真的设计理念，与以前的系统(例如库操作系统)形成对比。PANOPLY将操作系统抽象的实现委托给底层的操作系统本身，而不是在enclave中模拟它。PANOPLY的microns能够检测到来自操作系统的恶意响应，并在这样的情况下中止。按照这样的设计选择，与库操作系统不同，PANOPLY不会通过给每个micron提供自己的名称空间来虚拟化micron，这种选择消除了大量的从enclave TCB模拟底层操作系统的名称空间管理逻辑。
  PANOPLY的第二个特性是它支持一种即插即用的架构，在这种架构中，安全架构师可以根据需要创建任意多的Micron，并在多个操作系统进程中托管它们。这样的设计保持了与多进程和多线程应用程序设计的兼容性，有更好的可用性。

 PANOPLY Micron向应用逻辑公开 表达性的操作系统抽象。为了支持这些，我们在其设计上做了一些概念上的改进，这些是SGX的现成Intel sdk所不提供的：
  1.Micron 公开了按需创建线程的POSIX抽象，动态地请求应用程序需要的任意数量的线程。以前的系统将这种设计限制为：在一个enclave中预先确定静态可执行线程的数量。
  2.PANOPLY提出了几种支持fork-exec语义的设计。PANOPLY允许多个操作系统进程承载Micron。
  3.PANOPLY支持pthreads同步接口，其中包括使用SGX特有的抽象、互斥、barrier等。
 4.最后，如前所述，PANOPLY自动在Micron接口上嵌入检查，确保飞地间控制和数据流符合原始代码。

Result:
  我们对4个使用表达特性的实际应用程序进行了案例研究,移植工作都是适度的，平均需要修改905行代码，案例中应用也有了一定优化。

Contributions

• PANOPLY系统。 PANOPLY是第一个支持多线程、多处理和事件管理应用程序的系统。我们的微米间流完整性确保应用程序保持高水平的保证。
• 在实际应用中的使用。 我们将4个应用程序改造成PANOPLY架构，平均需要修改905行代码。
• 评估。 移植到PANOPLY后，我们报告每个应用程序的性能开销为24%，平均TCB增加了19.62
  KLOC。与以前的系统相比，PANOPLY将TCB降低了2个数量级，同时降低了5 - 10%的性能开销。

2. PROBLEM：

A. Background: Intel SGX Enclaves
 介绍了Intel SGX中enclave的特性；

B. Attacks & Challenges
 为了在实际应用程序中实现端到端安全保障，我们的目标是解决三个主要挑战:
(1)支持丰富的操作系统抽象
(2)多个enclaves之间的安全交互
(3)最小的额外TCB。
Example：
为了确保更高级别的安全属性，我们将通过一个示例演示现有抽象中的差距，以应对这些挑战:
 FreeTDS:为远程数据库实现流协议(TDS[9])的应用程序; 使用OpenSSL SSL/TLS库与远程数据库建立安全通道。FreeTDS通过连接到证书管理器服务，检查远程数据库是否是经过授权的服务并具有有效的SSL证书。当且仅当原始应用程序接受了有效的证书时，FreeTDS应用程序才接受该证书。假设原始应用程序没有bug，但是系统管理员希望保护它不受 宿主服务提供商的基础设施（但系统管理员希望系统安全抵抗被感染的服务器） 的感染。我们可以通过使用英特尔SGX飞地来实现这种防御。
  受信任的证书管理器和FreeTDS被放在相互独立的enclave中，受信任的证书管理器服务在许多应用程序之间共享，如图1所示，FreeTDS应用程序通过标准的OpenSSL接口调用受信任的证书管理器来验证提交的证书。具体来说，FreeTDS应用程序通过3个步骤完成:

Attacks on Inter-Enclave Interactions：
 FreeTDS应用程序enclave多次调用证书管理器enclave,传递数据。这样的通信必须通过操作系统OS控制下的对抗通道。操作系统知道标准的OpenSSL接口及其接口的语义。如果enclave使用Intel SDK的标准接口，操作系统就会通过导致FreeTDS接受无效的证书来破坏应用程序的保证。我们在图2中展示了对这个接口的具体攻击。
 这些攻击表明不是在enclace抽象运行为目标设计的应用程序会被他的微小弱点而影响；此外，sgx本地的低级别保证(远程认证和内存隔离)与确保应用程序端到端安全执行所需的保证之间存在差距。以前的一些工作已经强制了私有密钥和经过身份验证的数据交付的保密性，而我们的重点是保护端到端应用程序语义。

---

Supporting Rich OS Abstractions With Low TCB：
 该示例突出了在支持实际应用程序方面的一个更基本的挑战。FreeTDS使用标准的系统调用，如gethostname()和poll()(隐式地用于回调注册)。然而，SGX和Intel SDK并不为这些抽象提供原生支持。表一显示了英特尔SDK、库操作系统和实际应用程序需求之间的差距。研究的问题是如何以最少的努力来支持这种抽象，使安全架构师能够快速地试验使用特权分离他们的应用程序的方法。
 提供丰富表达能力的最先进的解决方案依赖于库操作系统(如Haven[21]和GrapheneSGX[52])。库操作系统为应用程序代码提供了一个虚拟化进程名称空间的抽象。名称空间虚拟化需要在飞地中模拟许多操作系统逻辑。这种方法提供了与现有代码的良好兼容性;然而，这也带来了TCB膨胀的危险。库操作系统报告了数百万行代码的TCB大小。

3.Solution

A. PANOPLY Overview
 PANOPLY使丰富的Linux应用程序能够运行在SGX enclave上。PANOPLY提供了微型容器micron的抽象，micron是enclave包围的一个应用程序逻辑。
 Linux进程可以导入或托管一个或多个微米。Micron没有自己的虚拟化名称空间，而是与它们的主机Linux进程共享;Micron确实有它们的私有地址空间，它被隔离在enclave中，可以与主机进程共享任意数量的公共地址空间。默认情况下，基于微米的逻辑的代码和数据分配在私有内存中。存在一个显式的PANOPLY API，通过它微米可以与外部代码通信。

Micron代码可以访问POSIX v1.3 API的丰富子集。公开的API包括文件系统、网络、多处理、多线程、同步原语、信号和事件管理的系统调用。图3显示了标准Linux应用程序的部分，该部分在我们的体系结构中是TCB(灰色部分)。PANOPLY嵌入了一个薄shim库，该库与PANOPLY API接口相互作用。shim库在编译时被添加到每个enclave中。
 为了达到较低的TCB, PANOPLY选择了一种委托而不是仿真策略。首先，PANOPLY将所有系统调用委托给不受信任的操作系统。PANOPLY拦截对glibc API的调用，这允许我们将glibc库留在enclave TCB之外(图3)。其次，PANOPLY不在TCB中模拟整个操作系统逻辑，将调度逻辑委托给底层操作系统。因此，应用程序调度不能保证与原始代码相同(因此API是WILD)。然而，这种取舍是合理的，因为操作系统可以发起DOS攻击，并负责enclave调度。作为一个优势，它允许我们在enclave内放置最少数量的检查，从而显著减少TCB。最后，PANOPLY“选择性”地在enclave中包含API调用，也就是说，只有给定的enclave代码使用的API才会被包含在enclave中。

B. Usage Model & Scope
 系统概述：PANOPLY将原始程序和程序员的分区方案作为输入。它首先将应用程序划分为enclaves，然后加强微米间的流完整性，从而产生PANOPLY应用程序。

4. PANOPLY DESIGN & SECURITY

 这部分描述了PANOPLY的重要设计和选择，讲其必要性和它实现的方法；还有它的安全性如何保证。
A. Runtime Micron Management

• Micron初始化和身份建立
• 内部Micron流完整性

B. Expressiveness with Low TCB

• 系统调用
• 多线程方法
• 多重处理
• 共享内存
• 事件管理

5. EVALUATION

 将流行的现实世界应用程序移植到Micron，并针对一套特定于应用程序的基准测试，我们展示了PANOPLY的有效性。这部分对PANOPLY进行以下评估：

• 表达能力。PANOPLY是否成功地支持微米内部的表达性编程结构?
• 较强的安全性。PANOPLY是否为应用程序提供更强的安全保障?
• TCB。PANOPLY在库操作系统上降低了多少TCB ?
• 性能。与库操作系统相比，PANOPLY的表现如何?

交代了实验环境；将真实的系统作为用例，对PANOPLY进行评估。

6.RELATED WORK

这部分讨论了PANOPLY在TCB、设计目标、范围和端到端保证方面与现有系统的区别。

7. CONCLUSION

 PANOPLY弥合了sgx本地抽象的表达性和特性丰富的Linux应用程序的需求之间的鸿沟。PANOPLY提供了一个新的设计点，在不牺牲兼容性的前提下，将TCB置于性能之上。它的TCB比以前的系统低2个数量级。