机密计算依赖基于硬件的可信执行环境(trusted execution environment，TEE)来保护用户安全敏感的数据和代码．区别于传统的静态存储中和动态传输中数据保护方法，机密计算技术主要用于保护使用中数据安全[1-3]．它通过专有硬件安全扩展例如Intel SGX (intel software guard eXtensions)创建一个可行执行环境称为TEE或enclave，使得运行于enclave内的数据和代码获得全面的机密性和完整性保护[4-7]．SGX原始设计考虑了一个强的安全威胁模型，它不信任云服务提供商、第三方服务提供者、系统管理员、其他可以接触物理机器的人员等，仅仅信任Intel CPU SGX实现和用户自己的程序代码．这种信任模型将庞大的攻击面(相对于传统操作系统)大大缩减．作为比较成熟的商业化产品，SGX技术已经被一些重要的厂商部署在云端服务器例如Microsoft Azure[1]、阿里云ECS[3]等，应用于金融、医疗保健、知识产权、多方共享机密数据、机密机器学习、区块链等敏感信息场景．尽管Intel SGX提供了一种强有力的、硬件级安全保护，但其自身设计约束导致enclave安全性、兼容性/可用性、性能等受到不同程度的影响．具体总结如下．a．二进制兼容性：由于Intel SGX自身设计空间约束，大多数SGX运行时框架[8-15]包括Intel官方提供的SGX SDK，仅仅提供了源码级而非二进制级的兼容性安全保护，使得SGX与未修改应用程序在兼容性和可用性方面存在重要不足．这是可信计算领域一个开放性问题．b．语言运行时兼容性：由于SGX默认仅支持运行基于C/C++编译的应用程序，语言运行时(例如Python和R)程序将无法直接运行于SGX enclave中，这类程序体积大、复杂度高等特点，语言运行时与Intel SGX技术的兼容性已成为一个独立研究点[16-17]．c．细粒度调停能力：本地操作系统中，许多用户应用程序可以在发布前使用工具(例如DynamoRIO[18])对其进行细粒度的安全监控、性能分析及动态优化等操作．而在SGX隔离执行环境中，由于安全约束，直接对enclave内部程序执行这些敏感且复杂操作是一项具有挑战的任务．d．轻量级：相比庞大的操作系统代码基，一些SGX框架使用“轻量级”的库操作系统来部分地解决与可信硬件兼容性问题，但是这类系统相比原始SGX运行时仍然较“重”，加上其他软件抽象层，可信计算基TCB将变得更加庞大．例如，Graphene-SGX[10] TCB高达1.2 MLoC，很可能导致可信计算不再可信．e．安全性：Intel SGX官方开发了配套的运行时软件，用以驱动处理器中SGX硬件保护机制，然而SGX复杂的软硬件设计自身可能包含安全漏洞[19-28]．例如OS-enclave接口的原子性安全[28]已然是一类重要的安全问题．本研究首先总结了SGX五个重要的设计约束，系统地分析了每个约束对enclave兼容性、性能、安全性等的影响；然后，对兼容性/可用性解决方案进行了综述，讨论了其优缺点；接着，从SGX安全性出发，对不同的攻击技术进行了分类和总结；最后，总结了SGX技术研究的经验教训、发展趋势，并指出了若干研究方向．1 SGX隔离技术概述SGX[4-7]作为Intel CPU架构新的安全扩展，在其原有基础上增加了一组新的指令集和内存访问机制．该扩展允许用户应用程序在其地址空间内划分出一块安全区域，称为enclave(围圈)，为围圈内的代码和数据提供机密性和完整性的保护，并阻止来自特权级恶意软件的破坏．SGX整体架构如图1所示，图中：R/W/X表示所拥有的操作权限，其中，R为可读，W为可写，X为可执行；EENTER，EEXIT，AEX，ERESUME表示Intel SGX指令集，其中EENTER为同步enclave进入指令，EEXIT为同步enclave退出指令，AEX为异步enclave退出指令，通过ERESUME指令可以恢复enclave上下文，继续执行；Ring0~3表示Intel CPU特权级别，主要划分为Ring0，Ring1，Ring2，Ring3四个级别，其中Ring0是最高级别，Ring1次之，依此类推．SGX的实现需要处理器、内存管理部件、BIOS、驱动程序和运行时环境等软硬件协同完成．特别指出的是：Intel SGX引入了enclave私有内存的概念来表示被SGX硬件隔离的内存区域，该区域是事先从整个动态随机存取内存(DRAM)中预留了一块连续物理内存，称为PRM，通常可以在BIOS中选择其大小(例如系统预设了96 MiB或者128 MiB)．负责创建enclave并与之交互的用户进程称为主机进程，在enclave内被执行的程序称为enclave软件．Enclave运行时代码和数据，包括其堆栈(enclave私有堆栈)都存储在enclave内，并受到SGX硬件的保护．在SGX信任模型中，只有SGX硬件和enclave软件是可信的，系统上所有其他软件，包括特权软件如操作系统、虚拟机管理程序等都被认为是不可信的．SGX硬件不允许不受信任的软件访问enclave内存，但enclave软件可以读取或写入enclave边界外的内存区域，即主机进程内存空间．这种enclave和主机进程都可访问的共享虚拟地址空间称为公共内存．10.13245/j.hust.240204.F001图1Intel SGX隔离机制除了提供内存隔离与安全保护属性，SGX架构还支持本地/远程认证和密封的功能，用于安全软件相互认证和数据安全存储保护．SGX提出了两种类型的身份认证方式：一种是平台内部enclave间的认证，用来认证进行报告的enclave和自己是否运行在同一个平台上；另一种是平台间的远程认证，用于远程的认证者认证enclave的身份信息．数据密封允许enclave内数据在enclave之外被存储，不会破坏数据的机密性和完整性．密封是通过在退出enclave前对数据进行加密来实现的．Enclave软件可能须要依赖非enclave软件(如操作系统)提供的服务，如系统调用和接收信号等．SGX硬件有同步和异步两种接口，用于在操作系统和enclave之间切换．图1体现了这种交互接口和SGX保护机制．一个enclave中可以包含多个TCS (thread control structure)结构，它用于保存进入或退出enclave时恢复enclave线程的必要信息．每一个enclave中的执行线程都和一个TCS相关联，它需要4 K字节对齐，由多个部分组成，例如保留位(RESERVED)、标志位(FLAGS)、状态保存区偏移量(OSSA)等．Intel SGX SDK通过ecall和ocall为SGX应用程序提供了一个函数调用机制．具体来讲，ecall是进入enclave去调用可信函数的操作，而ocall是退出enclave去调用不可信函数的操作[4]．因此，用户应用程序可以通过调用ecall执行enclave内的代码，并获得返回值；enclave可以调用ocall执行应用程序中不可信部分的函数，并接收返回值．enclave代码可以访问外面应用程序内存，而非enclave代码则不能访问enclave的内存．SGX CPU支持本地和远程验证，以便检查enclave是否加载了正确的代码．为此，CPU首先通过计算enclave初始状态的哈希得到一个测量结果；其次，一个实体可以进一步验证该测量结果，以确认该初始状态是“干净的”．上述步骤可以保证enclave是在没有被操作系统篡改的情况下按预期创建和加载的．2 SGX设计约束及其影响Intel SGX允许在一个称为enclave的硬件隔离执行环境内运行用户应用程序代码[4，7]．然而，对enclave内执行的所有指令进行调停或控制是一个重大挑战，因为SGX有严格的威胁模型和对enclave代码的安全限制．在该威胁模型中，操作系统是不被信任的，SGX必须确保enclave内代码和数据的机密性和完整性．所有enclave内存都是私有的，只有在enclave模式下执行时才能被访问．与外部世界(例如主机应用程序或操作系统)交换的数据必须驻留在不受保护的公共内存中，因为外部程序无法访问enclave私有内存．当运行时，执行控制只能通过ecalls同步操作进入enclave，通过ocalls退出enclave，这是SGX中提供的两个主要交互接口，也是实现系统调用(syscalls)的主要方式．enclave中的任何非法指令或异常都会产生异步的进入-退出点，之后SGX将重定位当前控制流到程序中预先指定的位置．此外，如果enclave的执行被异步中断，SGX会保存enclave代码执行上下文，并在之后的进入点恢复它们[4]．2.1　设计约束Intel SGX通过在操作系统和用户enclave代码之间的关键交互点上实施严格的隔离策略，从而保证enclave安全性．本节概述了SGX硬件设计所实施的5个约束条件[9]．(1)空间内存划分：SGX从空间上强制实施内存分区策略．它预保留了一整块内存区域作为enclave私有的而其余作为公共虚拟内存．内存可以是公共的，也可以是私有的，但不能两者兼而有之．(2)静态内存划分：SGX必须静态地指定空间分区．它的私有内存大小、类型(如代码、数据、堆栈、堆)和权限必须在创建之前指定，无法在运行期间被改变．(3)非共享私有内存：一个enclave不能与其他enclave共享其私有内存，为了安全考虑，SGX不允许同一块物理内存被多个enclaves同时映射或访问．(4)一对一私有虚拟内存映射：enclave私有内存包含一块连续的虚拟地址(VA)范围，其起始地址由操作系统决定．私有VA空间与物理地址(PA)空间是一对一映射关系．(5)固定入口点：一个enclave只能从它最后的退出点和上下文信息恢复执行．任何其他的入口点/上下文都必须在enclave程序中预先静态地指定或设置，否则无法执行期望的代码．上述SGX设计约束对操作系统常见功能会有不同程度的影响．例如，约束(1)会导致系统调用参数无法直接传递；动态加载及产生的代码会受到约束(2)的影响；多线程被(2)和(5)限制，而线程同步则受到约束(1)和(3)的影响；约束(1)和(5)会影响信号/异常处理功能；进程间通信(IPC)和共享内存受到(3)和(4)的约束；文件和内存映射受到(1)~(4)的约束．下面将详述这些约束带来的影响．2.2　约束影响约束(1)~(5)是经过研究实验得出的关于SGX设计方面的重要结论，也是全面理解SGX与操作系统及应用程序功能之间不兼容或可用性低的重要方式．所有相关的约束都适用于SGX1[4]，(1)~(4)也适用于SGX2[5]，但(2)已经被消除了，因为SGX2新增了动态内存管理机制．下面将逐一解释约束带来的影响．约束(1)．由于SGX对enclave内存进行了空间上的划分，任何与操作系统交换的数据都须要在私有和公共内存之间进行复制．在正常的应用程序中，操作系统假定它可以访问用户进程中所有内存，但这对enclave而言不再是正确的．位于enclave私有内存中的任何系统调用参数都不能被操作系统或主机进程访问．enclave必须显式地管理一份公共和私有副本数据，使其能够被外部访问，并在必要时保护其免受不必要的恶意篡改，这种操作称为双拷贝机制．因此，约束(1)破坏了功能例如系统调用、信号处理、futex锁机制等，同时可能引入非透明性问题(如同步两份数据记录)和安全漏洞(如TOCTOU攻击[22])等．约束(2)．二进制软件可能须要经常改变enclave内存的大小或权限．例如，在动态加载库文件(如dlopen)或数据文件(如mmap)、执行动态生成的代码、创建只读的全零数据段(如bss)以及用于基于软件的安全敏感数据隔离等情况中，内存权限都会发生变化．约束(2)与此类功能严重不兼容．为了维护与(2)的兼容性，应用程序须要小心地改变相应语义，例如削弱安全保护(将读或执行改为读和执行)、使用双拷贝机制或者依靠一些额外的隔离方式(如使用分段或软件插桩等)．约束(3)．SGX没有提供机制允许两个enclave直接共享它们的私有内存．当可信同步机制不存在时，这种约束与锁和共享内存等同步原语是无法兼容的．维护共享锁的2个副本则会破坏其语义，并产生一个鸡生蛋-蛋生鸡的问题：如何在没有另一个可信同步原语的情况下同步这2份数据状态．约束(4)．当应用程序请求创建新的虚拟地址映射时(例如malloc)，操作系统会帮助添加这些映射关系．通常，应用程序可以要求操作系统将几个不同的虚拟地址映射到同一个物理页，或者设置相同或不同的权限等．例如，当同一个文件在同一进程空间的两个地方被映射为只读属性．然而，在SGX上，同一个物理地址不能被映射到多个enclave虚拟地址上．任何这种映射都会触发SGX内存保护错误．约束(5)．SGX只能从预先设置的入口点开始或恢复enclave执行，即必须是静态可识别的虚拟地址．通过系统调用进入/退出enclave的位置，可以通过静态的识别方式获得．然而，当在enclave中运行未修改应用程序时，会出现一些意外的入口点(例如由于异常指令或错误的内存访问)．跨越SGX enclave边界来确定所有潜在的程序位置是困难的．当控制在退出(如ocalls)后重新进入enclave时，SGX要求退出和重新进入时的程序执行环境应该是相同的，但这不符合典型的程序功能．通常，如果程序想执行自定义的错误处理代码，例如在除零操作(SIGFPE)或非法指令(SIGILL)之后，它可以在二进制软件的信号处理函数中利用操作系统设置的上下文信息恢复执行．相反，SGX会从相同的指令和相同的上下文(而不是由操作系统设置的异常处理上下文)中恢复enclave执行．因此，如果处理不当，异常会被重新触发从而陷入死循环．通过理解SGX的异常处理特性[4]，可以实现对各类异常的兼容性．然而，这须要在异常发生前后插入相关逻辑代码来适时地更新异常处理的数据结构(例如SSA及发生EENTER和ERESUME时的enclave栈)．当对未修改二进制软件实施这些改变时，尽管在概念上并非不可行，但却十分复杂．因此，系统设计须要防止覆盖enclave程序中任何预先存在的合法行为，并确保二进制软件所期望的上下文信息保持不变．换言之，二进制软件就像运行在原生Linux环境中一样，能够与操作系统进行正确的交互操作．3 SGX兼容性方案为了实现在SGX enclave中运行应用程序，已有多种不同的方法被相继提出，其中大部分侧重于提供SGX硬件保护的同时以性能为设计主导．一个好的规避性能代价的方法是让应用程序使用规定的程序接口或应用程序编程接口(APIs)，从而提供不同的兼容性，如特定的编程语言[16-17]、容器接口[11]及标准libc接口的特定实现[10，12]．图2为两种不同的模型，包括库操作系统何库函数封装，图中：App表示修改或未修改的应用程序；shim表示轻量级交互接口层；glibc和libc均表示C语言函数库；libos表示库操作系统；Host Process表示主机进程．这些方法的一个缺点是，如果一个应用程序最初没有使用规定的APIs，那么该应用程序须要被重写，或是从源代码重新编译、或使用特定的库重新链接等．此外，enclave程序可能在规定的APIs之外直接调用操作系统的接口如内联汇编代码．图3展示了另一种模型——指令级封装，它可以在接口的最底层(即每条执行指令)进行完全调停或控制，为SGX环境提供一种新的兼容性方案，但无须专门针对特定的目标应用程序或对应用程序的行为进行任何额外假设，图中：musl为轻量级C语言函数库；shield表示安全检查与功能层；DR表示DynamoRIO，即动态二进制翻译引擎；Container表示容器，即轻量级操作系统层虚拟化技术．10.13245/j.hust.240204.F002图2SGX兼容性方法10.13245/j.hust.240204.F003图3指令级封装模型3.1　库操作系统模型库操作系统(Library OS或LibOS)是一个特殊的library，它模拟了一个应用程序进程中所依赖的操作系统功能和APIs．通过将整个库操作系统移植进入enclave内，可以提供良好的兼容性．概括来讲，当二进制程序想要在enclave内运行时，程序开发人员须要将应用程序二进制文件和该文件所依赖的库文件重新链接后一起加载至enclave内，然后在enclave内执行．库操作系统自身实现了传统操作系统中的大部分功能，因此enclave内程序可以节省大部分进入/退出enclave的操作．已有多项研究工作提出了基于库操作系统模型的enclave运行时框架，如Haven[15]，Graphene-SGX[10]和SGX-LKL[29]．该模型中，enclave内包含目标应用程序和与之相链接的库操作系统．库操作系统为传统操作系统在内核模式下实现的大部分功能提供了用户空间的实现．但是一些特权操作仍然须要在处理器supervisor模式下执行，例如与保护和隔离相关的操作：当上下文切换时执行页表切换等．因此，库操作系统须要借助于一个小的特权软件层，使其帮助实现这些特权操作．由于库操作系统包含了传统操作系统的大部分功能例如文件系统和网络管理，因此库操作系统和特权软件层之间的接口通常比操作系统和应用程序之间暴露的系统调用层更小．例如，Graphene-SGX中包含28个(在最新版本中可能更多)不同的操作接口，Haven中包含约20个．当库操作系统须要执行一些特殊指令/操作时(如cpuid和getsec等)，会将控制流转移到特权软件层，让其帮助完成这些操作．a．优点．更简单的enclave交互接口是库操作系统模型的主要优点．这主要归功于库操作系统本身实现了传统操作系统的众多功能，从而大大简化了enclave接口．例如，库操作系统可能在enclave内实现文件系统的重要功能，当控制流到达enclave接口时，任何读写操作均可以被细粒度控制．对于许多系统调用例如getpwd，fcntl，dup，brk在传统操作系统上须要用户空间和内核空间交互完成，但运行于enclave内的库操作系统则无须再进行跨空间操作，甚至不会触碰enclave接口．因为这些系统调用的具体操作可以简单地映射到库操作系统中文件系统相关数据结构的读写、修改等．这些函数调用也不会修改任何其他应用程序的安全敏感状态，更无须特权系统软件的帮助．b．缺点．该模型一个重要的缺点是整个库操作系统须要运行于单个enclave内，这意味着可信计算基(TCB)会变得十分庞大，例如Graphene-SGX TCB高达1.2 MiB左右．因此，整个enclave的攻击面也会随之增大，攻击者有更多机会去破坏隔离执行环境，泄露用户机密数据．例如库操作系统中的某个缓冲区溢出漏洞，将会为攻击者开启代码重用攻击创造有利条件．缺乏灵活性也是库操作系统模型的主要缺点之一．正如基于库操作系统的研究文献所述，整个应用程序运行在enclave内．然而，应用程序开发者可能仅仅想要将部分安全敏感程序代码放入enclave内运行，而非全部代码．例如，对于一个R语言解释器，开发者只想在enclave中执行解释器关键核心代码，而将其余解释器功能运行于enclave外部，进而减少可信计算基代码大小，或者是减少安全内存占用率，提高运行时性能．另外一个缺点是需要复杂的工程努力．不同的enclave应用程序进程之间可能须要相互通信，这将涉及跨越库操作系统的多层通信机制．这种模型使得enclave之间通信变得更为复杂．例如一个enclave内的R语言解释器须要与另一个enclave进程进行通信．由于两个enclave相互不信任，因此不能像运行在相同库操作系统(意味着相同enclave内)中的应用程序一样进行相关操作．每当跨enclave通信时，传递的数据须要穿过每个库操作系统内部软件层，进而被处理．例如，Graphene-SGX实现了enclave组，为enclave之间的父子进程提供安全通信通道．3.2　库函数封装模型库函数封装模型的代表性工作如Panoply[13]，它假设应用程序通过库函数(如标准C函数库libc)来调用系统服务．通常，这些库文件包含了在enclave内无法执行的底层系统调用函数和其他敏感指令操作．Panoply提供了库函数封装接口，使得enclave应用程序能够与之进行链接．这类封装接口确保了库函数代码是从enclave外部被调用，并且enclave接口是面向标准C的库函数．a．优点．当前Panoply是仅有的使用库函数封装模型的系统．与库操作系统模型相对比，库函数封装模型实现了一系列退出enclave的接口，但在enclave内实现的附加功能很少．在Panoply中，标准C库函数在enclave之外执行，但提供了enclave应用程序需要链接的库函数封装接口．这些封装函数简单地将数据进行封装，并传递至enclave外部对应的库函数．由于enclave内的库函数封装器只做了很少的数据封装和解封装工作，从而大大减少了enclave内可信代码，使得TCB变得很小．应用程序开发者可以灵活地决定将哪些安全敏感函数放在enclave内执行，所有enclave代码被视作一个单独的模块来执行，并通过跨模块调用实现函数之间相互调用．Enclave应用程序代码本身很容易产生，只须将函数模块与Panoply库封装器链接起来即可．b．缺点．库封装模型最明显的一个缺点是，在enclave之外执行的库函数代码是不可信的，因此可以被攻击者利用来破坏enclave应用程序的机密性和完整性，例如通过类Iago攻击．由于库封装函数接口十分庞大和复杂，因此防御此类攻击变得更具挑战性．此外，标准C库文件包含上千个函数接口，该接口也会随着新功能的加入而不断增加、修改、删除等．文献[30]研究了超过10个版本的glibc库文件，并统计了API函数数量，发现不同版本中会有一些API被新增或删除．因此，基于库函数封装模型的SGX框架例如Panoply必须手动适配或修改不同版本的库文件．值得注意的是，可移植操作系统接口(POSIX)、国际标准化组织(ISO)等标准仅仅规定了库文件的函数调用接口，但是没有规定某些数据结构的定义．这些数据结构可能在不同的库版本中也有所不同，但是它们的接口仍然符合POSIX或ISO标准．当适配SGX环境时，数据结构的变化意味着须要修改相应的库函数封装结构，确保可以将数据结构进行正确封装或解封装，使得enclave内部或外部操作可以正确执行．例如，Panoply不支持file类型结构，任何使用该file类型的应用程序代码必须先被转化到SGX支持的数据类型如long类型，然后再将其翻译到库文件中正确的file数据结构．除了庞大的封装接口，Panoply系统还须要修改目标应用程序代码，确保相应的库函数封装被正确调用．换言之，应用程序对库文件中函数的调用必须被修改为对Panoply库文件的调用．根据Panoply作者对论文中提及的基准测试应用程序的统计，大约须要修改1 000行代码．尽管修改应用程序确实给enclave软件开发者带来了很大工程压力，但这些工程努力也一定程度上提高了enclave运行时性能．3.3　指令级封装模型指令级封装模型中，主要是为enclave内禁止执行的底层指令例如cpuid，rdtsc，syscall等提供封装函数．这些封装结构包含跨越enclave边界的安全规则，以确保数据的安全性．当数据离开enclave时，该模型可以提供加密服务；当进入enclave时，实施解密操作．在该模型中，enclave接口是一套指令级封装接口，主要用于拦截被SGX禁止的特殊指令，然后传递控制流和相应参数至enclave外部再进行相应操作．原始目标应用程序代码中很少出现直接调用底层特殊指令，而是依靠库文件来执行各种系统调用，所以指令封装接口可以通过修改标准C库文件内部实现来达到相应目的．SCONE[11]，RATEL[9]等是基于该模型实现的SGX框架．指令级封装模型提供了一种更细粒度的enclave接口控制方式，比库操作系统模型和库函数封装模型更具灵活控制能力．图3展示了两种不用的指令级封装模型方法．这类方法不止可以拦截特殊指令，也可以“透明”地拦截每一条目标程序指令例如RATEL(图3(b))，对其进行安全检查、动态分析等．指令封装函数对调用函数参数进行封装，并将其转发至enclave外部对应的函数接口，该接口负责真正调用系统服务或执行该指令，并将结果封装后返回到enclave内．与库封装模型相比，指令级封装操作发生在更低一级的抽象层，并且更靠近enclave边界，例如对寄存器参数和内存等的操作．a．优点．理论上，通过使用指令级封装接口可以替换enclave代码中任意指令的调用，从而可以支持在SGX上运行任意二进制程序．文献[11]中指出应用程序很少以原始形式直接执行指令来完成操作，而是倾向于调用相应库函数接口，间接执行底层指令．因此，它将这类指令封装在相应库文件中，应用程序只须简单地链接这些库文件即可使用对应的指令封装接口．通过在更底层实现封装接口(即封装指令而非提供库文件调用封装接口)，意味着该封装接口工作在一个更稳定的接口之上．例如syscall指令通常被用来实现系统调用，对于每个syscall的指令封装结构，视调用的系统调用参数及类型，其指令封装接口也各不相同．根据文献[30]调研，相比于glibc接口，Linux系统调用接口在不同内核版本中变化很少，相对更稳定．指令级封装模型中，应用程序依赖的标准C库文件运行于enclave内部，而库函数封装模型则是在enclave外部．因此，指令级封装模型的TCB要比库封装模型更大、更重些．指令级封装模型中可以灵活地添加一层薄的安全检查程序，防止类Iago攻击对指令返回接口进行恶意操作．相比而言，该模型无须或很少须要对应用程序进行侵入性修改，进而启用SGX enclave的安全保护．然而，一些底层的安全自省、监控、优化程序等可以被灵活地添加，帮助进一步提高应用程序的安全性、性能、兼容性/可用性等．a．缺点．指令级封装模型的首要开销是较大的TCB，它比Panoply更大，但仍然比库操作系统模型小得多．另外，应用程序可能须要重新链接新的指令级封装库文件例如SCONE，但这种操作不是必须的．例如RATEL，它在enclave内提供了一个指令级动态翻译引擎，可以动态翻译和执行目标二进制应用程序的每一条指令，并将须要调用系统服务的指令转移至enclave外部执行，完成操作后返回enclave内继续运行．该过程中，RATEL无须动态或静态链接任何库文件，可以直接将未修改应用程序运行于enclave内，提供安全保护．3.4　SGX兼容性方案比较表1展示了当前比较流行的几个SGX运行时框架，它们分别提供不同级别的兼容性保证．10.13245/j.hust.240204.T001表1SGX兼容性方案及案例模型方法源码级兼容二进制级兼容库操作系统模型Occlum[12]Haven[15]，Graphene-SGX[10]库函数封装模型Panoply[13]—指令级封装模型SCONE[11]RATEL[9]3.4.1　源码级源码级兼容性主要是基于编译器的解决方案，须应用程序修改源代码或者使用高级语言重新编写程序来适配SGX[8-17]．Intel官方提供了一个基于C/C++的SGX编程软件栈，其中包括用于管理或操作SGX硬件的SDK和驱动，以及用于运行本地enclave的平台软件PSW．此外，开发人员也利用侧重于内存安全的Rust语言开发了Rust SGX SDK[31]．一些框架诸如Asylo[8]和Open Enclave[14]等为使用通用接口编写本地TEE应用程序提供了一个高级的前端系统，其中一些甚至可以支持不同的后端TEE如Intel SGX和ARM TrustZone．3.4.2　二进制级目前已有相关工作针对SGX与二进制软件兼容性做了深入研究．主要思路是通过重新编译或者重新链接目标应用程序来适配SGX接口，从而修复应用程序接口．因此，通过暴露特定版本的libc (glibc或musl libc)作为交互接口，既能支撑运行在它们上面的应用程序也保证很好地适应底层SGX约束并提供最佳兼容性．容器或库操作系统解决方案(如Haven[15]，SCONE[11]，Graphene-SGX[10]，SGX-LKL[29]和Occlum[12])利用该方法在enclave内执行经过重新编译/重新链接的代码．大部分源码级和二进制级兼容性解决方案可以提供较好的运行时性能，但是须要重新编译或重新链接目标应用程序．例如Graphene-SGX利用库操作系统、SCONE利用容器化引擎，两者均依赖于一个特定的glibc或musl libc版本，导致应用程序无法自由选择链接或者使用其他类型的库函数或者更高版本的库函数等，造成了对底层平台接口提供者的依赖，为后续升级带来二次不兼容甚至须要重新移植．此外，使用内联汇编或动态代码生成的应用程序也变得不兼容，因为它们直接访问系统调用指令，而不是通过API调用．4 SGX攻击、防御与检测尽管基于Intel SGX的安全解决方案已经被广泛应用在各大云产品服务中，例如AWS云，Google Cloud，Alibaba Cloud等，但是SGX可信计算技术及其运行时框架可能仍然存在安全漏洞．攻击者可能很难正面对抗SGX enclave环境并窃取受保护的隐私数据，但可能利用可信计算技术中侧信道攻击(如CPU缓存、分支预测)、硬件漏洞(如RowHammer攻击)、运行时框架漏洞(如ROP攻击)、交互接口漏洞(如原子性违背)等方面对SGX发起攻击，从而完全破坏可信硬件提供的机密性和完整性保证．已有大量研究从不同攻击面探索了SGX安全性，证明了漏洞的真实性和危害性．本研究深入调研SGX安全相关问题，并进行了分类汇总，具体如表2所示．10.13245/j.hust.240204.T002表2基于英特尔SGX的安全漏洞分类总结漏洞分类相关成果发表情况交互接口安全COIN Attacks[19](ASPLOS'20)，Iago attacks[25](ASPLOS'13，非SGX攻击)，A Tale of Two Worlds[20](CCS'19)，SmashEx[28](CCS'21)可信代码漏洞(内存安全、线程同步、状态延续)The Guard's Dilemma[23](Security'18)，AsyncShock[22](ESORICS'16)，Game of threads[26](ASPLOS'20)，State Continuity[32](Secuirty'21)，Controlled Data Race Attacks[33](Secuirty'23)侧信道攻击/硬件设计安全(基于页表、基于缓存、瞬态执行)Controlled-channel Attacks[21](S&P'15)，Leaky Cauldron on the Dark Land[27](CCS'17)，SgxPectre[34](EuroS&P'19)，Branch Shadowing[35](Security'17)，Foreshadow[36](Security'18)，LVI[37](S&P20)硬件缺陷SGX-Bomb[38](SysTEX'17)SpecHammer[39](S&P'23，非SGX攻击)4.1　交互接口安全enclave软件可能须要依赖非enclave软件(如操作系统)提供的服务，如系统调用和接收信号等．SGX硬件同步和异步两种接口，用于在操作系统和enclave之间切换．SGX运行时软件通过ecall和ocall接口为enclave应用程序提供了一个函数调用机制．具体来讲，ecall是进入enclave去调用可信函数的操作，而ocall是退出enclave去调用不可信函数的操作．攻击者可以通过提供恶意的系统调用返回值来破坏enclave的机密性和完整性，这类攻击被称为Iago攻击[25]．要消除这种威胁，须要enclave软件借助形式化验证[40]，对传递到enclave中的系统调用返回值进行严格检查[11，13]．此外，enclave运行时可能忘记在上下文切换到enclave后清理某些寄存器，从而使enclave受到攻击[20]．文献[20]证明应用程序二进制接口(ABI)和API接口存在重要安全问题，由于没有安全管理/清除接口数据，导致攻击者可以偷取enclave秘密．COIN Attack[19]通过扰乱ecall调用顺序来触发Use-After-Free漏洞，进而可能导致控制流劫持攻击．SmashEx[28]是一个最新的接口调用攻击，研究发现了异步异常处理过程中enclave边界存在原子性违背安全问题，可引发严重的可重入漏洞，导致enclave内任意代码执行和任意私有数据被读取．接口调用漏洞存在的根本原因是enclave内用户代码须和外部不可信代码进行交互需求导致的．基本上绝大多数用户软件都须要依赖系统服务或者访问系统资源来完成相关任务，因此SGX enclave受到严重的接口调用安全威胁．4.2　可信代码漏洞4.2.1　内存安全与传统软件一样，受SGX硬件原语保护的可信软件也可能存在内存安全问题．通过构造恶意输入到enclave环境，攻击者可以开启enclave内控制流劫持攻击，结合面向返回编程(ROP)漏洞利用方法，攻击者可以实现任意代码执行和任意内存泄露目的，甚至绕过精心布置的内存防御机制例如栈溢出保护stack canary．在SGX环境下，内存漏洞发生的主要原因是可信软件缺少正确的安全检查或者存在逻辑处理错误．因此，在机密计算中，面向内存安全的编程是避免此类威胁的重要对抗措施．SGX安全模型中，它不信任任何系统软件(特权或非特权)、固件、外围组件等模块，可以抵御不同权限的敌手．但是，和传统操作系统中类似，攻击者也可以利用侧信道方法执行辅助攻击，窃取其安全内存中秘密信息，例如安全内存布局信息，进而破坏地址空间随机化防御机制．根据研究表明，为整个SGX软件栈启用地址空间随机化是具有挑战性的．SGX-Shield[41]仅仅为enclave内用户应用程序代码启用地址随机化(ASLR)，但是没有对SGX依赖的SDK代码(可信部分)也进行随机化保护，因此攻击者可以利用未随机化的代码片段实施ROP攻击．The Guard's Dilemma[23]正是利用了这一安全问题，成功泄露了enclave内秘密数据．4.2.2　线程同步多线程应用程序中经常存在一类同步逻辑漏洞，导致线程违反数据访问的一致性，也称竞争条件．线程同步漏洞可能会概率性发生，具体视同步窗口时间长短．例如较长的同步窗口，引发竞争条件的概率会增大；反之，概率会变小，可能运行许多次之后才会发生．在SGX设计中，线程调度器仍然由操作系统管理，攻击者可以任意地操纵时钟中断来恶意打断enclave线程运行，触发同步漏洞．一个同步窗口十分小的竞争条件漏洞在SGX环境中可能被进一步恶化，使得窗口被任意放大，加大增加竞争条件机会，进而更容易被攻击者利用．Game of Threads[26]通过操纵线程调度，恶意操作系统能够稳定地利用enclave应用中有漏洞的线程同步逻辑．例如，对于没有频繁执行线程同步的机器学习训练工作负载，恶意调度可以降低精度，使模型出现偏差．AsyncShock[22]假设两个或多个enclave线程之间的同步逻辑(例如使用互斥锁mutex)是有漏洞的．基于该同步逻辑漏洞，通过利用enclave内Use-After-Free (UAF)漏洞，攻击者可以实现控制流劫持攻击；通过利用enclave内TOCTTOU (time-of-check-to-time-of-use)漏洞，攻击者可以轻松绕过某些安全检查(例如某关键寄存器值有效性检查)．文献[33]研究了英特尔SGX中的一种新型攻击向量，它是由非重入式enclave代码引起的，并允许攻击者触发一个受控的数据竞争；该研究也提出了一个基于二进制分析的工具来检测此类攻击．4.3　侧信道威胁正如传统CPU架构，一个机器中的所有软件都共享CPU微架构层的资源，例如地址翻译、分支预测器、CPU缓存等组件，以及架构内部各种缓冲器例如分支目标缓冲器(BTB)、返回栈地址缓冲器(RSB)等．这些共享资源会导致复杂的内在关联，例如某个特定指令的执行会引发资源访问冲突或错误等不良结果，进而使得攻击者有机会推测原始输入．此外，现代处理器为了在架构层面实现优化或提升性能，经常引入新的硬件机制．例如，为了增加CPU指令并行执行速度，CPU在微架构层面实现了指令的预测执行和乱序执行．当某一条指令被执行时，它在CPU中执行的逻辑顺序可能与实际顺序完全不同．某些情况下，攻击者可以将正常情况下不可访问的秘密数据以瞬态方式加载到缓存中，尽管CPU检查失败后会执行回滚操作，但微架构不可见的缓存状态不会被立即彻底清除，因此攻击者可以通过缓存时间侧信道攻击恢复秘密数据，从而造成瞬态执行漏洞．SGX环境中同样存在相似资源共享和微架构优化机制，即enclave软件和外部不可信软件共享CPU微架构的硬件资源．攻击者可能利用侧信道来推测enclave软件的内存访问模型、分支预测等信息，最终获得enclave私有数据信息．此外，按照目前SGX硬件架构定义，特权软件依然保留对进程虚拟地址空间的管理权限，即对页表的操作权限．如果进程空间中存在一个SGX enclave，操作系统可以通过操作对应的页表项来观察enclave中代码和数据在页面粒度的踪迹．已有攻击证实可以从这些粗粒度的地址信息中获知应用程序的数据位置，并基于此来泄露细粒度机密信息[25]．如果SGX enclave可以为自己的页面错误提供服务，那么此侧信道将消失．Foreshadow[36]通过清除映射到enclave秘密数据的页表条目中的“present”位来引发一个页面故障，造成瞬态执行来泄露秘密．Intel处理器自身设计无法预防侧信道攻击，而基于该类CPU的SGX可信计算技术目前仍然无法幸免．因此，预防侧信道是安全处理器设计中最关键的环节，且极具挑战性．4.4　硬件缺陷硬件自身安全是任何安全机制最根本的保障．一旦硬件自身存在重大缺陷，整个系统的安全性可能被破坏．不论是在传统CPU还是安全CPU中，硬件自身问题通常很难被发现，同时也很难在软件层面进行预防，通常须要更换新的硬件组件才能彻底根除．一个典型的硬件漏洞，如Rowhammer攻击[42]，它通过频繁访问一个内存行来引起相邻行的位翻转，从而破坏数据和代码的完整性，与Spectre组合可以进一步增强推测执行攻击[39]．SGX-Bomb[38]提出了基于软件的攻击来破坏enclave完整性，它通过重复访问发生冲突的行地址，引起enclave内存位发生任意位翻转，导致enclave内存访问完整性检查失败，从而引发处理器被锁定，这类攻击对云服务提供商而言是极具威胁的．4.5　SGX安全检测已有研究从不同方面探讨了SGX的安全检测，但是它们采用的方法存在不同程度的利弊权衡．SMILE[43]提出了一种安全的enclave运行时内存自省方法．它通过平台硬件辅助特性——系统管理模式(SMM)提供自省代理，构建系统限制执行环境，并在enclave中引入内部自省模块，从而实现enclave内存运行时的可信自省功能，例如读取enclave代码、堆和栈内存及SSA栈帧．然而，当需要自省数据量很大时，该方法将引起极大的硬件资源开销，因为SMILE须要在自省过程中停止其他的CPU core，以保证当前自省过程的安全性．TeeRex[24]是利用符号执行方法对主机(host)到enclave边界的内存安全问题开发了一套自动发现漏洞工具，但其只能针对于enclave中代码的特定部分进行安全检查(enclave代码中的特定漏洞进行安全检查)，无法对enclave内二进制程序使用中内存进行检测．另外，最近提出的SGXFuzz[44]，是一种基于覆盖指导的模糊测试器，它提出了一种二进制输入结构合成方法，即使在没有源代码访问的情况下也能暴露enclave漏洞．但此类方法存在以下不足：a．它在非enclave环境中模拟了enclave执行时必须的所有条件(提取enclave代码到外部运行)，然后执行模糊测试，因此缺少真实运行和测试环境；b．仅对ecall执行路径进行了分析，未对ocall进行分析；c．已有方法对enclave中运行的二进制程序无法进行动态、实时监测，因此真正意义上的enclave内动态安全检测方法还未被完全研究，即为enclave内二进制程序提供动态安全检测能力，例如内存错误、并发错误检测等．5 SGX性能瓶颈SGX在执行enclave代码时会产生各种性能开销．a．由于特权指令不能在enclave内执行，线程必须在系统调用之前退出enclave．这种enclave与非enclave之间的上下文切换是有代价的出于enclave自身安全考虑，必须进行一系列检查和更新操作例如刷新旁路转换缓冲器(TLB)．基于内存的enclave参数(例如系统调用参数)也必须在可信和不可信内存之间进行复制．b．enclave代码须要为内存写入和缓存未命中付出代价，因为MEE (memory encryption engine)必须对缓存中数据进行加密和解密．c．当enclave程序内存需求超过EPC (enclave page cache)自身大小时，SGX必须在EPC和不受保护的DRAM之间进行页面交换．驱逐EPC页的成本很高，因为数据在被复制到外部DRAM之前必须进行加密和完整性保护．为了防止地址转换攻击，驱逐算法会中断所有enclave线程并刷新TLB．已有相关工作通过修改符合enclave的库函数接口来实施优化．HotCalls[45]观察到SGX SDK提供的ecalls和ocalls有很高的性能开销，大约在8×103~1.7×104个CPU周期之间(视缓存状态)．HotCalls提出了一个新的异步设计，使用一个共享的缓冲区将这个开销降低到620~1 400个CPU周期．此外，新版本的Linux SGX SDK中引入了一个类似的功能叫Switchless[6]．Eleos[46]是另一个相关工作，它增加了无退出调用，以减少ocalls开销．6 SGX研究总结、方向及趋势6.1　研究总结基于Intel SGX隔离执行环境的研究已获得了重要经验，主要涉及兼容性/可用性、性能、可信计算基和微架构侧信道威胁四个方面．a．共享内存．正如第1节中所描述，SGX预留了一块连续的DRAM内存，称为处理器保留内存(PRM)．它包含由4 KiB页组成的enclave页面缓存(EPC)，用于存储enclave代码和数据．Intel CPU保护它们不被所有非enclave程序访问，例如操作系统内核、管理程序等；只允许从非enclave软件访问非PRM内存的操作，也允许从enclave内部访问非PRM内存．上述约束为SGX enclave提供了安全隔离保证．因此，SGX设计中不存在一个可共享的专用内存区域，以便在多个enclave之间或enclave与非enclave软件之间相互通信．一个简单的案例是，在enclave初始化期间，系统软件须要从非EPC页复制数据到EPC页，从而将应用程序初始代码和数据加载到新创建的enclave内，但该操作会引起极大地的性能开销．另一个例子是，由于可信与不可信世界之间缺乏可共享的安全内存，对于须要短暂且频繁交互(通过EENTER和EEXIT)的工作负载，SGX软件必须在enclave和非enclave内存之间执行浅拷贝或深拷贝，但会增加额外开销．事实上，视不同的工作负载，其运行时性能可能大不相同．因为，一些工作负载可能触发多个性能瓶颈，导致累加的代价变得更大．此外，原始用户应用程序中关于共享内存的操作，SGX enclave无法正常提供，造成了不兼容性．b．空间隔离．Intel SGX的核心思想是为每个enclave提供隔离，同时也确保与外部世界及其他enclave相互隔离．这种设计理念从安全角度考虑是很好的，但从应用程序的兼容性、表达性或可用性角度考虑是不足够的．下一代TEE应该为用户程序提供灵活性，让开发者可以在严格的安全约束、更好的性能及更丰富的表达性之间做出选择．例如，可以允许程序根据需要将私有enclave页转换为非私有．Intel SGX当前架构实现不允许在enclave整个执行生命周期内将私有页转换为非私有页．此外，在SGX威胁模型中，假设主机软件(例如操作系统)是脆弱的且容易被破坏．因此，作为SGX实现的一部分，操作系统内核可能会故意拒绝调用CLFLUSH指令，使其无法从cache中冲刷enclave相关的代码页和数据页，从而很容易受到缓存定时攻击或侧信道攻击等．相反，系统内核可能频繁执行CLFLUSH指令，导致cache中的enclave页面被驱逐然后再次加载，造成重大性能损失．c．上下文切换开销．许多真实应用程序很大程度上依赖于操作系统提供的系统调用服务．尽管SGX不允许在enclave内直接执行系统调用，但可以通过它提供的ocall接口间接调用系统服务．当enclave代码须要请求系统服务时，一个ocall操作将被执行，同时会将系统调用参数从enclave私有内存复制到非私有内存中，然后在完成调用后执行ecalls重新进入enclave．然而，在一些系统调用中，如果参数包括指针和嵌套的数据结构，那么用户程序可能须要自己实现深拷贝操作．尽管当前新版本的SGX SDK已经支持了递归复制参数数据，但所引起的性能开销是相似的．由于ocalls和ecalls须要在enclave-OS之间来回切换，大量的参数数据拷贝以及运行时软件对enclave和非enclave上下文保存与恢复等操作将会对系统性能产生很大的损害．上述问题例如共享内存、空间隔离、上下文切换成本等，不同程度地损害了基于SGX的安全系统性能、安全性和兼容性等．目前一些相关优化方案已被提出．例如，可以使用HotCalls[45]等机制来缓解昂贵的上下文切换开销．该机制通过在enclave内外分别创建工作线程异步地执行函数调用，避免了enclave频繁地切换，从而为应用程序和enclave代码之间提供了一个快速的调用接口．此外，EPC内存到随机存取存储器(RAM)内存的交换也是主要开销之一，可以通过最小化enclave大小(TCB)来减少enclave初始化和运行时的页面交换，从而改善性能；另一方面，通过改进相关设计算法，在空闲EPC较少时更智能化选择须要驱逐的EPC页面，可以降低EPC页面交换开销．6.2　研究方向及趋势a．设计更有效的TEE环境安全检测方法．TEE有多种实现技术，例如利用Intel SGX，ARM TrustZone，AMD SEV等技术均可创建一个可信执行环境TEE．针对不同的可信计算技术和差异化的平台设计，不同的可信计算技术可能隐含新的攻击向量．因此，根据目标平台和使用的可信计算技术，一方面，研究其已有单一攻击向量特征，综合评估工业界和学术界对各种不同攻击向量的检测方法，进一步优化其检测速度和精确度；另一方面，探索新型攻击向量，评估其安全攻击属性，设计和开发相应的检测技术．从单一到多元攻击，集成多样化攻击检测属性，从而形成能够高效、有效地检测多元攻击向量的方案，最大化排除TEE可能受到的攻击与危害．b．研究可信硬件设计方法，从源头减少攻击面．在可信硬件设计上加大研究投入，尽可能保证底层设计思路和逻辑的可信性、一致性和完备性等，是可信计算技术的重要基础保障．然而，硬件设计十分复杂，极具挑战，可能带来不可避免的缺陷，存在一定的利弊权衡．此外，随着新的SGX攻击面被不断发掘，从单一的攻击方式到综合运用多元攻击方式的组合实现混合多层次攻击也成为攻击者的重要手段．综合考量各种攻击向量特性，特别是侧信道类攻击，深入理解攻击成功的关键要素，构思阻止信道泄露信息的硬件设计(如增加可信的时钟、可信的原子性保证等)，从单一信道到多重信道、从简单到复杂，整合安全防御设计思路[41，47-49]，尽可能减少所有已知和未知攻击面，综合评估设计的兼容性、性能、安全、可扩展等问题，创造切实可靠、符合标准的可信硬件处理器．c．研究可信软件设计方法，进一步减少攻击面．可信的硬件需要可靠的软件来驱动和支持，在充分理解可信硬件技术的基础上，开发高质量、无漏洞的软件程序，是可信计算技术的重要条件．然而，各类开发商根据已有可信硬件技术和自身需求开发安全系统框架并部署到各种机密计算平台，导致基于该类可信硬件的隐私保护框架安全性层次不齐．这类安全威胁主要来源：一方面，安全框架设计与实现各有不同，可能存在设计缺陷；另一方面，软件开发者水平参差不齐，可能引入新的软件漏洞．开发安全的软件程序，须要对可信硬件技术的全面理解．此外，受保护的用户程序也可能包含安全漏洞，导致降低甚至完全破坏TEE硬件安全保证．因此，加强对可信计算技术的理解及可信软件生态建设，持续研发高安全性、高兼容性、高性能等特点的可信计算系统框架和可信软件程序．d．研究软硬件协同设计方法，全面提升TEE．Intel SGX技术展现了诸多硬件设计约束，导致它在安全性、扩展性、兼容性和性能等关键属性中存在重要的权衡利弊．此外，目前流行的其他TEE技术例如ARM TrustZone，AMD SEV和RISC-V Keystone等针对不同架构提出了相应的可信计算技术，同样存在不同程度的安全、性能等重要问题，并且它们都是商用未开源的；而Keystone[50]是基于RISC-V架构的开源TEE，它为新一代TEE技术的发展做出了重要尝试．但由于RISC-V架构还未被广泛商用，因此基于它的TEE技术将会继续更新迭代，例如Penglai TEE[51]．相信借助开源安全社区的影响，开源架构的TEE会是未来许多用户的首要选择．总之，通过结合已有各类TEE技术研究经验，进一步学习探索更安全、更轻量、高性能、更灵活、更具扩展性和兼容性的可信CPU技术，是未来安全处理器技术的重要发展趋势．e．研究TEE兼容性/可用性方法，拓展应用场景．由于Intel SGX硬件设计约束，使得某些指令无法在enclave中运行，例如无法执行系统调用等．然而，传统应用程序可能包含许多此类指令，以便在用户空间中调用内核服务．普通用户想要使用SGX安全保护，必须了解SGX开发流程并遵守这些限制，同时还须要保证敏感数据的机密性和完整性，这严重阻碍了TEE技术的应用．此外，若用户须要将传统二进制应用程序运行于enclave中，则要根据规则改写或重新代码．第3节列举了现有SGX兼容性/可用性解决方案，但此类方法仍然在性能、安全性等方面存在不同程度的弊端．文献[30]表明并没有一种兼容性模型能够全面兼顾，在选择模型时往往须要根据实际对性能和开销进行权衡．因此，开发一个可用性强的TEE兼容性框架将是一个持续的研究课题．f．研究TEE内存管理优化方法，提升系统性能．Intel SGX在提供机密性和完整性保护的同时也产生了较大的性能开销．主要来源进入和退出enclave产生的模式切换、内存的加密解密和enclave页面的替换三方面[52]．在访问内存时产生的高性能开销，使得SGX很难在保证完整性的同时支撑较大容量的安全内存，从而限制了SGX的广泛应用．因此，应尽量避免进行模式切换，可以采取异步调用的方式；加密开销的根本原因是由于内存加密保护机制所致，结合硬件加速或使用高效的数据结构存储，降低加解密的开销；通过优化内存的管理机制，或预加载EPC页面来尽量避免页替换．综上，研究TEE内存优化方法，提升系统整体性能，使得TEE在更复杂的场景中获得广泛应用是一个重要的方向．7 结语Intel SGX提供了一个硬件辅助的高安全隔离执行环境，但由于自身设计约束导致在兼容性/可用性、性能和安全性等方面存在重要权衡．本研究总结了五个SGX自身设计约束，系统地分析了引起SGX与二进制软件和运行时语言不兼容的根本原因．然后，阐述了解决SGX兼容性问题的三种解决方案，分析了它们的优缺点；总结了SGX面临的安全问题，对攻击方法进行了分类，概述了攻击关键要素和根本原因；分析了SGX性能瓶颈，总结了制约enclave运行性能的主要因素．最后，描述了SGX研究经验教训，展望了新一代TEE技术的研究趋势，指出了若干研究方向．