Position Paper: Challenges Towards Securing Hardware-assisted Execution Environments【TEE安全综述】

作者：Zhenyu Ning, Fengwei Zhang, Weisong Shi, and Larry Shi
发布：HASP
时间：2017

这篇文章比较早，但是描述TEE可能面临的问题比较全面。入坑TEE的小伙伴可以看看~
1、TCB对于TEE安全的重要性，越大越不安全
2、封闭也意味着不安全，对手可利用TEE不被检测这一特性实现更高级别的隐形rootkit

摘要

可信执行环境（TEE）为敏感工作负载提供了一个隔离的环境。但是，TEE中运行的代码可能包含漏洞，攻击者可以利用这些漏洞进一步破坏TEE。TEE内部不断增加的bug代码关系到整个TEE的安全。在这份立场文件中，我们提出了确保可信执行环境和潜在缓解措施的挑战。

引言

近年来，可信执行环境（TEE）已被广泛应用于商品系统中，以增强软件执行的安全性。这种方法在受信任的环境中运行安全敏感的工作负载，并保证工作负载的所有运行状态与潜在的受感染环境（例如，操作系统或系统管理程序）隔离。TEE的示例包括但不限于：Intel Software Guard eXtensions（SGX）[6，27，46]、AMD Memory Encryption Technologies[21]、ARM TrustZone Technology[7]、x86系统管理模式[30]、AMD平台安全处理器[5]和Intel管理引擎（ME）[53]。尽管这些精心设计和硬件辅助的TEE提供了安全的执行环境，但其中运行的代码可能存在漏洞，这导致“可信”执行环境（TEE）不可信。而争论的焦点是TEE中工作负载的代码库足够小，因此存在易受攻击代码的风险很低；然而，由于软件的复杂性不断增加，以及在商品系统中使用TEE的激增，开发人员不断增加TEE中代码的大小（例如，操作系统运行在TrustZone[8]中，系统管理程序部署在SMM[12]中，Linux容器运行在SGX[9]中）。TEE中工作负载的庞大代码库不可避免地会产生可利用的漏洞攻击者。即使TEE的安全设计和实现是完美的（例如，完美的隔离和安全的架构设计），我们也无法防止由于部署的错误代码而引起的攻击。更糟糕的是，TEE的安全功能可能会帮助攻击者。利用这些安全功能，攻击者可以实现更高级别的隐形rootkit，这极难被现有的防御工具检测到。例如，操作系统中运行的防病毒工具无法检测Intel SGX创建的Enclave中的恶意代码，因为Enclave的运行内存是加密的。基于SMM的rootkits[1]已被国家安全局用作隐形网络武器。此外，ring-3rootkits[71]已经通过使用IntelME进行了演示。因此，在可信执行环境中运行不可信代码引起了很大的安全问题。此外，由于现有的防御机制无法直接应用，这可能会产生一系列的研究挑战。本文的主要目的是提出这个问题，讨论研究挑战，并提供解决这些挑战的潜在方向。

问题陈述：不同的平台都引入了可信执行环境来保护软件执行，但实现安全不仅取决于执行平台本身的技术（例如，小TCB、强隔离），还取决于执行的代码。目前最先进的可信执行环境研究缺乏验证执行代码的框架、可信环境中的防御、检测受损TEE的方法以及TEE攻击响应的缓解计划。

为了进一步保护可信执行环境，我们考虑了以下研究挑战（RC）。

RC1：TEE代码中的Hunting Bugs

TEE中运行的软件可能包含缓冲区溢出等文本书漏洞，因为该软件可能由粗心的程序员或第三方开发人员编写。如果我们有软件的源代码（例如，SGX应用程序），我们可能能够使用现有的静态分析或错误检查工具来识别漏洞，并最大限度地减少软件中的错误数量。这意味着，我们需要修改这些工具，使其适用于特定环境的应用程序（例如，SMM或TrustZone代码）。此外，在某些情况下，我们可能没有源代码，而不是TEE的二进制图像（例如，SMM代码）。在二进制图像中寻找bug是非常困难和耗时的。此外，由于供应商的硬件保护，其他TEE的图像（如ME的代码）可能不可用[66]。

