【论文阅读】——Spons Shields: Practical Isolation for Trusted Execution

文章目录

Abstract
Introduction
Isolation Support For Trusted Execution
- Hardware TEEs
- OS Support Within TEEs
- ThreatModel and System Requirement
- Existing isolation Approachs
Spons and Shields
- Overview
- Use Cases for Spon and Shield Separation
- Spon API
SSF implementation
- memory layout
- Execution and Memory Access Isolation
- Protecting the TEEOS Interface
- Multi-Threading Support

Spons & Shields: Practical Isolation for Trusted Execution

**
作者：Vasily A. Sartakov、Daniel O’Keeffe、David Eyers、Lluís Vilanova、Peter Pietzuch
来源：VEE
**
lift and shift model: 云迁移选项，与SDK不同，无需重新设计，但是在TEE中这样操作的话，TEE OS需要支持大量lib，TCB较大
MMU:Memory Management Unit
IPC：Inter-process communication
SFI:Software Fault Isolation，将代码限制在自己的代码块中，进行跳转检查
CFI :control flow Integrity，检查跳转的地址是否为CFG（Graph）规定地址
ABI:APP Binary Interface
POSIX：Portable operating system interface of Unix
MPX：Memory Protection Extension
musl：轻量级stdc
MPK：
原语：TEE中的术语，封装好的代码块
文中提到的常见TEE OS：4——SCONE、6——HAVEN、21——Graphene

阅读之后，感觉本文大致使用LLVM的SFI和CFI以及硬件中MPK，实现了在enclave内部的一个隔离，达到了同一个enclave中多个进程在没有依赖OS和MMU的情况下实现了类似进程隔离，并且通过划分所属Shield，在同一个Shield中的Spon可以访问对方的内容，实现了共享内存的需求。使用用户级线程避免线程转移出enclave，来减少在user和kernel间线程切换的开销

Abstract

对于云中部署安全敏感的应用来说，TEE提供了一个lift and shift的部署方式。TEE OS必须支持很多lib，TCB较大。将应用进行细粒度划分，可以提高安全性。
对于应用划分的组件如何在TEE中运行，有两种选择：

在同一个TEE中运行所有的组件，并且内部不做任何多余的保护处理，缺乏足够的共享内存（感觉是因为TEE内存大小原因）
使用不同TEE运行不同的进程，性能和兼容性较差，并且多个组件间的通信要使用加密解密等操作

本文提供了Spons&Shields两个新的抽象概念？，在TEE中统一了进程、lib、usr/kernel隔离，并且支持内存共享

Spons：每个POSIX进行或者库一个
Shields：提供一个强制执行的内存访问策略
达到了与进程隔离相同的性能

Introduction

传统中使用SDK模型，TEE中运行一部分计算敏感的组件，较小的TCB，但是需要重新开发。之后的lift and shift模型，在TEE中运行容器化应用或者完整的VM。该模型需要TEE OS的支持，例如SGX中的SCONE、Haven、Graphene；AMD中的SEV-SNP，但是该模型的TCB较大，带来了安全性的下降。

软件划分是个解决方法，使用隔离机制将软件组件彼此分离，但现有的隔离技术不足以提高TEE中大软件的安全性：进程隔离将安全敏感的功能提取到单独的进程中，是一项复杂的任务，并且会影响程序性能，而且需要OS和MMU的支持，但是TEE无法与不可信的组件进行合作，OS和MMU在TEE中功能受限。

U/K隔离是防止可信K不受U的攻击，但是在TEE中认为K是不可信的，要防止K对U进行攻击，因此，传统的U/K隔离无法防止应用程序中的漏洞被利用？

Multi-TEE使用多个TEE隔离应用组件，ex：SGX，但是创建TEE成本很高，数据复制和加密的开销阻止了有效的数据共享
理解TEE中隔离需求

该服务需要四个应用组件，A中是运行在相同的TEE中并且没有相互隔离：Nginx、SSL加密、PHP、DBMS数据库。该项服务需要在TEE中创建多个进程，并且使用IPC

进程隔离：web请求无法访问其他进程中的敏感数据
库隔离：其他进程都不可信，SSL库中的密钥也不会泄露
PHP解释器与其模块隔离：防止其被恶意模块攻击？
传统的U/K隔离：web进程无法损害TEE OS，进程只能通过可控的进入点去访问TEE OS和敏感库

