【论文分享】SoK: Understanding Designs Choices and Pitfalls of Trusted Execution Environments @2024AsiaCCS

标题为《SoK: Understanding Design Choices and Pitfalls of Trusted Execution Environments》，由Mengyuan Li、Yuheng Yang、Guoxing Chen、Mengjia Yan和Yinqian Zhang撰写，发表于2024年的ACM Asia Conference on Computer and Communications Security (ASIA CCS '24)

Overview

背景：随着云计算服务市场的快速增长，客户越来越需要保护其在云平台上执行的敏感数据。传统的云模型要求客户完全信任云服务提供商（CSP），这限制了对云服务的采纳，尤其是在金融、医疗和政府等涉及敏感数据的行业。

TEE：文章讨论了可信执行环境（Trusted Execution Environment, TEE）技术，这是一种革命性的技术，能够在不信任的服务器端计算平台上实现云工作负载的安全远程执行（Secure Remote Execution, SRE）。TEE通过硬件信任计算基础（Trusted Computing Base, TCB）组件，如具有内存管理单元（Memory Management Unit, MMU）和内存加密引擎（Memory Encryption Engine, MEE）的系统芯片（System-on-Chips, SoCs），提供了一个高度安全和隔离的执行环境。

TEE设计：文章提供了TEE设计选择的结构化分析，重点分析了TEE设计及其潜在的陷阱。作者介绍了TEE运行时架构框架（TEE Runtime Architectural Framework, TRAF），这是一个详细的框架，通过分析TEE设计所做的高层次考虑，促进了对TEE设计的全面和系统化分析。

TRAF框架：TRAF框架特别研究了CPU、内存和I/O设备等共同资源是如何由TCB和宿主操作系统（host OS）共同管理的。TRAF分析了影响设计选择的因素，如TCB大小、性能和效率，并评估了不同设计选择对安全性的影响。

已知攻击与漏洞：文章通过检查现有的TEE漏洞和攻击，进一步评估了不同设计选择的安全性影响。特别是，通过案例研究AMD SEV和相应的对策，文章深入探讨了现有攻击背后的原因，以及设计缺陷如何导致攻击。

Abstract

可信执行环境 (TEE) 是一项革命性技术，可在不可信的服务器端计算平台上实现云工作负载的安全远程执行 (SRE)。 过去几年中，商业和学术 TEE 都被提出，包括 Intel 的 SGX 和 TDX、AMD 的 SEV、ARM 的 CCA、IBM 的 PEF，以及基于开源 RISC-V 处理器构建的学术同行，例如 Keystone、Sanctum、CURE 、蓬莱。 尽管双方都在打造保密计算生态系统方面做出了巨大努力，但设计截然不同的服务器端 TEE 的存在以及各种已知攻击的存在，大大增加了理解 TEE 设计和现有攻击背后原因的难度。

本文对服务器端 TEE 的设计选择进行了结构化分析，重点是剖析 TEE 设计并识别其潜在缺陷。 我们介绍了 TEE 运行时架构框架 (TRAF)，这是一个详细的框架，通过分析 TEE 设计的高级考虑因素，有助于对 TEE 设计进行彻底且有条理的剖析。 TRAF 分析的一个关键方面是 TEE 设计中资源管理的重新配置，其中主机操作系统曾经拥有完全控制权。 通过结合可信计算库（TCB），TEE设计在如何划分和协调主机操作系统和TCB之间的任务上采用不同的设计选择，以实现计算资源的安全和有效管理。 TRAF专门研究了TCB和主机操作系统如何联合管理CPU、内存和I/O设备等公共资源。 这包括对影响设计选择的因素进行重点研究，例如 TCB Size、性能和效率。 此外，通过检查 TEE 上的现有漏洞和攻击，本文进一步评估了不同设计选择的安全影响。

Introduction

近年来，IT行业云服务市场快速增长。 云客户以执行实例（例如虚拟机和容器）的形式从 CSP（Cloud Service Provider） 租用计算能力，并使用云来执行远程计算任务。 然而，传统的云模型要求客户完全信任 CSP。 这种信任允许 CSP 检查和控制用户实例，如图 1a 所示。 这种对毫无保留的信任的需求极大地阻碍了云服务在涉及敏感数据的任务中的采用，特别是对于金融、医疗保健和政府等行业。

一个有前途的解决方案是机密计算 [20]，它利用服务器端可信执行环境 (TEE) 来保护敏感工作负载免受不可信 CSP 的侵害。 TEE 由硬件可信计算基础 (TCB) 组件（例如具有内存管理单元 (MMU) 和内存加密引擎 (MEE) 的片上系统 (SoC)）支持，为 TEE 实例提供高度安全且隔离的执行环境。 这种受保护的环境为 TEE 实例提供了强大的机密性和完整性保证，保护它们免受特权软件甚至服务器上的直接物理攻击。 通过在 SoC 中嵌入加密信任根 (RoT)，TEE 还提供远程证明机制，以验证硬件和 TEE 实例的真实性。 TEE 技术的进步显着改变了公共云内的信任动态，将机密计算定位为保护云中“使用中的数据”的实际解决方案（如图 1b 所示）。

鉴于 TEE 带来的巨大优势，近年来，包括 Intel、AMD 和 ARM 在内的主要芯片供应商推出的 TEE 生产系统数量不断增加，以及基于 RISC-V 系统的开源原型的学术 TEE 设计方案。 这些 TEE 设计在多个方面有所不同，包括性能开销、安全属性和可编程性（即易于使用）。 尽管 TEE 很受欢迎，但它也呈现出另一个令人担忧的趋势，越来越多的软件和硬件攻击频频成为人们关注的焦点。 我们认为，随着 TEE 设计研究工作的蓬勃发展，社区可以从这些工作的系统化中受益匪浅，这有助于提供多样化 TEE 设计景观的全局并确定有前途的研究问题。

然而，对多样化的 TEE 研究领域形成一个系统的看法是具有挑战性的。 主要困难在于，考虑到 TEE 设计的丰富性及其设计和实现的多样性，理解这些复杂但独特的设计的复杂细节和基本考虑因素可能是一个真正的挑战，特别是对于该领域的新研究人员而言。 此外，并非所有设计选择和实现细节都同样重要。 理想的系统化应该帮助人们掌握驱动 TEE 设计选择的架构级动机，并从逻辑上推理这些选择背后的权衡。 因此，本文提供了一个 TEE 解构框架，重点关注 TEE 设计的基本挑战：

TEE 设计如何保护 TEE 实例使用的资源，同时使不受信任的操作系统 (OS) 能够以有效的方式管理计算资源，以履行 CSP 的职责。

通过从操作系统资源管理任务的角度分解TEE设计，该框架提供了一种系统化、结构化的方法论，以从上至下的方式理解TEE设计的复杂性。

TEE Runtime Architectural Framework (TRAF)

TEE运行时架构框架旨在帮助新手全面了解不熟悉的TEE设计。 TRAF 提供了一种基于操作系统中常见事件和任务（例如 CPU 调度、内存管理等）的结构化方法，将复杂的 TEE 设计分解为 TEE 设计如何考虑不同的事件和资源管理。 对于不同的事件，TEE 设计可以选择直接控制事件或将它们委托给不受信任的主机操作系统进行处理。 TRAF 将关键系统管理事件分为四种模式。 这四种模式强调TEE实例、不可信特权操作系统和TEE（TCB内的组件）引入的可信保护措施之间的协调关系。 不同模式的采用反映了 TEE 设计选择的架构概述，并且是由于不同的权衡（例如安全性、性能和效率）而导致的。 通过这种高层次的分析，研究人员可以迅速掌握 TEE 设计的重点。 因此，他们可以快速粗略地了解总体考虑因素，并选择感兴趣的特定领域进行进一步深入研究。 此外，我们希望这种解构模型能够激励研究人员从不同操作系统事件对 TEE 设计的影响角度系统地考虑 TEE 设计的安全性。

Contributions

• 本文介绍了 TRAF，这是一个结构化框架，旨在剖析 TEE 设计并分析可信计算基 (TCB) 和主机操作系统之间资源管理任务的划分和协调。

• 本文利用TRAF 对控制TEE 设计如何处理常见运行时任务的高级设计选择进行深入分析。 分析表明，大多数现有 TEE 设计对于大多数任务都表现出类似的设计选择。 本文还讨论了设计选择带来的影响，包括它们对安全性、TCB 大小和性能的影响。

• 本文对针对 TEE 的已知攻击进行了分类，并深入研究了有关 AMD SEV 的现有攻击背后的原因以及相应对策的案例研究。 它强调，源自 TEE 设计缺陷的攻击通常是由于某些资源在某些极端情况下仍由不受信任的主机操作系统管理而导致的，而这些资源缺乏足够的保护。

TEE IN A NUTSHELL

在本节中，我们首先提供有关 TEE 的基本背景信息。 此外，我们还概述了广义的 TEE 生命周期，主要涉及远程证明和运行时保护。

Scope of Investigation

在本文中，我们将注意力集中在支持安全远程执行（SRE）功能的通用处理器中基于硬件的服务器端（也称为云）TEE [80]。 如果使用硬件支持的技术来为受保护环境中运行的 TEE 实例提供安全保证，则 TEE 被认为是基于硬件的 [19]。 SRE 是一种安全功能，可以在远程、不可信的平台上安全地执行应用程序。 具体来说，具有SRE功能的TEE设计必须具有以下安全属性[80]：

（1）安全测量：它应该提供底层硬件平台的测量以及可用于远程证明的TEE实例的初始状态；

（2）保密性：应对 TEE 实例的内部数据保密，防止软件和物理（可选）对手；

（3）完整性：应防止对TEE实例的代码和数据进行未经授权的篡改。

我们的研究中不包括不支持 SRE 或纯粹以软件实现的 TEE。 例如，TrustZone [6] 是一个著名的 TEE，已在 ARM 处理器上使用超过 15 年。 然而，由于它不是为云平台设计的，也不支持安全测量以允许远程用户验证 TEE 实例的初始状态，因此我们将 TrustZone 排除在我们的调查之外。 完全用软件实现的 TEE 也被排除在外，例如 Amazon AWS Nitro enclave [8] 和 Ant Group 的 HyperEnclave [42]。 本文还排除了基于硬件的 TEE 的软件扩展，例如 vSGX [102]、Twinvisor [51] 和 Colony [97]，因为它们的安全保证构建在底层 TEE 之上。 此外，我们只关注主要的服务器级处理器平台，包括Intel、AMD、ARM和RISC-V。 嵌入式 TEE 设计由于不同的使用场景和不同的设计考虑因素而被排除在本文的讨论范围之外。

TEE Threat Model

Threat models

TEE 设计通常考虑的对手拥有控制底层计算平台的整个软件堆栈的能力。

具体来说，假设对手能够

（1）在特权级别执行任意指令；

（2）随意启动、暂停、销毁TEE实例；

（3）管理非 TEE 领域的软件堆栈，包括内存映射、I/O 设备和 CPU 调度。

此外，许多 TEE 设计还假设对手可以获得对计算设备的物理访问权限 [5,29,36,44,49,83]。 在存在物理对手的情况下，SoC 外部的外围硬件组件被认为是不可信的，因为它们可能会通过各种物理攻击而受到损害，例如冷启动攻击 [31] 和总线监听攻击 [64]。

然而，针对可用性的攻击是 CIA 三合会的另一个关键组成部分 [72]，通常不被考虑在商业 TEE 的威胁模型中。 这是因为计算平台（包括硬件和软件）由潜在对手方管理。 对手至少可以终止或破坏 TEE 实例。 因此，拒绝服务 (DoS) 攻击被排除在 TEE 的威胁模型中。

此外，微架构侧通道攻击通常也被排除在威胁模型商业 TEE 之外 [3,5,22,36]。

Trusted computing base (TCB)

TEE的TCB包括所有被认为可信的、参与建立TEE安全基础的硬件和软件组件。

具体来说，TEE的TCB又可以分为Manufacturer TCB和ISV TCB。

Manufacturer TCB 包括由 TEE 制造商提供的硬件和软件组件。 例如，在Intel SGX [22]中，制造商TCB包括制造商提供的硬件组件，例如指令集架构（ISA）、基于硬件的内存加密引擎、基于微码的MMU扩展以及基于软件的架构飞地（例如 ，引用 Enclave 和 Provisioning Enclave）。

ISV 是独立软件供应商 (Independent Software Vendor) 的缩写，这是英特尔创造的术语，指利用 TEE 构建应用程序的软件开发人员。 因此，ISV TCB 包括在受 TEE 保护的执行环境内运行的软件（例如，在飞地或机密虚拟机内运行的进程）。 请注意，尽管 ISV TCB 内部的漏洞可能会导致各种攻击（例如，内存安全攻击 [18] 和线程安全攻击 [91]），但 ISV TCB 内部的漏洞通常超出了 TEE 设计的范围，因为它是 ISV 有责任确保 ISV TCB 没有错误。

TCB 大小是反映 TEE 设计安全性的常用因素。 一般来说，较小的 TCB 大小表示较少的代码行或硬件实现，这反过来又表明出现漏洞的可能性较低。 然而，基于 TCB 大小比较两种 TEE 设计的安全性很困难，即使是在基于 VM 的 TEE（例如 AMD SEV）和基于进程的 TEE（例如 Intel SGX）之间也是如此。 例如，通常假设基于VM的TEE的ISV TCB大于基于进程的TEE的ISV TCB。 然而，随着我们看到越来越多的研究努力使用内存安全编程语言（例如 Rust）构建更小的 TEE 操作系统，得出这样的结论是不合理的。 对于Manufacturer TCB，由于基于VM的TEE通常需要处理VM特定的事件（例如特权指令或I/O），因此它们的Manufacturer TCB可能更大或更复杂。 然而，仍然很难直接比较两种 TEE 设计之间的制造商 TCB 大小，因为大多数商业 TEE 都是闭源的。

Generalized TEE Lifecycle

如图2所示，TEE设计和生命周期主要涉及两个部分：远程证明和运行时管理。

• 远程认证。 远程证明会生成一份可验证的报告，详细说明 TEE 实例的初始状态，以便远程用户可以验证制造商 TCB（执行环境）和 ISV TCB（TEE 软件）的真实性和完整性。 初始状态由已部署软件二进制文件的加密哈希以及 TEE 硬件和软件的配置组成。 大多数 TEE 遵循类似的远程认证程序，在制造商 TCB 的协助下生成认证报告。

• 运行时管理。 从验证初始状态开始，在运行时管理方面，TEE设计主要关注两个方面：高效的资源管理和安全性。 在高效的资源管理方面，TEE设计必须符合CSP的资源管理要求。 这确保了对服务器资源（包括 CPU、内存和 I/O 设备）的高效管理，这些资源在运行时由 TEE 实例和非 TEE 组件使用。 在安全性方面，TEE设计必须保护TEE威胁模型下TEE实例的机密性和完整性（第2.2节）。

大多数 TEE 设计通常遵循远程证明中的类似步骤。 因此，我们在第 3 节中简要总结了执行远程证明和验证 TEE 实例初始状态的步骤。

然而，运行时管理和保护的方法在不同的 TEE 设计中存在更广泛的差异。 因此，本文主要关注不同的 TEE 设计如何协调 TCB 与不可信主机操作系统以提供安全有效的运行时管理。 在第4节和第5节中，我们将提出一个系统框架来分析云TEE设计如何实现运行时管理。

REMOTE ATTESTATION

在本节中，我们简要介绍大多数 TEE 如何遵循通用远程认证程序来确保可验证的 TEE 初始状态。

General Remote Attestation Procedures

大多数 TEE 遵循相同的远程认证程序：

第1步。 TEE实例本身或TEE实例的所有者（加载TEE实例的实体）向受信任的证明监管者发起远程证明请求。 可信证明监管者通常位于制造商 TCB 内，可以是底层硬件、安全协处理器或 TEE 制造商发布的特权 TEE 实例；

第2步。 鉴证主管生成并签署可验证的鉴证报告。 该报告包含有关 TEE 实例的关键信息，例如对其初始状态、平台详细信息和配置的安全测量；

第3步。 然后，TEE 实例用户在将任何秘密数据传输到 TEE 实例之前验证证明报告。

远程认证的关键技术组件包括:

(1) 信任链，用于验证认证报告和认证主管的可信度;

(2) 建立能够准确表示TEE实例初始状态的安全度量机制。

Chain of Trust

信任根通常是TEE制造商拥有的根签名密钥。 制造商为每个TEE SoC提供一个特定的密钥，称为认证密钥，并使用根签名密钥对该认证密钥进行背书。

然后，认证主管将使用该认证密钥对来自TEE实例的认证请求进行签名。 认证主管可以根据不同的TEE设计而变化，但通常在制造商TCB内。 常见的认证监督器可以是

(1)TEE硬件，或者

(2)制造商提供的特权TEE实例。

与在硬件上实现签名算法相比，利用基于软件的实现(即特权TEE实例)可以实现更高级的签名算法(例如，Intel SGX采用的EPID可以保护TEE平台的隐私)。 不利的一面是，特权TEE实例自然成为攻击者的目标，这可能有更大的攻击面。 例如，几次针对Intel的特权飞地(即quotation enclave)的推测执行攻击已经成功获取了认证密钥[16,81]，从而破坏了安全保证。

验证方在获得签名的认证报告后，需要相应的认证密钥来验证该报告。 当制造商选择不公开验证密钥，或将其发布给有限的第三方(例如云提供商或数据中心)时，制造商或第三方需要运行一些认证服务来代表TEE用户执行验证。 因此，在这种情况下，TEE用户必须对认证服务给予额外的信任。 验证过程成功完成后，TEE用户可以使用TEE实例提供的公钥(包含在证明报告中)与TEE实例建立安全通道。 通过这个安全通道，TEE用户可以安全地提供数据或将计算任务委托给TEE实例。

Secure Measurement

安全测量旨在根据 TEE 的内容确定性地生成固定长度的测量，以识别 TEE 实例。 现有的 TEE 设计[9,23,33]通常使用 TEE 实例初始内容的加密哈希作为度量。 通常假设 TEE 用户提前知道 TEE 实例的初始内容，以便她可以得出测量的预期值。 只要通信 TEE 实例的测量结果与预期值匹配，TEE 用户就确信 TEE 实例运行预期的软件。 对于初始内容，基于流程的TEE通常测量应用程序的初始代码和数据，而基于VM的TEE通常测量安全BIOS，这是加载到VM中的第一个软件，并依靠BIOS来检查可信度 稍后加载的操作系统和应用程序。

测量的安全性在于攻击者不可能启动两个具有不同内容的TEE实例(例如，一个恶意TEE实例和一个受害者TEE实例)，但测量是相同的。 通过使用加密散列函数，攻击者可以发现导致相同散列值的两个不同消息，这是可以忽略不计的。 因此，这里的关键点是，认证主管需要确保正确测量有关TEE实例内容的所有必要信息(例如，虚拟地址、访问权限)，并清空微体系结构中过期的数据副本。 否则，可能会有潜在的攻击绕过远程认证。 例如，Wilke等人[96]发现AMD SEV-ES不能正确地测量要加载到VM中的安全BIOS代码的虚拟地址，因此可以在不改变测量的情况下操纵安全BIOS的布局。 然后，被操纵的BIOS可以启动任意恶意代码并绕过远程认证。

TEE RUNTIME ARCHITECTURAL FRAMEWORK

在本文的其余部分，我们主要关注TEE的运行时管理和保护的分析。 本节旨在提供解构 TEE 设计的系统框架。

TRAF Overview

TEE运行时架构框架（TRAF）从操作系统（OS）角度利用常见事件和任务的分类来解构TEE设计。 TRAF 特别关注云 TEE 运行时中频繁发生的事件，即运行时管理任务（如图 3 所示），并进一步扩展分析以评估 TEE 设计如何保护这些事件。

具体来说，TEE 设计围绕 TEE 运行时高效资源管理和安全性的双重目标，同时旨在避免过度的 TCB 扩展。 TEE 设计还必须符合不可信 CSP（又名主机操作系统）的资源管理要求，而不是将整个操作系统堆栈（例如 CPU 调度程序、页表管理和 I/O 驱动程序）合并到 TCB 中。 这导致了设计挑战，即通过不可信主机操作系统和制造商 TCB 之间的协调来管理 TEE 运行时。 常见的运行时管理任务如何在两者之间划分会导致不同的高级设计选择，这些选择由各种 TEE 设计选择。

TRAF 首先在第 4.2 节中将高级设计选择分为四种模式，其中每种模式指示 TEE 设计是否以及如何处理该事件。 然后，我们展示每个 TEE 设计如何针对不同的运行时任务从这些模式中进行选择，包括 CPU 虚拟化（第 4.3 节）、内存管理（第 4.4 节）和外设资源管理（第 4.5 节），这些内容通常在操作系统教科书中介绍 [7]。 图 5 提供了设计选择如何随时间演变的时间线视图，以帮助显示趋势。

High-level Design Choices

TEE 设计在多大程度上仍然将管理运行时资源的能力委托给特权软件是服务器端 TEE 设计的关键因素。 具体来说，为了保护 TEE 实例，TEE 在其制造商 TCB 内执行一些运行时管理任务。 这些任务可以通过额外的 SoC 组件（例如 AMD 安全协处理器 [3]）、CPU 扩展（例如 Intel TDX ISA [36]）或软件组件（例如 Intel TDX 模块 [36] 和 SGX 引用）来执行 飞地[22]）。 我们创造了一个术语 TEE 运行时保护模块（简称 RTPM）来指代这些涉及安全运行时管理的制造商 TCB 组件。 在 TEE 设计中，RTPM 以四种模式之一与特权但不受信任的主机操作系统协作执行资源管理：

Unprotected mode

如图4（a）所示，在无保护模式下，特权软件直接管理运行时资源，TEE设计充分利用不受信任的软件进行资源管理。 选择此模式时，特权软件直接管理分配给TEE实例的硬件资源。 一个示例是将 CPU 资源调度到 TEE 实例，例如设置 CPU 亲和性。 请注意，在某些情况下，ISV TCB 可能会在自检或攻击检测中发挥作用。 然而，这可能是ISV本身的行为。 因此，如果Manufacturer TCB不参与，也应该归属于非保护模式。 一个示例是 SEV 环境上的指令仿真，其中guest VM (ISV TCB) 在某些情况下可能会额外检查指令返回值。

RTPM-only mode

如图 4(b) 所示，在仅 RTPM 模式下，TEE 实例与其关联的运行时资源之间的交互由 RTPM 专门管理，特权软件仅处理其他非 TEE 组件的资源。 在处理安全关键但简单的运行时管理任务时，TEE 设计可能会选择仅 RTPM 模式，例如由 RTPM 安全保存和恢复寄存器的上下文切换。 然而，使用此模式执行复杂任务可能会显着增加 RTPM 的大小，从而增加 TCB 的大小。

RTPM-guarded mode

图 4© 说明了 RTPM 保护模式。 在这种模式下，运行时管理任务在特权软件和 RTPM 之间协调，通常前者处理资源管理，后者专注于安全验证。 RTPM 保护模式对于复杂的运行时管理任务（例如内存管理）来说是一个有吸引力的设计选择。 例如，在 AMD SEV-SNP 中，特权软件执行嵌套页表维护和故障处理，而 RTPM 则验证内存加密密钥或隔离的正确配置。

TEE Instance-assistedmode

图4（d）描述了TEE实例辅助模式，其中TEE实例本身需要直接操作一些运行时资源。 如果没有 RTPM 或不受信任的主机操作系统作为 TEE 实例的代理，则实例必须自行执行部分管理任务。 与前两种模式不同，实例辅助模式不提供全局运行时资源对TEE实例的透明性，会损害系统的可用性。 因此，很少有 TEE 设计对物理资源采用这种方法。 其中一个例子是 Keystone 让 TEE 实例本身处理页面错误。

CPU Virtualization

CPU 虚拟化为 TEE 实例提供了 CPU 资源的抽象。 我们主要关注涉及 TEE 实例与不可信主机之间交互的事件，包括 CPU 调度、上下文切换以及中断和指令仿真（对于基于 VM 的 TEE）。

CPU Scheduling

在多道程序设计系统中，CPU调度在空闲进程中进行选择，并决定下一个进程占用CPU核心。 负责做出此类决策的特权软件称为 CPU 调度程序。

同样，TEE 实例也作为进程/虚拟机进行管理，并与非 TEE 组件共享 CPU 资源。 大多数TEE将CPU调度器排除在RTPM之外，并采用无保护模式进行CPU调度，其中调度决策仅由不可信操作系统中的调度器做出。 这种选择有两个关键原因：

(1) CSP 需要能够根据 TEE 实例的特定需求和策略有效管理和确定 TEE 实例的调度。 在 CPU 调度中采用 RTPM 保护模式可能会导致性能显着下降。

(2) 由于CPU调度的复杂性，将CPU调度器的功能放入RTPM中将显着增加TCB大小[11]。

可以在调度器中应用的调度算法，例如 Linux 中使用的轮询 (RR) 或完全公平调度 (CFS)，也是根据 CSP 的需要进行选择的。 调度程序依靠中断（例如定时器中断和 I/O 中断）来强制进程之间的上下文切换。 因此，CPU 调度程序的无保护模式的选择利用了不受信任的操作系统随意中断 TEE 实例的能力，这可能会导致基于中断的受控通道攻击，如设计选择的含义（第 5 节）中所讨论的。

观察：大多数TEE采用无保护模式进行CPU调度，以实现CSP的高效资源管理并减少其TCB大小。

Context Switch

在上下文切换期间，用于表示 TEE 上下文的寄存器将保存到内存中。 为了保护寄存器值的完整性和机密性，大多数TEE采用RTPM-only模式进行上下文切换。 例如，在传统的AMD虚拟化架构中，虚拟机管理程序协助保存和恢复VM的某些寄存器[43]。 然而，在 AMD SEV-SNP 中，整个过程作为单个原子硬件指令 (VMRUN abd VMEXIT) 合并在一起，并且寄存器值存储在受 RTPM 保护的内存区域中。 对于基于开源 RISC-V 的 TEE，在机器模式下运行的可信安全监视器会捕获并接管上下文切换过程，以确保其机密性和完整性。

除了更新寄存器值之外，RTPM 还可以在上下文切换期间选择性地清除存储在某些微架构（例如 TLB 和缓存）中的数据。 例如，在上下文切换期间通常需要完整的TLB刷新，以避免重用其他进程的TLB条目。 一些 TEE（例如 Intel SGX）也可能显式地部分刷新缓存，以防止推测执行攻击 [92] 和缓存侧通道攻击。 一些TEE中的RTPM（例如Keystone和Penglai）选择物理分区缓存路并在上下文切换期间切换缓存路以防止缓存侧通道。 出于性能考虑，某些 TEE（例如 AMD SEV 和 Intel TDX）使用安全域标签来标记 TLB 条目，并在上下文切换期间切换此标签，以避免完全 TLB 刷新。 为此，RTPM 使用当前执行器的标识符来标记每个 TLB 条目。 有了这样的TLB标签，前面的域留下的TLB条目就不会互相污染。

观察：大多数 TEE 选择仅 RTPM 模式进行上下文切换。 AMD SEV 是一个例外，因为它遵循无保护模式，但后续的 SEV-ES/SEV-SNP 切换到 RTPM-only 模式。

Interrupt and Instruction Emulation

在基于VM的TEE中，内部中断和异常以模拟的方式工作，这可以通过在VM控制块中模拟APIC相关的MSR的状态来实现。 有些TEE设计并没有为所有中断和异常提供额外的保护，例如AMD SEV，它仍然使用非TEE虚拟化环境中使用的中断和异常机制。 这意味着主机可以任意直接中断VM，当发生异常时，由主机负责处理或重定向。 一些TEE设计使用RTPM保护模式，例如Intel TDX和IBM PEF，它们利用RTPM来捕获、处理一些与安全相关的中断和异常。

同样，某些与物理状态相关的指令，例如CPUID、RDMSR、RDTSCP等，需要在虚拟化环境中进行仿真。 在传统的非TEE虚拟化环境中，这些指令是通过触发VMEXIT来模拟的，并让hypervisor更新相应的寄存器。 基于 VM 的 TEE（包括 AMD SEV、SEV-ES 和 SEV-SNP）继承了类似的机制（无保护模式），其中 VM 或 RTPM 直接向主机公开与指令关联的寄存器。 然后主机提供模拟结果并将其直接传递给虚拟机。 AMD SEV-SNP [3]的报告介绍，恶意主机可以通过提供不正确的CPUID返回值来诱导VM使用易受攻击的加密实现，或导致不同的VM行为，这严重违反了TEE执行的完整性 流动。 虽然VM可以在内部添加额外的检查来粗略地检查返回值，但Manufacturer TCB在整个过程中并不起到监督作用。

观察：对于基于VM的TEE，指令仿真和中断仿真是现有虚拟化技术中必不可少的。 然而，由于必须涉及不受信任的虚拟机管理程序，TEE通常在无保护模式或RTPM保护模式下运行。

Memory Management

内存管理旨在优化物理内存的利用率并提供不同进程使用的内存的隔离。 在大多数现代操作系统的内存管理中，三个关键要素是必不可少的：虚拟内存的管理（第 4.4.1 节）、物理内存的分配（第 4.4.2 节）和页面错误的处理（第 4.4.3 节）。 此外，我们还讨论了内存加密（第 4.4.4 节），它广泛用于保护 TEE 的内存免受物理攻击。 我们排除了基于 VM 的 TEE 的内部内存管理的讨论，因为它通常完全由 VM 本身管理。

Virtual Memory Management

这里的虚拟内存是指TEE实例直接看到的地址空间。 在基于进程的 TEE 中，这是 TEE 实例的托管进程的虚拟地址空间； 在基于VM的TEE中，这是指VM使用的客户物理地址（稍后通过嵌套页表转换为主存储器使用的系统物理地址）。 无论哪种情况，TEE 虚拟内存都以实例辅助模式进行管理。 例如，基于VM的TEE允许TEE实例在TEE内部创建页表并自行添加虚拟内存的另一个间接层。 基于进程的 TEE 可能不允许在 TEE 内创建自己的页表，但 TEE 设计通常不会限制 TEE 实例安排其私有虚拟地址布局。

观察：大多数TEE采用实例辅助模式进行虚拟内存管理。

Physical Memory Allocation (Access Control)

内存分配为TEE实例分配一组物理地址，并启动它们与虚拟地址的映射。 内存分配可以在启动 TEE 实例时静态进行，也可以通过需求分页动态进行 [29]。 大多数使用 RTPM 保护模式进行内存分配的 TEE 都遵循两个步骤：

(1) 不受信任的操作系统首先从主内存中选择空闲物理页，可以选择在为 TEE 保留的区域内，

(2) RTPM 执行额外的检查以确保安全 （又名访问控制）。

映射信息（TEE 实例看到的地址空间和系统物理内存地址空间之间）需要由 RTPM 保护，以确保 TEE 实例拥有的私有物理页不会被错误地与其他人共享。 不同的TEE选择不同的机制来实现这种安全保障。 例如，一些 TEE（例如 AMD SEVSNP、Intel TDX、Keystone）选择在地址转换结束时执行所有权检查，以便可以在映射信息缓存到 TLB 之前执行访问权限检查。 其他人在初始化页表时执行此类检查。 例如，RISC-V蓬莱中的安全监视器在更新页表时确保所有页表的正确性，因此可以在页表遍历期间省略访问权限检查。 通过确保未经授权的个人无法拥有非法页表条目（例如，不受信任的主机具有指向飞地的映射），蓬莱借助严格的内存分配检查来提供访问控制。

RTPM 提供此类检查的方式也可能不同。 例如，Intel SGX 和 AMD SEV-SNP 依赖一些元数据记录（Intel SGX 的 Enclave Page Cache Map (EPCM) 和 AMD SEV-SNP 的反向映射表 (RMP)）来检查内存分配和权限的正确性的内存访问。 然而，AMD SEV和SEV-ES依赖于内存加密启用的间接检查来保护内存分配和访问（例如，攻击者无法获取其他TEE实例内存的明文，因为攻击者将被RTPM强迫使用错误的密钥 解密[53]）。

观察：大多数 TEE 采用 RTPM 保护模式进行物理页面分配，该模式在内存访问之前（在页表更新或地址转换期间）强制执行安全验证。

Page Fault Handling

系统级页表（即基于 VM 的 TEE 的嵌套页表和基于进程的 TEE 的页表）内的页表条目 (PTE) 将虚拟内存地址转换为系统物理内存地址，在以下过程中发挥着关键作用： 规范页面错误异常。 现有的TEE设计在保护页面错误处理的选择上存在分歧，采用了多种模式。 这些保护机制必须确保内存分配信息在故障处理期间不被泄露，以防止恶意篡改。

RTPM-guarded mode

一些TEE（例如AMD SEV-SNP和Intel SGX）依赖不受信任的特权软件来维护系统级页表，但RTPM在运行时执行权限检查以确保内存映射信息仍然正确（例如，在页面错误处理和 页表遍历）。 使用 RTPM 保护模式可以减少 RTPM 的工作负载和 TCB 大小，但由于 RTPM 不会阻止主机设置/取消设置 PTE 的当前位，因此它为受控通道攻击打开了攻击向量（如 第 5.1 节）。

RTPM-only mode

一些 TEE（例如 Intel TDX 和 RISC-V Penglai）选择在仅 RTPM 模式下管理内存映射，其中页表的内存区域只能由 RTPM 写入，页错误也由 RTPM 处理。 RTPM-guarded 模式和 RTPM-only 模式之间的主要区别在于是否允许不受信任的操作系统在运行时直接更新页表。 请注意，ARM CCA 和 Intel TDX 为 VM 的共享内存区域维护了单独的嵌套页表，该区域在 RTPM 保护模式下受到保护。 因此，ARM CCA 和 Intel TDX 也可以归类为混合模式。

TEE instance-assisted mode

一些TEE将维护页表的任务分配给TEE实例。 例如，Keystone 和 CURE 中的 TEE 实例有自己的运行时系统，该系统维护自己的页表并处理其页面错误。 虽然在访问内存地址之前，RTPM 最终会执行所有权检查，但我们将这种类型视为实例辅助模式，因为 TEE 实例具有直接配置物理内存的能力。 TEE 实例辅助模式还可以缓解基于异常的受控通道攻击。

观察：TEE 选择不同的模式来处理页面错误，从而导致不同的安全隐患。

Memory encryption

当 TEE 威胁模型中也考虑物理攻击者时，除 SoC 之外的所有硬件设备均不可信。 因此，内存加密似乎是保护物理内存中存储的数据的唯一方法。 启用内存加密后，RTPM 包括软件或硬件内存加密引擎 (MEE)，负责加密来自 SoC 的出站数据并解密入站数据。 内存加密密钥应该只能由 RTPM 管理和访问，确保其在生命周期内免受任何攻击者的攻击。

与优先考虑内存加密完整性并提供新鲜度支持的小内存大小的 TEE 设计（例如 RISC-V Keystone 和 Intel SGX v1）不同，大多数支持较大内存大小的 TEE 设计往往会删除此类保护（例如 AMD SEV、Intel TDX） 、Intel SGX v2）或将它们设为可选（例如 ARM CCA）。 这主要是由与维护完整性或新鲜度元数据相关的大量性能开销驱动的，导致许多设计放弃完整性保护，这可能会引入内存重放攻击的潜在风险。

I/O Management

I/O对于TEE实例持久存储数据或与外部传输数据是必需的。 基于进程的TEE通过共享内存与非TEE世界进行数据传输。 基于 VM 的 TEE 还通过共享内存使用虚拟 I/O 设备执行 I/O 操作（例如，I/O 指令或 DMA）。

大多数现有的基于虚拟机和基于进程的TEE设计都选择I/O流量的无保护模式，允许特权软件拦截或操纵I/O流量。 例如，英特尔 SGX SDK 允许 enclave 使用 OCall 执行数据传输（即暂时退出 enclave 以调用外部函数），这是由不受信任的软件处理的。 基于虚拟机的 TEE（例如 AMD SEV、ARM CCA 和 Intel TDX）支持使用软件模拟 I/O 设备的 I/O 操作。 启用内存加密后，模拟 I/O 设备无法直接访问 VM 的私有内存。 因此，共享内存区域用于模拟直接内存访问（DMA）操作。 为了支持可编程 I/O 指令 (PIO)，TEE 操作系统与适用于 AMD SEV-ES 的 Linux 内核一样，使用特殊的处理程序来捕获特权 I/O 指令，将 I/O 数据放入共享区域，并 触发虚拟机管理程序的按需上下文切换，以完成 I/O 指令的仿真。

观察：大多数 TEE 设计都利用无保护模式进行 I/O 数据传输和 I/O 操作。 I/O 操作的机密性和完整性通过应用层的加密得到保护。

Towards trusted I/O

在无保护模式下，TEE I/O 操作的机密性和完整性完全依赖于基于软件的加密机制（例如网络通信的 TLS/SSL 和磁盘 I/O 的全盘加密），这可能会引入不可忽视的风险和性能开销。

为了减少此类性能开销，英特尔最近推出了一份关于 TDX v2.0 硬件支持的可信 I/O 的白皮书 [38]。 具体来说，I/O设备本身需要包含一个值得信赖的逻辑单元（例如TDX 2.0中的设备安全管理器），负责在TEE实例和I/O设备之间建立安全通道。 I/O 设备和 TEE 实例之间的 I/O 流量经过加密和完整性保护，这可以通过 PCIe 5.0 标准中的完整性和数据加密功能来实现 [39]。 I/O设备需要支持单根I/O虚拟化（SR-IOV）等功能，以确保TEE实例与I/O设备或虚拟I/O功能之间的一对一映射[38]。

UNDERSTANDING TEE DESIGNS USING TRAF

图 5 中的结果表明，TEE 设计在大多数任务中表现出类似的趋势和考虑因素（也称为设计选择）。 然而，在某些任务中，不同的 TEE 之间也会出现差异，例如页面错误处理和指令仿真。 在本节中，我们将深入研究选择不同保护模式所产生的潜在影响。

Implications of Design Choices

不同的模式选择会对安全性、TCB大小和性能带来影响，列举如下：

Unprotected mode

选择不受保护模式可能会导致相应的任务或资源完全可追踪或被不受信任的主机控制。

然而，由于CSP对全局资源管理的要求，大多数云TEE允许不受信任的操作系统以不受保护的方式处理这些与资源相关的任务，例如CPU调度和I/O路由。 不受保护模式通常提供更好的性能，因为它避免了不受信任的操作系统和 RTPM 之间的额外特权切换。 在 CPU 调度的情况下，采用 RTPM 保护模式几乎是不可能的，因为需要对每个调度操作进行 RTPM 验证会显着降低 CPU 性能。

然而，无保护模式的缺点也很明显，因为它增加了攻击面。

例如，采用无保护模式进行CPU调度，攻击者可以通过中断来暂停TEE实例的执行，或者为TEE实例配置CPU亲和性。 这种基于中断的受控通道攻击[55, 83]可以与微架构侧通道相结合，以执行细粒度的秘密渗透[12,24,62,77,84]。 最近的 TEE 设计尝试通过限制中断注入方式 (SEV-SNP [3]) 或由 TEE 实例本身处理某些中断 (CURE [9]) 来减轻此类攻击。 此外，对于 I/O 事件，对所有 I/O 流量进行基于软件的加密成为必要的对策，需要由 TEE 实例本身执行。

RTPM-only mode

仅 RTPM 模式被认为是最安全的模式，因为所有操作都在 TCB 内执行。 对于上下文切换等高度机密的操作，大多数TEE采用RTPM-only模式。 AMD SEV 和 SEV-ES（使用无保护或 RTPM 保护模式）缺乏足够的保护，导致上下文切换期间出现相应的泄漏[32,53,56,93]。 另一方面，将所有操作放在 RTPM 中可能会显着增加 TCB 大小，并且不适合复杂任务。 例如，在AMD SEV/ES/SNP的设计中，主要的RTPM是安全协处理器。 然而，由于其功能有限，在该安全协处理器中包含页面错误处理是不切实际的。 在这种情况下，将复杂的任务委托给 RTPM 会严重影响性能。 在这种情况下，只有软件RTPM（例如Intel TDX中的可信模块或RISC-V蓬莱中的安全监视器）才能有效地管理相对复杂的任务。

RTPM-guarded mode

RTPM 保护模式在安全优势和与仅 RTPM 模式相关的 TCB 大小的潜在增加以及无保护模式提供的资源管理功能之间取得了平衡。 然而，RTPM保护模式确实存在三个缺点：

首先，它仍然可能导致旁路信息泄漏。 例如，采用 RTPM 保护模式进行页错误处理的 TEE（例如 Intel SGX 和 AMD SEV）将遭受页错误控制通道攻击 [32, 54, 65, 66, 67, 79, 85, 89, 93、98]。 通过操纵 PTE（例如，清除“当前”位），攻击者可以恶意触发页面错误，从而使攻击者能够在页面粒度上观察 TEE 实例的内存访问模式。

其次，RTPM 保护模式通常涉及权限切换在不可信操作系统和 RTPM 之间，这可能会导致性能较差，例如，在 RISC-V Penglai 的情况下，在更新页表时，RTPM 内部的安全监视器需要遍历所有现有页表才能批准更新请求。 这种设计选择已被确定为蓬莱的主要性能瓶颈之一。

第三，RTPM 保护模式的实现可能会忽略某些特殊场景，例如，在 SEV-ES 中选择了 RTPM 保护模式。 上下文切换时，当不受信任的主机在某些极端情况下故意操纵 CPU 亲和力时，可能会出现 TLB 误用 [56]。

Instance-assisted mode

一些 TEE 设计允许实例直接协助或参与某些资源管理任务。 采用这些设计的主要原因有两个：

（1）相应的资源可能是虚拟的，或者

（2）TEE设计的目的是避免涉及不可信的主机并防止额外信息的泄露。

然而，在 TEE 设计中采用实例辅助模式时务必谨慎，因为 TEE 用户可能并不总是在合规性方面采用正确的策略。 恶意TEE用户也可能尝试利用实例辅助模式，从而造成不良影响。 例如，如果整个地址转换在 TEE 内部执行，则恶意 TEE 实例可以访问任意内存页面。 此外，如果中断处理完全由 TEE 控制，则 TEE 实例可能会拒绝放弃 CPU 资源，从而使主机无法使用这些资源。

Security Implications: Known Design Flaws

为了更深入地研究各种设计选择的安全影响，我们编制了针对 TEE 的已知攻击的完整列表（表 2）。 针对 TEE 的攻击有多种类型，包括易受攻击的系统设计、微架构side-channel、硬件缺陷、推测执行漏洞和其他微架构缺陷。 大多数现有攻击都属于side-channel攻击类别，大多数商业 TEE 的威胁模型都明确指出将其排除在外 [22, 44]。 我们的论文主要关注 TEE 运行时的保护以及资源管理方式的安全影响。 因此，在本节中，我们专门深入研究 TEE 运行时易受攻击的系统设计。 所有其他已知的不同类型的攻击将在第 6 节中讨论。

由于 TEE 设计中存在漏洞的系统设计而导致的攻击在特定的极端情况下无法实现其安全目标。 现有的攻击通常会利用这些极端情况下的不一致行为，从而损害 TEE 的整体安全性。 值得注意的是，无保护模式或 RTPM 保护模式更容易出现设计缺陷，因为不受信任的主机可能会影响相应的任务。 例如，在 AMD SEV 中，寄存器值在上下文切换期间不受保护 [32, 93]，这为攻击者提供了更改其值并破坏 VM 实例完整性的时间窗口。 同样，对嵌套页表（NPT）[65,66,67]和TLB[56]缺乏足够的保护（RTPM保护模式）也会导致安全漏洞。

表 1 列出了由易受攻击的设计引起的所有已知攻击。由微架构缺陷引起的攻击，例如不安全的内存加密引擎 [27, 94] 或可以绕过 TEE 隔离的特殊指令 [99]，也可以被视为源于易受攻击的攻击 TEE 设计在某种程度上。 这是因为这些微架构设计忽略了与 TEE 相关的极端情况。 然而，这些攻击主要归因于制造商 TCB 本身的缺陷，而不是系统设计和运行时管理任务中的问题。 因此，我们将它们单独分类为不同类别的攻击。
此外，值得注意的是，大多数源自易受攻击的系统设计的已知攻击主要与 SEV 系列相关。 这可以归因于 SEV 是针对机密虚拟机的早期设计，它在开发过程中可能忽略了某些极端情况。 这一发现对于我们对 TEE 设计的分析非常有价值，因为它使我们能够检查 SEV 的三个版本（SEV、SEV-ES 和 SEV-SNP）的演变以及为解决现有攻击而实施的缓解措施，从而揭示这些变化 在TEE设计中。

Case Study: Evolution of Protection Mechanisms in AMD SEV

在本节中，我们将详细分析由于易受攻击的系统设计而导致的 SEV 攻击，并讨论这些攻击的根本原因。

Context Switch

在AMD SEV和SEV-ES中，上下文切换时分别采用无保护模式和RTPM保护模式。 这意味着在上下文切换过程中，所有/部分资源由不受信任的虚拟机管理程序管理。 这导致了一些针对上下文切换阶段的攻击，包括未加密的寄存器攻击、TLB中毒攻击和未验证的加密攻击。

Unencrypted Register Attacks

如果没有 SEV-ES 和 SEV-SNP 扩展，基线 SEV [44]（无保护模式）中的 VMEXIT 操作的行为与虚拟化中的传统上下文切换非常相似。 硬件将VM的寄存器值直接保存到VM控制块（VMCB）区域，并从主机保存区域恢复主机的寄存器值。 此外，在 VMEXIT 和 VMRUN 操作期间，CPU 会更新“ASID”寄存器，该寄存器存储用于区分主机和不同 TEE 实例的 ID。

未加密的 VMCB 和不受保护的模式会导致各种攻击 [32,78,93]，从而破坏受 SEV 保护的 VM 的机密性和完整性。 例如，SEVerESt 攻击[93]表明，通过在 VMEXIT 操作后持续监视存储在 VMCB 区域中的寄存器值，攻击者可以推断 SEV VM 内正在执行的指令或指纹应用程序。 同样，Hetzelt 等人。 [32]表明攻击者可以在VMEXIT之后修改RIP寄存器来执行面向返回编程（ROP）攻击。 AMD 通过利用 RTPM 在上下文切换期间通过加密保护 VM 的寄存器值，修复了 SEV-ES 和 SEV-SNP 中的寄存器泄漏漏洞。 具体来说，SEV-ES 和 SEV-SNP 中的 CPU 微码现在对 VM 的寄存器值进行加密，并将密文存储在 VM 保存区 (VMSA) 中。

TLB Poisoning Attacks

在 SEV 和 SEV-ES 中，RTPM 在 VMEXIT 或 VMRUN 操作期间不会主动执行 TLB 刷新。 这种性能优化与没有 TEE 的传统 KVM 设计相一致，通过为 VM 的 vCPU 分配唯一的地址空间 ID (ASID) 可以避免频繁的 TLB 刷新，并且这种 ASID 标记可以禁止对脏 TLB 条目的非法访问。

但是，对于受 SEV 保护的 VM，同一 VM 中的所有 vCPU 的 ASID 需要保持一致，因为 ASID 也由硬件识别以选择内存加密密钥。 因此，在某些特殊情况下，SEV 利用不受信任的主机强制执行 TLB 刷新，例如同一逻辑 CPU 核心上同一虚拟机的 vCPU 之间的上下文切换。 TLB 中毒攻击探索了这种由管理程序控制的 TLB 刷新，并表明攻击者可以破坏受害虚拟机的两个 vCPU 之间的 TLB 隔离。 具体来说，图 6 解释了这种攻击模式的微架构状态的更新。我们将两个 vCPU 称为“受害者 vCPU”和“攻击 vCPU”。 在所提供的示例中，攻击 vCPU 旨在直接利用受害 vCPU 的 TLB 条目残留。 如图 6 所示，在受害 vCPU 的 VMEXIT 期间，RTPM 仅清除寄存器，但不刷新 TLB。 随后，在攻击者 vCPU 的 VMRUN 期间，攻击者的寄存器被加载。 当攻击者随后使用受害者 vCPU 之前使用并保留在 TLB 中缓存的程序计数器值（存储在 RIP 寄存器中）执行读取操作时，来自受害者的 TLB 条目将被直接继承和使用。 共享相同的 ASID。 这种操作序列模式反过来又会损害受害虚拟机的完整性。

AMD SEV-SNP 通过在上下文切换期间使用仅 RTPM 模式来减轻 TLB 中毒攻击。 具体来说，CPU 微代码现在执行 TLB 刷新检查，并在必要时通过记录硬件保护区内的 vCPU 状态来强制执行 TLB 刷新 [4]。 通过消除不受信任的虚拟机管理程序对 TLB 资源的控制，可以减轻此类攻击。

Unauthenticated Encryption Attacks

未经身份验证的加密攻击[53]是通过在上下文切换期间篡改ASID来进行的，导致使用不正确的内存加密密钥。 在AMD SEV和SEV-ES中，攻击者可以在VMEXIT之后修改VMCB中存储的ASID，导致后续VMRUN使用错误的密钥来解密访问的内存。 从仅使用 RTPM 模式的 AMD SEV-SNP 开始，硬件会在 VMRUN 期间检查所有访问页面的所有权，从而有效缓解此类攻击。

Instruction Emulation

在SEV的所有三个版本中，均采用无保护模式进行指令仿真。 这意味着 TEE 实例直接依赖于虚拟机管理程序提供的模拟结果。 因此，虚拟机管理程序可以通过提供不准确的寄存器值来控制 TEE 实例的操作。 为了减轻这种风险，TEE 实例可能会实施内部软件检查以过滤掉潜在的错误模拟。 然而，这种防御措施既不强制执行也不全面。

Wrong CPUID Information Attacks

一个例子是错误的 CPUID 值 [3]。 具体来说，虚拟机管理程序可以为受害 VM 提供不正确的 x86 扩展保存区域大小，从而导致 VM 分配比预期更小的内存区域。 随后，当 VM 实例稍后执行 XSAVE 指令时，可能会触发潜在的缓冲区溢出。 为了解决此问题，SEV-SNP 通过 AMD 安全处理器 (AMD-SP) 添加了额外的 CPUID 过滤功能。 AMD-SP可以粗略地验证CPUID结果，以确保其落在合理的范围内。

Memory Allocation

在 SEV 和 SEV-ES 中，都采用弱形式的 RTPM 保护模式来保护内存分配。 具体来说，内存分配使用 RTPM 提供的内存加密密钥进行保护。 例如，如果不受信任的虚拟机管理程序将 TEE 实例 A 的内存页面映射到 TEE 实例 B 的现有内存页面，则实例 A 可以获得对实例 B 的内存页面的访问权限。但是，由于该内存页面是使用唯一的密钥加密的 对于实例 B，实例 A 将无法检索受保护的明文。 然而，这种弱RTPM保护模式忽略了TEE实例内内存分配的映射信息，导致一系列源自未受保护的嵌套页表（NPT）的攻击。

Unprotected Nested Page Table Attacks

在 AMD SEV 和 SEVES 中，NPT 由不受信任的虚拟机管理程序维护。 虚拟机管理程序可以将受害虚拟机的来宾物理地址重新映射到同一虚拟机所拥有的另一个系统物理地址，以更改其控制流或破坏其数据机密性。 赫策尔特等人。 [32]首先讨论了通过重定向地址转换来改变VM执行流程的可能性。 类似的方法也可以应用于数据页[65,66,67]。 在 SEVered 攻击 [66] 中，攻击者以某些网络应用程序（例如网络服务器）为目标，并将来宾物理地址从应该包含网络数据的系统物理地址重新映射到包含受害虚拟机数据的任意系统物理地址。

DISCUSSION

Other Attacks

除了源自 TEE 设计缺陷的漏洞外，还存在各种其他类型的针对 TEE 的攻击（表 2）。 虽然某些攻击被排除在 TEE 的威胁模型之外（例如side-channel攻击），但当前的研究表明这些攻击已成为针对 TEE 的真正威胁。

Side-channel attacks

尽管侧通道攻击已被证明是云环境中的威胁 [59, 100]，但特权攻击者的强烈假设使得侧通道攻击在 TEE 环境中变得更加强大，原因有两个。

首先，攻击者可以访问特权接口，例如性能计数器[30]和功耗分析器[57]，这些接口可用于获得更多用于推理的侧通道。

其次，攻击者可以通过有意控制全局资源[12,24,62,77,84]来收集更细粒度的信息，例如设置CPU亲和性或使用受控通道攻击。

因此，一些传统的side-channel攻击给 TEE 设计带来了额外的威胁。 例如，CacheQuote [24] 对 Intel SGX 使用的远程认证过程的安全性提出了挑战。 由于证明管理程序（引用飞地）还与其他不受信任的线程共享 CPU 资源，CacheQuote 表明它可以利用中断控制的 L1 缓存侧通道成功泄露扩展隐私 ID (EPID) 协议中使用的长期秘密。

此外，一些side-channel攻击利用新的side-channel信息从 TEE 中推断秘密。 一种特殊类型的侧信道攻击是针对 AMD SEV 的密文侧信道攻击，AMD SEV 监视内存加密后的密文以推断秘密 [52, 55]。 此外，性能计数器、功耗接口或CPU频率也可能被滥用来监控TEE实例以泄露敏感数据[30,52,57]。

Controlled-channel attacks

受控通道攻击是指特权攻击者可以控制 TEE 实例使用的某些资源（例如页表或 CPU 调度）来故意暂停其执行，从而提供额外的信息和适当的时间窗口来进行其他攻击（例如，侧面攻击）。受控通道攻击通常是由于选择 RTPM 保护或无保护模式所致。

Interrupt-based controlled-channel attacks

大多数TEE设计在CPU调度上采用非保护模式（§4.3），使得攻击者能够强制TEE实例退出并进行细粒度攻击。 例如，SGX-STEP [83] 首先表明攻击者可以使用 APIC 定时器中断以指令级粒度单步执行 SGX enclave。 AMD 平台也研究了类似的攻击，以监控 SEV VM 的状态。 SEV-STEP [95] 和 CipherLeaks 攻击 [55] 使用定时器中断在指令页内步进 SEV VM 的执行。 这种基于时间中断的受控通道可以与其他漏洞（例如缓存侧通道）结合使用，以获得细粒度的攻击窗口。 为了解决这些受控通道攻击，最近的学术研究一直致力于通过软件-硬件协同设计来减少不可信操作系统的影响 [21, 70]。

Page table-based controlled-channel attacks

正如§4.4.3中介绍的，在页表维护中不采用RTPM-only模式的TEE设计，例如Intel SGX和AMD SEV，将遭受基于页表的受控通道攻击[32,54,65, 66、67、79、85、89、93、98]。 通过操纵页表中的页表项（PTE）（例如，清除“当前”位或“脏”位），攻击者可以故意引发页面错误或观察TEE实例尝试访问某些内存的时间点 页。 这些异常或观察结果会立即中止 TEE 实例的执行，以帮助攻击者在所需的执行点拦截 TEE 实例或推断其行为。 例如，通过收集页面级别的内存访问轨迹，piginghole [79] 表明，当加密实现具有依赖于秘密的页面访问轨迹时，它可以窃取 SGX enclave 使用的密钥。

Speculative Execution

推测执行攻击很大程度上受不同平台上 CPU 设计的影响。 出于性能原因，许多 CPU 供应商选择与推测执行并行实施与权限相关的检查，这首先在 Intel CPU 上被 Meltdown [58] 和 Spectre [46] 攻击利用，以绕过基于软件的权限隔离并使用侧通道来执行 泄露。 随后，大量研究工作深入研究了跨各种微架构的推测执行相关攻击，包括 L1 数据缓存 [86, 88]、分支目标缓冲区 (BTB) [3, 16]、返回堆栈缓冲区 (RSB) [47]、Line 填充缓冲区（LFB）[35,76,82,86,87,88]，单指令多数据（SIMD）缓冲区[63]等。由于TEE的强大威胁模型，不同平台上的TEE设计已成为 许多投机攻击的主要目标。 值得注意的是，推测执行更多的是与安全域之间的隔离相关的普遍问题，而不仅仅是 TEE 特有的设计问题。

Other Microarchitectural Flaws

除了推测执行攻击之外，还有其他源自微架构缺陷的攻击。 这些攻击利用 SoC 内的硬件问题，导致 TEE 数据被访问或操纵。 这些攻击违反了 TEE 的威胁模型，其中 SoC 本身被认为是可信的。 因此，它们通常与高级 TEE 设计无关，这使得它们更难以检测。 例如，在AMD Zen1架构中，人们发现内存加密引擎使用了不安全的加密模式和非随机调整函数[27, 94]。 这使得攻击者能够进行密文重放攻击。 另一种类型的微架构缺陷是非法数据转发，攻击者可以使用侧通道或未定义的寄存器未经授权访问或推断 TEE 实例中剩余的陈旧数据。 这些攻击通常是由于不完整的 CPU 设计导致的，这些设计允许某些指令 [99] 或隐藏缓冲区 [10, 37] 绕过 TEE 与不可信世界之间的隔离。

Hardware Flaws

硬件缺陷也可能被用来危害 TEE。 例如，当电压下降时，处理器可能会表现异常。 因此，当攻击者在运行 TEE 实例时可以通过物理访问或软件接口操纵处理器的电压时，安全检查可能会被绕过，从而导致机密性甚至完整性被破坏 [17,45,69,73]。 硬件缺陷的另一个例子是 Rowhammer 攻击，它基于 DRAM 中已知的硬件缺陷，该缺陷会触发随机位翻转，这可能会在 TEE 配置中被滥用来锁定处理器 [40]。

Limitations of TRAF

TRAF 专注于对 TEE 进行彻底、系统的反汇编，分析其设计选择和影响。 然而，这种高层次的反汇编主要是为了突出TEE设计的考虑因素和趋势，但不足以评估TEE设计的详细实现的安全性。 TRAF不选择从微架构角度进行安全分析的主要原因是TEE设计的具体实现存在巨大差异，增加了对每个实现细节进行系统化的挑战。 列举每项任务的实现细节很容易让新研究人员感到困惑，并偏离 SoK 论文的预期目的。 相比之下，由于 TEE 引入了独特的分层模型（TEE 实例由虚拟机管理程序管理，但必须防止信息泄漏），如何在这种独特的威胁模型下安全地管理资源，对有 TEE 需求的服务器操作系统提出了新的挑战 。 通过这篇 SoK 论文，我们的目标是通过 TEE 上下文揭示不同运行时任务中的适当设计选择。

RELATED WORK

一些现有的工作也做出了很大的努力，从不同的角度总结或比较 TEE 设计，例如系统化保护机制、性能比较以及对具体 TEE 设计进行深入检查。

Existing SoK works about TEE

Schneider等人[75]也研究了基于硬件的TEE设计如何提供安全性。 他们主要研究TEE设计的实现细节，而不是关注高级设计选择，例如如何在不受信任的操作系统和RTPM之间协调管理任务。 他们分类并指出TEE设计通常通过空间、时间或混合方法提供数据隔离。 同时，他们关注更广泛的TEE设计，不仅包括服务器级TEE，还包括嵌入式TEE设计。 然而，TEE的实现细节众多，工作场景多样，可能导致分类分散，这给新研究者把握TEE设计的重点带来了挑战。 相比之下，我们的SoK从TEE中资源管理的挑战开始，提出了一个类似于操作系统教科书中的知识分类的结构化框架。 然后可以使用这个框架来分析TEE对各种运行时任务的效率、性能和安全性的考虑，以及它们潜在的安全威胁。

Zhao等人[101]对基于软件和基于硬件的tee进行了详细的解释。 然而，基于软件和基于硬件的tee之间的区别导致了建立结构化分析框架的失败，正如我们在本文中所做的那样。 Paju等人[71]进行了一项研究，涉及学术界和工业界建立在tee上的200多个可信应用程序。 它们涵盖了在不同TEE平台上开发可信应用程序时遇到的各种应用程序场景和设计挑战，包括TCB大小、性能和可用性。 Mofrad等[61]和Akram等[1,2]对tee在各种工作场景下的性能进行了概述和分析，探讨了tee的不同性能瓶颈。

Studies of a specific TEE design

一些作品侧重于对特定TEE设计的解释[15,22]。 Costan等人[22]作为Intel SGX的重要教育文档，并启发了许多关于基于enclave的tee的后续工作。 Cerdeira等人[15]研究了ARM TrustZone和基于TrustZone和Cortex-A处理器的现有安全系统。 Lu等人[60]和Dessouky等人[26]总结了RISC-V上的学术TEE实现。

Other summarizing works on TEEs

Munoz等人[68]对tee攻击进行了调查，包括软件攻击、架构攻击、侧信道攻击和微架构攻击。 并讨论了相应的对策。 Sabt等人[74]定义了TEE及其一般安全属性。 Demigha等[25]列举了四种著名的TEE设计，分析了其支持的特性，并讨论了适用的工作场景。 Jauernig等人[41]深入研究了机密云行业的安全属性、应用程序和未来方向。

CONCLUSION

在本文中，我们系统化了基于硬件的服务器级 TEE 的设计选择和安全含义。 我们提出 TRAF 框架作为解构 TEE 设计的一种手段，从而能够根据现有 TEE 的总体设计选择更深入地理解它们。 通过对现有 TEE 设计的分析，我们显示出大多数 TEE 采用类似设计选择的明显趋势。 此外，通过分析针对 TEE 的现有攻击，我们研究了各种 TEE 设计选择的潜在影响，并深入研究了这些攻击出现背后的原因。