RC2：TEE内的保护机制

软件要有完美的代码而没有任何漏洞是不切实际的，分析系统（例如RC1）也不能保证它们能识别所有漏洞。因此，我们有必要在TEE中进一步发展防御机制。在正常环境（如操作系统）中，我们有一系列防御机制，如数据执行预防（DEP）和地址空间布局随机化（ASLR）。然而，这些防御机制在当前的TEE中是缺失的，相反，我们认为这些环境比操作系统环境更安全。TEE通常具有专用资源、有限的软件库，并且是特定于硬件的，但最近的研究表明，TEE中添加了更多的防御机制（Intel SGX中的ASLR[60]）。

RC3：检测受损TEE

如前所述，TEE可能会因其文本书漏洞或其他攻击而受损。然而，检测受损的TEE是具有挑战性的，因为TEE的存储内容要么是加密的，要么是从外部无法访问的。例如，英特尔SGX在飞地中对其代码和数据进行加密；SMM和TrustZone代码不可由系统软件（例如OS）访问。一方面，由于这些“保护”功能，TEE可以实现强大的安全保障。另一方面，在破坏TEE后，攻击者可以在其中实现无法检测的秘密rootkit（例如，基于SMM的密钥记录器[24]）。虽然将TEE提供为一个强大的隔离环境，但拥有检测受损TEE的方法是一项具有挑战性的任务。

RC4：TEE的修补和再生

在检测到受损的TEE后，至关重要的是减轻攻击并在TEE中恢复到健康状态。然而，如果TEE被破坏，则很可能系统软件也是恶意的。因此，在系统软件中运行的修补过程是不可信的。此外，TEE通常具有高特权并且是硬件专用的。开发从干净副本快速恢复受损TEE并修补易受攻击图像的方法具有挑战性。

背景

在本节中，我们将解释不同的受信任执行环境。我们将它们分为三种类型：
1）通过存储器加密实现的ring 3 TEE；
2） 通过内存限制实现的ring -2 TEE；
3）通过协处理器实现的ring -3 TEE。
接下来，我们将使用现实世界中的技术来描述这三种类型的TEE。

通过内存加密ring 3 TEE

SGX

2013年，英特尔发表了三篇关于软件保护扩展（SGX）的介绍论文[6，27，46]。英特尔SGX是添加到英特尔体系结构处理器中的一组用于内存访问的指令和机制。这些扩展允许应用程序实例化一个受保护的容器，称为飞地。飞地可以用作TEE，即使不信任BIOS、固件、管理程序和操作系统，也可以提供机密性和完整性。一些研究人员认为SGX是新一代TXT[20，54]。英特尔SGX是值得信赖的计算的最新迭代，未来所有英特尔处理器都将具有此功能，并将其用作解决安全问题的TEE。然而，研究人员对此提出了安全担忧。最近，Costan和Devadas[20]发表了一项关于SGX的广泛研究。他们分析了SGX的安全特性，并提出了缓存定时攻击和软件侧通道攻击等问题。此外，ISCA 2015[31]中的SGX教程幻灯片提到，SGX不能抵御软件侧通道攻击，包括使用性能计数器。Jain等人[33]开发了OpenSGX，这是一个开源平台，通过修改QEMU在指令级模拟Intel SGX硬件组件。

AMD内存加密技术

最近，AMD在ISCA 2016和USENIX Security 2016教程中引入了两个新的x86功能[39，40]。其中一个功能被称为安全内存加密（SME），它定义了一种新的主内存加密方法。另一种称为安全加密虚拟化（SEV），它与现有的AMD-V虚拟化架构集成，以支持加密虚拟机。这些功能提供了选择性地加密部分或全部系统内存的能力，以及运行与系统管理程序隔离的加密虚拟机的能力。AMD SME是与英特尔SGX竞争的技术，他们通过内存加密提供ring 3 TEE。除了ring 3 TEE，AMD内存加密技术还可以提供其他系统级TEE（例如，系统管理程序级，ring 1）。SEV技术可以对虚拟机进行加密，运行在虚拟机中的操作系统可以是TEE。AMD SME和SEV是即将推出的技术，将在不久的将来得到AMD芯片组的支持。