除了上述细粒度隔离，还需要共享内存，SQL进程使用IPC交换数据，SSL访问web请求，进程内存被TEE OS可以访问，来控制用户级线程调度？

本文提出了Shield&Spon两种抽象概念，为TEE中细粒度划分提供了统一的机制，统一了进程隔离、库隔离、U/K隔离同时也允许内存共享。通过分离隔离的执行和内存保护方面，SSF提供有效的机制，满足TEE内隔离的功能和安全需求

Spons封装应用组件的上下文和其他Spons的入口，可以动态创建Spons
- Active Spons支持多线程，包含由用户控制的一个或者多个执行上下文
- passive Spons将libs屏蔽为Active Spons的一部分（passive Spon一般来说为active Spon通过TEE接口进行调用，被嵌套在Active Spon中）。Spons只能通过定义好的接口调用其他Spons，passive通过调用者来获得执行上下文
Shields定义了内存保护便捷的层次结构，允许嵌套Shields。比如图中：TEE OS在root上，系统调用当做进入点，提供U/K隔离；web、PHP、DBMS被屏蔽，提供进程隔离；DBMS使用同一个Shield，方便IPC；SSL和WEB的嵌套层次，提供库隔离来加密密钥，允许库访问web的数据

这个方法，在TEE不支持VM和OS的情况下也可以实用。一些TEE提供进程功能，但是不隔离，一些进行隔离并提供共享内存，但是性能下降。

本文选用SGX，但SGX不提供硬件机制实现enclave内部隔离，SSF实用编基于编译器的LLVM pass（SFI和CFI）保护Shield的边界，MPX指令执行边界检查，LKL是TEEOS的实现，提供全部Linux ABI在SGX中，利用用户级线程来考虑安全和性能原因，为了U/K隔离，SSF对标准C区分（用户态接口划分？），在TEEOS和应用程序之间划分线程元数据

Isolation Support For Trusted Execution

Hardware TEEs

云中处理数据有危险，SGX提供了针对应用程序级代码的最小TEE，但是enclave缺乏管理权限级别和页表的管理机制
Enclave使用与其他进行空间隔离的内存，EPC，PRM，MME，防止物理攻击，与外部交互使用OCALL

OS Support Within TEEs

Lift and shift导致较大的TCB，SGX需要定制的libos，现存的TEE提供了OS lib：内存分配、文件、IO、线程同步和调度，传统kernel中的一些库不必要（为了小TCB）：设备驱动程序、低级别硬件管理和多用户支持

使用TEE OS的应用设计，与TEE OS的stdc进行链接，TEE OS包含，libc，LKL

ThreatModel and System Requirement

APP代码不安全、OS不安全，TEE硬件安全，不考虑侧信道攻击，TEE OS和编译器安全。目标是：进程或者库相互保护，并且保护TEE OS不受这些库或者进程的攻击

需求：
R1: Fine-Grained 隔离：提供原语去划分TEE APP，开发人员干预少，性能开销低，适用于lib和pro，TEE OS视为另一个组件
R2：有效内存共享，将组件与应用程序的其余部分和TEE操作系统隔离时支持应用程序组件子集之间的高效共享内存通信
R3：兼容现有的POSIX APP，提供与现有APP的进程、线程、IPC兼容的抽象，提供的原语在运行时也可以用，并且不限制单元数量，只收内存限制
R4：在TEE中试线，不依赖OS和硬件，与TEE兼容

Existing isolation Approachs

一个进程host多个TEE，但是多个TEE间的通信必须加密进行。性能较差，需要重新开发——不满足R3，R2

表比较了进程内隔离的其他方法