通过内存限制实现的ring -2 TEE

x86系统管理模式和ARM TrustZone技术通过内存限制创建TEE。具体地，它们使用硬件（例如，存储器管理单元）来设置存储器区域对执行空间的访问权限，因此正常的系统软件不能访问执行空间。注意，TEE通过内存限制以时间片的方式与正常系统软件共享CPU。

X86系统管理模式（SMM）

系统管理模式（SMM）[29]是一种执行模式，类似于x86平台上可用的Real和Protected模式（英特尔自90年代初开始在其奔腾处理器中使用SMM）。它提供了一个硬系统隔离执行环境，用于实现特定平台的系统控制功能，如电源管理。它由基本输入/输出系统（BIOS）初始化。SMM是通过断言【断言(assertion)是一种在程序中的一阶逻辑(如：一个结果为真或假的逻辑判断式)，目的为了表示与验证软件开发者预期的结果——当程序执行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止执行，并给出错误信息。】CPU上的系统管理中断（SMI）引脚来触发的。此引脚可以通过多种方式断言，包括写入硬件端口或使用PCI设备生成消息信号中断。接下来，CPU将其状态保存到一个称为系统管理RAM（SMRAM）的特殊内存区域。然后，它原子地执行存储在SMRAM中的SMI处理程序。SMRAM无法通过其他执行模式进行寻址。默认情况下，对SMRAM中地址的请求被转发到视频存储器。因此，这个警告允许将SMRAM用作安全存储。SMI处理程序在引导时由BIOS加载到SMRAM中。SMI处理程序可以不受限制地访问物理地址空间，并可以运行特权指令（因此，SMM通常被称为ring -2。）RSM指令迫使CPU退出SMM，并以以前的模式恢复执行。

ARM TrustZone技术

ARM TrustZone技术[7]是一种硬件功能，自2002年左右的ARMv6[14]以来，它创建了一个隔离的执行环境。与其他硬件隔离技术类似，它提供了两种环境或世界。信任执行环境（TEE）被称为安全世界，富执行环境（REE）被称之为正常世界。为了确保安全世界和正常世界之间的完全隔离，TrustZone为包括CPU、内存和外围设备在内的硬件组件提供了安全扩展。

启用TrustZone的ARM平台上的CPU有两种安全模式：安全模式和正常模式。图1显示了启用TrustZone的ARM平台中的处理器模式。每个处理器模式都有自己的内存访问区域和权限。在正常模式下运行的代码无法在安全模式下访问内存，而在安全世界中执行的程序可以在正常模式中访问内存。安全模式和正常模式可以通过读取安全配置寄存器（SCR）中的NS位来识别，该寄存器只能在安全模式下进行修改。如图1所示，在ARMv8体系结构中，ARM涉及不同的异常级别（EL）来指示不同的权限，并且较低的EL拥有较低的权限。EL3是最高的EL，充当管理正常模式和安全模式之间切换的看门人。正常模式可以通过调用安全监视器调用（SMC）指令或触发安全中断来触发EL3异常，以切换到安全模式，而安全模式使用异常返回（ERET）指令切换回正常模式。

TrustZone使用内存管理单元机制来支持安全和正常环境中的虚拟内存地址空间。两个世界中相同的虚拟地址空间被映射到不同的物理区域。硬件中断有两种类型：中断请求（IRQ）和快速中断请求（FIQ）。通过配置IRQ，它们都可以配置为安全中断比特和SCR中的FIQ比特。安全中断被直接路由到安全EL3，忽略正常世界的配置。ARM建议将IRQ用作正常世界的中断源，将FIQ用作安全中断。

通过协同处理器的ring -3 TEE

Intel管理引擎

英特尔管理引擎（ME）是嵌入所有最新英特尔处理器中的微型计算机，它存在于英特尔产品中，包括服务器、工作站、台式机、平板电脑和智能手机[53]。英特尔于2007年推出ME作为嵌入式处理器。当时，它的主要功能是支持Intel Active Management Technology（AMT），Intel AMT是第一个在ME中运行的应用程序。最近，Intel开始将ME用作执行安全敏感应用程序的可信执行环境（TEE）。根据一位从事ME工作的英特尔架构师撰写的最新ME书籍[53]，一些安全应用程序已经或将在ME中实现，包括增强的隐私识别、受保护的音频视频路径、身份保护技术和引导保护。

图2展示了ME的硬件架构。从图中可以看出，ME就像一台计算机；它包含处理器、密码引擎、直接存储器访问（DMA）引擎、主机嵌入式通信接口（HECI）引擎、只读存储器（ROM）、内部静态随机存取存储器（SRAM）、计时器和其他I/O设备。ME在处理器上执行指令，并且它具有代码和数据缓存，以减少对内部SRAM的访问次数。内部SRAM用于存储固件代码和运行时数据。除了内部SRAM，ME还使用来自主系统存储器（即主机存储器）的一些动态随机存取存储器（DRAM）。该DRAM充当磁盘的角色；ME处理器当前未使用的代码/数据的存储器页将从SRAM中移出并交换到主机存储器中的DRAM。当系统引导时，DRAM的区域由BIOS保留。此DRAM专用于ME，操作系统无法访问它。但是，ME的设计不信任BIOS，它假设主机可以访问保留的DRAM区域。

AMD平台安全处理器

虽然ME适用于英特尔处理器，但我们可以在AMD平台上找到类似的技术。AMD安全处理器[5]（也称为平台安全处理器或PSP）是嵌入主AMD CPU内部的专用处理器。它与ARM TrustZone技术和ring -2可信执行环境（TEE）合作，使第三方可信应用程序能够运行。AMD安全处理器是一种基于硬件的技术，能够从BIOS级别安全启动到TEE。受信任第三方应用程序能够利用行业标准API来利用TEE的安全执行环境。另一个例子是系统管理单元（SMU）[45]。SMU是北桥的一个子组件，负责在引导和运行时执行各种系统和电源管理任务。SMU包含一个处理器来辅助[4]。由于AMD将北桥集成到CPU中，SMU处理器是CPU内部的嵌入式处理器，与Intel ME相同。

基于TEE的系统

基于TEE的解决方案被引入各种现代系统中，包括云平台（服务器和集群）、端点（台式机和移动设备）和边缘节点[63]（路由器和网关）。在本节中，我们将介绍在ARM和x86体系结构中利用TEE的应用程序和系统。

基于SGX的系统和攻击

以前基于SGX的系统，如Haven[13]，将系统库和库操作系统移植到SGX飞地中，从而形成一个大型TCB。Arnatov等人[9]提出了SCONE，这是Docker的一种安全容器机制，使用SGX保护容器进程免受外部攻击。Hunt等人[28]开发了Ryoan，这是一种基于SGX的分布式沙盒，使用户能够在数据处理服务中对其数据保密。Schuster等人[58]开发了VC3，这是一个基于SGX的可信执行环境，用于在云中执行MapReduce计算。Karande等人[41]使用SGX保护系统日志。Shih等人[64]利用SGX来隔离网络功能虚拟化（NFV）应用程序的状态。

Schwarz等人[59]通过缓存侧通道攻击SGX飞地，并证明mbedTLS的RSA实现中的私钥可以在五分钟内提取。除了RSA解密，Ferdinand[16]还证明了通过基于SGX缓存的信息泄露对人类基因组索引的更有效攻击。AsyncShock[74]表明，线程调度可以通过攻击来控制，并且线程操作可以进一步用于利用SGX飞地内的同步错误。SGX屏蔽[60]为SGX程序提供了安全地址空间布局随机化支持。T-SGX[65]对抗受控信道攻击，确保页面错误不会泄露。