进程领域：使用不同的硬件机制来划分进程。MPK通过为page添加标记来对进程的领域限制，类似的，可以将标记分配给线程，将他们绑定到特定的范围中，Shred与MPK类似的ArM域，ERIM和CubicleOS引入了MPK的系统抽象。但是只能使用较少的独立上下文，与R3冲突。libMPK通过虚拟化保护密钥解决了这一限制，但是需要使用OS，与R4冲突
硬件隔离扩展：IMIX引入了内存隔离，允许开发人员将内存也标记为安全敏感，CHERI和CODOMs引入了基于硬件的额支持程序划分系统，但是都依赖于TEE上不可信的硬件，与R4冲突
内核强制隔离：OS可以使用自己的原语和MMU来隔离部分进程。LwCs是进程内隔离的抽象，每个LWC有自己的堆栈，但是智能访问有限的内存范围，进程切换的话设计OS，因为会更改虚拟内存映射，文件表。SECage或者都依赖可信的VM或者OS，与R4冲突
编译器检测：编译器可以检测TEE的代码，来保护指针，使用MPX或者SGXBounds，开发人员将检测添加到与指针相关的操作中。MPX使用硬件便捷寄存器来检查缓冲区，SGXBounds将缓冲区大小编码至SGX TEE未使用的指针位，但是都不提供编程抽象，与R3相矛盾
编译器检测可以再较粗的粒度上保护代码，ConfLLVM在进程内创建两个分区，一个是可信的，一个是不可信的，将检测不可信分区，保证代码永远不会到达可信分区，只支持两个分区，与R3相矛盾？Occlum支持使用MPX的SGX TEE内部多进程隔离，但是不支持库隔离（R1），并且只支持具有重叠内存范围（R2）的进程之间非常有限的内存共享。Occlum同时依赖OS的调度和同步R4

虽然已经提出了许多技术来隔离用户空间组件，但它们要么需要额外的硬件，要么需要不受信任的主机OS内核的参与，要么不提供适当的编程抽象

Spons and Shields

Overview

图3，展示了一个使用SSF框架的例子
Spon封装了执行上下文：具有一组函数入口点，线程上下文和栈，堆分配器的可执行代码
SSF提供两种Spon：

passive Spon（SponSSL）：使用开发人员制定的入口点函数（SSL_read）封装任意代码，
active Spon（Sponweb、SponPHP）：用来封装POSIX进程以及进程的主入口点

所有用户代码斗鱼一个Spon相关联，它是执行上下文的句柄，也是最小的内存保护单元，内存保护策略在SSF中通过为Spon分配Shield（多个Spon可以分配给相同的Shield）并定义Shields之间的分层嵌套关系来表示，允许访问与其在同一个Shield中的Spon。

TEE OS在默认的最外层Shield执行，默认情况下，该Shields也分配给未指定Shields的所有Spon，为了使线程更有效和安全的抵御来自主机的某些攻击，每个Spon有一组在OS上多路复用的用户级线程，通过TEE OS调用另一个Spon的函数，会导致用户级线程的上下文切换，Passive Spons是同步调用的，但是包含独立的线程堆栈

SSF检测Spon的代码，检测内存访问是否在指定的Shield上，Spon不能直接访问TEE OS，SSF配置了一个回调函数表在Spon上，指向TEE OS中的可信函数。对于TEE OS的调用没有上下文切换开销（？不是很明白），并且TEE OS自己是不被检测的，TEE OS是被加固过的，防止未授权的跨Shields交互

用户可以在启动TEE时候进行创建Spon和Shields，也可以在运行中动态创建。

Use Cases for Spon and Shield Separation

SSF中最简单的用例是一个Spon对应一个Shield，实现了传统的进程隔离。SSF也支持多个进程共享内存——多个Spon对应一个Shield，现有的但TEE和多TEE在进程隔离时，对于共享内存的支持并不是很容易。DBMS对应一个Spon但是多个Spon放在同一个Shields，支持共享内存，所有的DBMS进程可以相互访问，但是不需要更改应用程序来跨其他组件提供保障（？不是很明白）

Spon和Shield的分离以及Shields的嵌套，允许非对称保护

图片左部，SSL使用passive Spon来隔离自己的key，SponSSL是一个passive Spon能访问SHieldSSL中所有内存，包括ShieldWeb，因此，SSL可以直接访问SponWEB接收的数据，SponWEB只能访问ShieldWeb的数据，并且必须使用TEE OS来访问SponSSL中提供的加密函数 SLL_READ

右图中，python解释器—— active SponPY调用不可信的C模块-passive SponMod，这是用来隔离可能存在漏洞的库，module被Shieldmod屏蔽，py通过TEE OS调用函数将参数传递给SponMod，TEE OS将上下文切换到被调用的Spon中，SponMod执行时，限制在Shieldmod中，使得C模块免受攻击

Spon API

SSF通过额外的调用拓展了TEE OS POSIX原语来管理Spon和Shield
表2展示了用于配置任意数量的Spon和Shield的API函数：