基于SMM的系统

近年来，基于SMM的研究出现在安全文献中。例如，SMM可用于检查更高级别软件（例如，系统管理程序和操作系统）的完整性。HyperGuard[55]、HyperCheck[82]和HyperSentry[11]是基于SMM的完整性监控系统。此外，国家科学基金会去年资助了一个关于使用SMM进行运行时完整性检查的项目[2]。SICE[12]提供了一个可信的执行环境，用于在AMD平台上通过SMM执行敏感工作负载。SPECTRE[79]使用SMM对恶意软件检测系统的实时内存进行内省。SMM的另一个用途是可靠地获取系统物理内存用于取证分析[51，73]。IOCheck[77,81]在运行时保护I/O设备的配置和固件。HRA[36]使用SMM在云环境中进行安全资源核算，即使系统管理程序受到损害。MalT[78]通过利用SMM在裸机上透明地调试软件，向秘密调试迈进。TrustLogin[80]保护用户凭据，尤其是密码，使其在不受信任的环境中免受盗窃。HOPS[42]使用SMM来创建低伪影过程内省技术。正如我们所看到的，已经提出了一系列基于SMM的系统，我们需要开发新的技术来保护这些系统的代码。

现代计算机将SMRAM锁定在BIOS中，因此在引导后，SMRAM无法从任何其他CPU模式访问。Wojtczuk和Rutkowska演示了通过内存回收[55]或缓存中毒[76]绕过SMRAM锁。内存回收攻击可以通过锁定重映射寄存器和低可用DRAM顶部（TOLUD）寄存器来解决。缓存中毒攻击通过操纵内存类型范围寄存器（MTRR），迫使CPU从缓存而不是SMRAM执行指令。Duflot也独立发现了这个体系结构漏洞[23]，但Intel添加了SMRR[29]已经修复了这个漏洞。此外，Duflot等人[22]列出了SMM的一些设计问题，但可以通过BIOS中的正确配置和SMI处理程序的小心实现来解决这些问题。Wojtczuk和Kallenberg[75]提出了一种通过操纵UEFI引导脚本的SMM攻击，该脚本允许攻击者绕过SMM锁并使用ring 0权限修改SMI处理程序。UEFI引导脚本是UEFI固件在S3恢复期间解释的数据结构。当启动脚本执行时，未设置BIOS_NTL（SPI闪存写入保护）或TSEG（来自DMA的SMM保护）等系统寄存器，因此攻击者可以强制S3睡眠来控制SMM。Butterworth等人[18]证明了SMM中BIOS更新过程中存在缓冲区溢出漏洞，但这不是一个体系结构漏洞，特定于特定的BIOS版本。

基于TrustZone的系统和攻击

在过去的几年里，移动设备的数量急剧增加，安全性成为用户关注的主要问题之一。ARM引入了TrustZone技术，研究人员利用它构建了一系列系统，以增强移动设备的安全性。TrustDump[69]通过利用TrustZone提供可靠的内存获取。它使用不可屏蔽的安全中断切换到信任域，并从信任域内省正常域的内存。TZ-RKP[10]运行在安全的世界中，并通过事件驱动的监控来保护正常的操作系统内核。Sprobes[25]提供了一种从安全世界内省正常操作系统的检测机制，并保证了内核代码的完整性。SeCReT[35]是一个在正常世界和安全世界之间建立安全通信通道的框架。TrustICE[70]为执行敏感工作负载提供了一个可信且独立的计算环境。TrustOPT[68]在移动设备上使用ARM TrustZone技术提供了一种安全的一次性密码令牌。AdAttester[43]提出了一种可验证的移动广告框架，该框架使用TrustZone来保护在线移动广告认证。[15]建议使用TrustZone对受限空间内的设备（如摄像头）的外围设备进行监管。fTPM[50]是在ARM TrustZone中实现的TPM 2.0的固件版本。PrivateZone[34]使用TrustZone创建一个与富执行环境和TEE隔离的私有执行环境。C-FLAT[3]通过TrustZone中的运行时控制流验证来对抗控制流劫持。

高通公司使用安全通道管理器（SCM）通过SMC指令与高通公司的安全执行环境（QSEE）进行交互，[52]利用此接口并利用整数溢出漏洞写入任意安全内存。接下来，他们用这种方法重写SMC处理程序表，并获得任意的TrustZone代码执行。[62]使用ret2user获得root权限，还存在未检查绑定将一个字节写入几乎任何物理地址的漏洞，最终导致TEE中执行任意有效载荷。ARMageddon[44]使用Prime+Probe缓存攻击将信息从安全世界泄漏到正常世界，并使监控TrustZone代码在正常世界中的执行变得可行。

基于ME的系统和攻击

Intel使用ME作为TEE来执行安全敏感操作[53]。2009年，Tereshkin和Wojtczuk[71]证明了他们可以通过将恶意代码注入英特尔主动管理技术（AMT）来在ME中实现ring -3 rootkit。DAGGER[67]使用[71]中类似的技术绕过了ME隔离，但它挂接了ME固件函数memset，因为它被调用的频率更高。Skochinsky[66]发现SPI闪存上的ME固件使用霍夫曼编码来防止实现rootkit的逆向工程。最近，Intel在ME中披露了一个AMT漏洞（CVE-2017-5689或Intel-SA-00075[32]）。该漏洞允许攻击者在不输入密码的情况下远程获得对英特尔机器的管理控制[49]，并且该远程黑客漏洞在英特尔芯片中存在七年[26]。

挑战和方向

TEE代码中的Hunting Bugs

在TEE中运行的软件可能包含文本书漏洞，攻击者很容易利用这些漏洞。Kallenberg和Kovah[37]发现，“数百万BIOS”很容易被破坏，因为SMM代码的已知漏洞从未在BIOS中进行修补。Butterworth等人[18]证明了SMM中BIOS更新过程中存在缓冲区溢出漏洞。Di[62]在TrustZone代码中发现了能够任意执行代码的漏洞。此外，已经开发了一系列基于SGX的系统[9，13，28，41，58，64]，这些基于SGX应用程序由于其庞大的代码库而不可避免地包含漏洞。我们需要开发有效的框架，以发现TEE中运行的代码/图像中的漏洞，并在攻击者利用漏洞之前减少出现漏洞代码的机会。

然而，现有的错误搜寻解决方案不能直接应用，因为TEE的代码需要特定的环境（例如SMM和TrustZone）来执行。如果我们有TEE软件的源代码（例如，SGX应用程序），我们可能能够修改现有的静态分析或漏洞检查工具，以识别漏洞并将漏洞数量降至最低。然而，如果我们没有源代码，但有TEE的图像，狩猎二进制图像中的错误非常耗时，并且需要大量的逆向工程工作。此外，由于硬件供应商的保护机制，可能无法获得其他TEE的图像，如ME代码[66]。

因此，需要开发一个框架，在TEE的代码在高特权、隔离和可信环境中运行之前对其进行检查。例如，我们可以使用符号执行（例如，S2E平台）来分析SMI处理程序代码和TrustZone固件。符号执行可以帮助探索SMI处理程序和TrustZone映像的执行路径，并发现导致已知利用的路径。由于S2E可以直接处理x86和ARM架构上的二进制文件，因此它可以在不了解源代码的情况下分析商业SMI处理程序和TrustZone代码。请注意，Bazhaniuk等人[47]。提出用类似的方法分析SMI处理程序对BIOS的安全性。然而，它们仅针对检测SMI处理程序中的外调用函数（即，在受攻击者控制的受保护内存SMRAM之外调用函数）[56]。此外，我们不仅可以针对x86上的SMI处理程序代码，还可以将该方法应用于ARM架构上的TrustZone固件。此外，我们可以修改S2E插件来处理其他漏洞，如缓冲区溢出和有毒指针[48]，以帮助我们验证来自不可信环境的输入。

TEE内的保护机制