1、Ahead-of-time operation，第一组函数在TEE OS中创建一组规则，在创建TEE时配置未修改的APP，alloc_shield和free_shield操作管理Shields的大小和层次结构，sid参数允许嵌套屏蔽，size参数确定了所有相关SPON的最大内存大小，并设置了Spon的堆空间，register_Spon和deregister_spon修改了TEE OS的规则，将可执行路径程序的路径（？？可能是应用程序的路径字符串 char *）映射到Spon和和对应的Shield
调用call_spon为先前创建的path创建passive Spon，TEE OS分配空间，并将对应的path加载到对应的Shield中，并且在Spon中动态创建代码块，来调用了那个func_name，call_spon仅接受path导出public 标志（类似于动态链接），并且将生成的代码thunk执行引导进TEE OS中，以便之后将执行上下文切换到对应的passive Spon对应的用户级线程中，传递给该代码块的参数必须是标量，或者是指向在目标Spon中屏蔽分配的指针

2、runtime operation，alloc/free来管理Shield的内存，TEE OS来执行分配，例如使用共享内存

3、POSIX-like操作，
提供类似POSIX的exec和execves调用，使用，标准的类似接口，OS通过接口对APP进行访问

创建三个Shield、注册每个register SPON并分配到对应的Shield中、创建必要的active SPON和Shield 唤醒main函数

SSF implementation

memory layout

应用程序由三部分组成：APP、有接口的库函数，TEEOS。TEEOS将这些组成结合，提供了供SGX使用的接口函数

TEEOS组件绑定在0 Shield，可以访问所有的TEE 内存，通过细分内存布局创建Spon和Shield，每个Spon有自己的堆栈，数据
为了在SPON中执行程序，需要与musl链接，之后为每个Spon创建个回调表，定向到对应的TEE OS函数中

Execution and Memory Access Isolation

SSF需要在不依赖OS的情况下加强Shield的边界保护（R4需求）；因为，Spons和Shields可以动态创建，不能限制最大数量。

SGX不提供内存保护的硬件支持，使用SFI、CFI、和MPX加速结合起来对应内存访问执行边界检查，SFI和CFI是为了阻止绕过SSF隔离的攻击，并支持不修改APP
为了保护边界，每个SHIELD只获得其指定内存（由alloc_shield中的参数指定）大小的一部分。TEE OS不需要检测（感觉可能是因为TEE OS可以访问当前SGX所有的内存空间）

Compiler-based bounds-checking：SSF提供了SSFpass，Spon的每个内存访问添加边界检测指令，访问合法的Shield外部内存的代码会报错
SSFpass保留MPX边界寄存器，包含当前活动的Shield边界，并且为每个Spon的内存访问插入必要的检查指令。还验证检测代码不会修改寄存器的值，之后Shield切换时，通过bndmk来更新寄存器的值

SSFpass通过LLVM实现，对Spon的ir进行操作，不需要更改源代码，为了减少开销，对已知安全地址的检查，只进行一次

加强控制流完整性：
使用CFI来限制间接函数调用，强制使用正确的动态类型函数进行调用，只对前向调用提供保证，函数的return无法提供保护

Protecting the TEEOS Interface

当TEE OS与APP进行交互是，必须提供类似u/k的隔离保证，TEE OS在SGX中的地位相当于普通的host OS
用两个函数来举例，防止TEE OS的内存被调用

memcpy用于赋值内存，由musl实现，见上一节的内存保护，
wirte函数由TEEOS实现，通过回调表调用，检测内存的限制，检测指针参数的有效性，保护功能

Multi-Threading Support

TEE OS使用用户级线程。每个硬件线程有用户级线程管理器，管理用户级线程池，用户级线程管理器将可以运行的用户级线程描述符从pool中取出来，将环境切换到对应的线程

默认的SGX-LKL中没有TEE内存保护，将线程调度到对应的Spon需要使用OS将l线程映射到p线程，使用OS可能会带来开销

因此，TEE OS维护了一个集中用户级线程调度器，对lthread线程数据进行了分区，没有被Spon使用的lthread在TEE OS中，使用的在Shield中,还从spn musl中删除与线程相关的代码，将调用重定向到TEE OS。这保证了所有线程和同步原语使用相同的功能，并且Spon不会引用其Shield之外的线程元数据？