在TEE中运行完美的代码是不切实际的，攻击者最终会发现漏洞并在某个时候利用它。然而，现有的TEE在执行环境中缺乏防御机制。例如，在SMM中运行的代码共享单个地址空间，并且禁用寻呼[29]。在SGX飞地中运行的应用程序没有ASLR等基本保护机制。在正常的计算环境（如操作系统）中，我们有一系列系统级防御机制，如不可执行堆栈、数据执行防止和地址空间随机化。然而，TEE中缺少这些防御机制。由于我们认为这些环境比普通操作系统更安全，因此需要这些基本的系统防御机制来保护环境。

防御措施之一是使TEE的环境多样化。这增加了攻击者成功利用漏洞的难度和成本。通过这种方法，我们可以创建动态TEE。根据英特尔手册[29]，系统管理模式有一个非常简单的寻址机制。它禁用分页并直接作用于物理地址。当系统启动时，BIOS初始化SMM，并将SMI处理程序代码加载到SMM_Base+0x8000的物理内存地址。SMM_Base表示SMRAM的开始。通常，BIOS供应商将SMM_base设置为0xa0000，并且该内存区域与VGA内存重叠。我们可以通过修改BIOS代码，在每次启动或重新启动时随机分配SMRAM的基本地址。具体来说，我们可以在BIOS中为每个重置信号随机设置SMRAM地址。请注意，重置信号可能是由各种电源状态变化引起的，包括冷启动、热启动、从S3唤醒（即挂起到RAM）等。通过随机化SMRAM的基址，增加了攻击者转储SMRAM进行利用或反向工程的难度。此外，我们可以在SMRAM中随机化保存的状态，而不是在固定位置SMM_base+0xFC00。然后，像[48]这样的SMM攻击将不起作用，因为它需要覆盖保存状态区域的SMM_base寄存器。

TrustZone的执行环境比SMM的执行环境更为复杂。TrustZone有自己的页面表，并在启用内存管理单元的情况下运行。为了使TrustZone的执行环境多样化，我们可以首先随机化TrustZone固件代码的位置。在TrustZone中，它可以支持并运行安全操作系统。我们可以在ARM可信固件的安全操作系统上实现地址空间布局随机化（ASLR）技术。这种添加可以降低利用缓冲区溢出或面向返回编程的攻击的成功率[61]。我们可以从类似TEE的SMM的Coreboot[19]和TrustZone的Trusted Firmware[8]开始这一研究方向。

此外，在ring 3 TEE（例如Intel SGX）中也需要随机化。SGX屏蔽[60]为SGX程序提供了安全地址空间布局随机化支持。此外，我们可以周期性地或随机地实例化SGX飞地，并将安全敏感的工作负载从一个飞地移动到另一个。在这种情况下，飞地的相关状态正在移动，因此依赖于静态信息（例如，内存地址）的攻击可能不再有效。

检测受损的TEE

在实践中，TEE可能会由于代码中的漏洞而受到损害。然而，检测受损的TEE是一个非常具有挑战性的问题，因为TEE运行在系统软件无法访问的高特权内存空间（ring -2 TEE），或者使用加密内存，如果没有密钥，其内容是神秘的（ring 3 TEE）。例如，英特尔SGX在飞地中对其代码和数据进行加密；SMM和TrustZone代码不可由系统软件（例如OS）访问。由于这些“安全保护”功能，TEE可以实现强大的安全保障。然而，在破坏TEE后，攻击者可以在其中实现无法检测的高级rootkit。

Embleton等人[24]使用SMM实现芯片组级键盘记录器和网络后门，该网络后门能够直接与网卡交互，通过网络数据包将记录的击键发送到远程机器。Schiffman和Kaplana[57]进一步证明了USB键盘而不是PS/2键盘。其他基于SMM的攻击侧重于实现隐秘的rootkit[1，17]。例如，美国国家安全局（NSA）使用SMM构建一系列rootkit，包括适用于Dell的DEITYBOUNCE和适用于HP Proliant服务器的IRONHEF[1]。已经证明了使用ME实现高级隐形rootkit的几种攻击[67,71]。Tereshkin和Wojtczuk[71]将恶意代码注入到Intel主动管理技术（AMT）中，以实现ME ring-3 rootkit。DAGGER[67]是一个在ME中实现的基于DMA的键盘记录程序，它在平台引导过程的早期捕获击键，这使DAGGER能够捕获硬盘加密密码。在证明TEE是一个强大的孤立计算环境的同时，拥有一种检测受损TEE的方法是一项具有挑战性的任务。

检测受损TEE的一种潜在方法是使用性能影响、定时或其他侧信道信息。例如，我们可能能够检测到受损的SMM或TrustZone通过定时侧通道信息。直觉是ring -2 TEE以时间片的方式与系统软件共享主CPU。这种方法不适用于ring -3 TEE，因为它们运行在独立的处理器上，而不是主CPU上。通常，SMM或TrustZone很少被调用，或者它们的执行时间对于正常的系统操作有一些特定的模式。如果我们看到一个系统显著改变了其执行模式（在SMM或TrustZone中停留太久，无法通过网络数据包发送敏感内存页面）或非常频繁地调用ring -2 TEE（例如，基于SMM的密钥记录器[24]为每次击键生成SMI），则系统更有可能受到损害。为了检测SMI调用及其执行时间，[72，82]实现了一种名为SMI检测器的工具。这个工具背后的想法是SMI调用挂起CPU中的所有内核，SMI检测器可以测量丢失的时间。类似的工具可以在TrustZone上工作，因为它也以时间片的方式共享CPU。注意，使用基于侧信道的方法来检测受损的TEE可能不适用于所有情况（例如，定时侧信道不适用于ring -3 TEE）。对于其他情况，可以考虑其他侧信道，包括功耗、高速缓存访问模式、网络流量模式。

TEE的修补和再生

本小节讨论了如何从受损的TEE中减轻攻击者并将其修补到良好状态的挑战。一种简单的方法是使用系统软件来更新受损的TEE。然而，如果TEE被破坏，则很可能系统软件也是恶意的。因此，在系统软件中运行的修补过程是不可信的。为了确保恢复过程不被篡改，我们必须依靠信任基础。然而，建立这样一个信任基地是一项具有挑战性的任务。

对于ring -2 TEE，我们可以使用固件作为信任基础。这种更新过程适用于一些真实世界的攻击，如入侵（CERT VU#631788）[37]。在这种攻击中，对手能够绕过隔离进入SMM运行任意代码，BIOS固件仍然受到BIOS控制寄存器（BIOS_CNTL）中的写入启用位的保护[29]。只要攻击者不能闪存BIOS固件，系统就可以执行快速重新启动以破坏SMRAM并重新初始化受损的SMI处理程序。在这种情况下，从固件对受损TEE的更新过程起作用。但是，攻击者有可能绕过写保护并重新刷新固件。例如，Wojtczuk和Kallenberg[75]通过操纵UEFI引导脚本提出了一种SMM攻击，该脚本允许攻击者绕过BIOS写保护锁，并使用ring 0权限修改SMI处理程序（CERT VU#976132）。此外，Speed Racer[38]描述了一种允许攻击者破坏固件闪存保护机制的竞争条件。在这些攻击场景中，如果固件不可信，我们如何将SMI处理程序恢复到干净状态？如果我们假设BIOS、SMM和系统软件都受到了损害，我们需要依赖一个在可信计算库（TCB）中没有它们的组件。一个潜在的解决方案是ring -3 TEE，如英特尔ME和AMD PSP。然而，如何更新ring -3 TEE是另一项具有挑战性的任务。

总结

现有的可信执行环境侧重于通过利用硬件支持来减少TCB并实现强隔离。然而，TEE中运行的错误代码等其他威胁会引发安全问题。本立场文件的目标是提请系统安全界注意实现更安全的执行环境所面临的挑战。我们还提供了应对挑战的愿景和潜在方向。