Abstract

我们提出了一种解决方案 MyTEE，即使在不存在主要硬件安全原语（例如，用于内存访问控制的 ARM TrustZone 扩展）的最坏情况环境中，也可以构建可信执行环境 (TEE)。 MyTEE 的核心是制作用于内存隔离的页表、过滤 DMA 数据包以及启用安全 IO。特别是对于安全IO，我们屏蔽了控制器的IO缓冲区和内存映射寄存器，并安全地提升了设备驱动程序的部分代码块的权限，以提供访问受保护对象的权限。通过这样做，可以免除在 TEE 中托管设备驱动程序（全部或部分）的需要，这可能会引入新的攻击面。 MyTEE 的概念验证 (PoC) 是在 Raspberry Pi 3 板上实现的，该板不支持构建 TEE 的大多数重要安全原语。此外，还演示了三个带有硬件 TPM、帧缓冲区和 USB 键盘的安全 IO 示例，以展示我们方法的可行性。

INTRODUCTION

可信执行环境（TEE）是保护嵌入式设备上的安全关键服务和数据的合理安全措施之一。特别是，考虑到 ARM 在移动和嵌入式设备中的高市场份额（移动、物联网和车载系统占 90%），ARM 处理器的安全扩展 TrustZone 是在嵌入式设备上启用 TEE 的最有力措施。它提供了各种安全扩展，例如分离CPU的安全状态、基于硬件的内存访问控制和安全IO。利用这些特征，已经提出了各种TEE应用程序[27]、[28]、[32]、[33]、[35]、[38]、[40]、[41]、[43]、[50]、 [52]–[54]、[56]、[57]。

尽管 TEE 有效并在广泛的研究中得到采用，但由于以下原因，TEE 在实际工作环境中的部署受到限制。嵌入式设备有时在构建 TEE 所需的硬件组件方面并不完整。例如，部署在商业设备[16]（例如智能集线器）中的Broadcom BCM2837 SoC [7]不支持用于内存和外设隔离的TrustZone扩展[12]。即使硬件组件可用，整个可信应用程序（TA）开发（和部署）流程可能需要供应商参与使用专有 API 并执行安全验证 [9]。这可以加快新第三方服务的上市时间。

我们提出 MyTEE 来解决在嵌入式设备上托管 TEE 的限制。它的设计基于一个严格的假设：大多数 TrustZone 扩展不受支持（CPU 的安全状态除外）。换句话说，不支持用于内存访问控制的 TrustZone 地址空间控制器 (TZASC) 和 TrustZone 内存适配器 (TZMA)，以及用于建立安全 IO 通道的 TrustZone 保护控制器 (TZPC)。用于防止恶意直接内存访问（DMA）的输入/输出内存管理单元（IOMMU）也不可用。如果没有这样的硬件安全原语，MyTEE 会隔离 TEE 区域，防止 DMA 攻击，并在 TEE 和外设之间动态构建安全 IO 通道。

内存保护是通过有意管理页表来实现的。利用将中间物理地址映射到物理地址的第 2 阶段页表 [15]（即 x86 [3] 上的扩展页表）来将 TEE 与不受信任的操作系统隔离。 MyTEE 的一部分是作为小型虚拟机管理程序实现的，这也可能受到损害。由于一旦攻击者获得了Hypervisor权限，基于stage2分页的保护就不再有效，因此我们还确保Hypervisor的页表不映射TEE并且是不可变的。然而，即使仔细管理页表，MyTEE 的安全性仍然可能被恶意 DMA 破坏。为了解决这个问题，我们实现了一个 DMA 过滤器，用于捕获、验证和模拟 DMA 控制器的任何内存映射 IO (MMIO)。为了实现安全 IO，我们将任务委托给不受信任的操作系统，该操作系统向外围设备发送请求（例如 TPM 命令），而不是在 TEE 中移植设备驱动程序。用于可靠通信的最小但必不可少的组件（例如用于外设输出的缓冲区和用于外设控制器的 MMIO 区域）受到第 2 级分页的保护。然后，设备驱动程序的部分代码块被授予管理程序权限来访问安全对象并记录事务以供受信任应用程序 (TA) 将来进行验证。

我们在配备不支持 TrustZone 扩展的 Broadcom BCM2837 SoC 的 Raspberry Pi 3 开发板上实现了 MyTEE。 OP-TEE [4] 和带有 Linux 4.15 的 Raspbian OS 分别作为 TEE 和丰富执行环境 (REE) 软件平台托管。 ARM 可信固件已修补以启用内存隔离。 DMA 过滤器和 MyTEE 服务（例如设备驱动程序的权限升级）作为微型管理程序的陷阱处理程序。特别是，MyTEE 服务由植入设备驱动程序中的 MyTEE API 调用。使用 API 开发了三个示例应用程序，它们为 TPM、帧缓冲区和 USB 键盘构建安全 IO。在性能评估过程中，我们观察到整个系统的开销可以忽略不计。相比之下，示例应用程序的开销根据外设类型和基线延迟而变化。最后，这项工作的贡献可总结如下：

我们建议 MyTEE 来构建和增强 TEE，即使没有 TZASC 和 TZPC 等强制 TrustZone 硬件扩展的支持。

可以通过为现有设备驱动程序配备 MyTEE API 来建立安全 IO，而不是将它们托管在 TEE 中。所提出的方案可以很容易地扩展以构建具有各种外设的安全 IO 通道。

分析了硬件 TPM、帧缓冲区和 USB 键盘的外围设备和控制器设备驱动程序，然后将其作为 MyTEE 示例应用程序进行保护，以证明我们的方法的可行性。

BACKGROUND

ARMv8 Architecture

在这里，我们讨论 ARMv8.0 架构上的 CPU、TrustZone 扩展和虚拟化的安全状态。

Security states

在启用 TrustZone 的系统上，有两种 CPU 安全状态：安全和非安全。非安全状态提供三种权限模式：用户、内核和管理程序。富执行环境 (REE) 在此状态下运行。 CPU 的安全状态更改为安全，可以在 TEE 中运行安全关键软件。一般来说，安全状态下可以使用用户模式、内核模式和监视器模式（从ARMv8.4开始，还支持Hypervisor模式）。运行在监控模式下的软件充当REE和TEE之间的看门人，保存和恢复每个环境的上下文。不限于网守，还利用监控模式来实现内核完整性监控[27]、[32]。

TrustZone extensions

除了 CPU 的安全状态之外，还定义了 TrustZone 硬件扩展，并且可以将其集成到 SoC 中。 TZASC 和 TZMA 使 TEE 内存能够与系统的其余部分隔离。具体来说，他们对内存区域进行划分，并根据安全状态为每个区域配置不同的访问权限。例如，我们可以强制只在 CPU 处于安全状态时才访问分配给 TEE 的内存区域。 TZPC动态改变外围设备的状态为安全或非安全。通过此，可以在具有安全状态的外设和 TEE 之间建立安全 IO 通道。

Virtualization

从 ARMv8.0-A 开始，ARM 将硬件辅助虚拟化定义为强制功能。第二阶段分页将中间物理地址（虚拟机视图的物理地址）转换为机器地址。另外，可以在第二阶段页表项中配置对机器地址的访问权限。任何第 2 阶段分页错误（例如访问冲突）都会被管理程序捕获。第 2 阶段页表的基地址设置为管理程序系统寄存器，即虚拟化转换表基址寄存器 (VTTBR)。之前的工作利用这个额外的转换层将安全关键软件与不受信任的操作系统隔离[36]、[45]、[55]。

Communication with Peripherals

外设使用各种协议与主机通信，例如串行外设接口 (SPI)、集成电路 (I2C)、外设组件互连 (PCI) 和通用串行总线 (USB)。每个协议的控制器执行管理通信的操作，例如分配设备地址、选择通信通道以及发起事务。这些操作是通过设置内存映射控制器寄存器来进行的。

用户进程与设备驱动程序交互以与外围设备通信。通常，通信涉及控制器 (cDrv) 和外设 (pDrv) 的设备驱动程序。 pDrv 为用户进程提供接口，例如 ioctl、write 和 read。此外，它还创建一个协议（例如 USB）消息，传递所需的信息，例如 IO 缓冲区和外设的地址。

cDrv 从消息中检索信息并通过 MMIO 配置控制器。此外，它还从 IO 缓冲区读取数据并将其传送到连接到控制器的外设。来自外设的响应也会被读取并写入缓冲区。这些内存操作可以通过DMA来完成，以最大限度地减少CPU的负担。例如，SPI 控制器的 cDrv 可以设置 DMA 控制器，以便将 DMA 操作的源和目标分别设置为缓冲区和 SPI FIFO 寄存器。图 1 说明了应用程序和外设之间的通信通道。

MOTIVATION

正如第 II-A 节中所讨论的，各种安全扩展已被定义并且可以集成到 SoC 中。然而，在 SoC 中实现安全扩展是可选的；因此，某些 SoC 中不存在其中的部分或全部。对最新可信固件存储库 [5]、[18]、[21] 的快速分析以及与一些供应商的咨询很容易发现这种不完整的实现。表 I 显示了缺少扩展的 SoC 示例。 BCM2837 [7] 部署在工业控制器和智能集线器等生产 IoT 设备 [16] 中，不提供 TrustZone 扩展。 SC9863A [26]、MT6739 [20] 和 Exynos 7570 [19] 托管在低端手机 [22]–[24] 和平板电脑 [25] 中，以降低成本并瞄准特定市场（例如发展中国家） 。相反，即使提供了扩展，它们通常也是专有的，这需要 SoC 供应商密切参与安全服务的开发和部署过程 [9]，因此可能会阻碍上市时间要求。 MyTEE 旨在通过提供一种无需依赖硬件安全扩展来创建 TEE 的替代解决方案来改善此问题。

ATTACK MODEL AND ASSUMPTION

除了假设操作系统不受信任之外，还假设第 II-A 节中说明的 TrustZone 硬件扩展未在我们的目标系统中实现。因此，即使安装了TEE软件平台，也是完全不安全的[12]。

相比之下，CPU 的安全状态和虚拟化（在 ARMv8-A 上被定义为强制功能）已得到实施和信任。我们还假设安全启动；因此，固件、引导加载程序和操作系统内核映像在引导时完好无损。这可以通过将图像放置在 SD 卡的不可变区域中来实现 [14]，而不是依赖于 TEE 中隔离的设备密钥，这在我们的攻击模型中是不可能的。而且，主机和外设硬件在物理上是隔离的，不是恶意的。因此，篡改 SD 卡或执行冷启动攻击 [31] 等物理攻击是不可能的。最后，我们的攻击模型中不考虑侧信道攻击[42]、[48]、[60]、[61]。

SYSTEM DESIGN

Overview

MyTEE 的目标是在严格限制的环境中启用 TEE，其中不支持硬件安全扩展。换句话说，像 OP-TEE [6] 这样的开源 TEE 平台即使部署在如此有限的环境中也可以通过 MyTEE 来保护。为了在没有 TZASC 的情况下支持内存保护，主动完整性监视器使用第 2 阶段分页 [15] 和去特权内核来隔离内存（第 V-B 节）。此外，监控 DMA 控制器的每个 MMIO 事务的 DMA 过滤器旨在防止 DMA 攻击（第 V-C 节）。对于安全 IO，pDrv 和 cDrv 使用 MyTEE API 进行了强化，以屏蔽控制器的 IO 缓冲区和内存映射寄存器，并允许部分设备驱动程序代码安全、无缝地访问它们（第 V-D 节）。图2描述了MyTEE的核心组件。值得注意的是，在虚拟机管理程序和监控模式下运行的 MyTEE 组件构成了我们的可信计算基础 (TCB)。特别是，过滤 DMA 和监督关键操作可以将可信组件与不可信操作系统严格隔离。进一步基于隔离构建安全IO等可信服务。

Execution Environments Isolation

MyTEE 由 TEE 和 REE 组件组成。植入设备驱动程序中的微型虚拟机管理程序和 MyTEE API 构成了 REE 组件。主动完整性监视器作为 TEE 组件在监视器模式下运行，以模拟内核和虚拟机管理程序的关键操作。这两个组件都通过仔细管理内核页表和第二阶段页表来受到保护。首先，通过从第二阶段页表中删除 TEE 和虚拟机管理程序的映射，MyTEE 确保不受信任的操作系统无法访问这两个区域。嵌入 MyTEE API 调用的内核文本和虚拟机管理程序文本也强制为只读。第 2 阶段页表是作为安全引导的一部分创建的。

对于设备驱动程序的权限升级（第 V-D 节），管理程序使用内核页表来映射其虚拟地址空间，而不是管理其自己的页表。这种方法使权限提升的代码块能够与虚拟机管理程序权限无缝运行。也就是说，可以使用虚拟机管理程序中的内核虚拟地址来访问内核 API 和动态分配的内核对象，而无需在单独的虚拟机管理程序页表中显式创建到它们的映射。为此，内核页表映射了除 TEE 之外的整个 REE（包括虚拟机管理程序）。然而，由于基于 stage2 分页的隔离，不受信任的操作系统无法访问虚拟机管理程序区域。此外，为了防止不受信任的操作系统或受损的虚拟机管理程序操纵页表，主动完整性监视器剥夺了内核和虚拟机管理程序的特权。与之前的工作[27]、[32]类似，（共享）内核页表设置为只读，完整性监视器验证并模拟页表更新；它确保新的页表条目不会映射到已分配给受保护组件和不变量（例如 TEE、管理程序、内核文本）的物理内存。

还模拟了其他安全关键操作，例如管理系统寄存器（例如页表基址寄存器）。特别是，此类关键操作的指令被用于进入 TEE 的安全监视器调用 (SMC) 所取代。通过将第 2 阶段页表放置在未映射到虚拟机管理程序或不受信任的操作系统的 TEE 区域中，可以防止攻击者获得虚拟机管理程序权限。我们还确保管理管理程序系统寄存器的安全关键指令不包含在管理程序中。例如，一旦寄存器在引导时初始化，配置虚拟机管理程序的 VTTBR 和系统控制寄存器 (SCTLR) 的指令就会从内存中删除。最后，采用基于观察点的内存保护技术[37]来监控对 DMA 控制器寄存器的特权恶意访问（第 V-D 节）。图 3 描述了 MyTEE 的内存布局。

DMA Filter

由于没有 TZASC，MyTEE 依赖于仔细的页表管理和剥夺来保护自身和 TEE 的内存。这可能容易受到 DMA 攻击，因为受损的外设可以任意读写任何内存区域。 DMA 攻击可以由两个不同的主体触发：恶意硬件或不受信任的操作系统。正如第四节所述，我们假设主机设备是物理隔离的，并且设备上的外围设备不是恶意的。因此，我们的工作中不考虑恶意硬件执行的 DMA 攻击。相反，不受信任的操作系统可以对 DMA 控制器进行恶意编程，从而破坏 MyTEE 的安全性。为了避免这种情况，MyTEE 会过滤掉可能导致 DMA 控制器执行异常操作的恶意 DMA 请求。因为 DMA 控制器有两种类型——内置 DMA 和外部 DMA控制器 - 根据控制器是集成到单个设备还是外部托管，应应用略有不同的监控策略。

External DMA controller

MyTEE 通过监控每个 DMA 控制块 (CB) 来保护外部 DMA 控制器。 CB是一种数据结构，指定传输数据的强制信息，例如源地址和目标地址、数据大小和传输类型。从图 4 中可以看出，由于 CB 的地址是通过 MMIO 传递到 DMA 控制器的，因此 MyTEE 会捕获并验证对 DMA 控制器的内存映射寄存器的任何访问。再次利用第 2 阶段分页来锁定寄存器。对锁定寄存器的访问会生成由 MyTEE 管理程序捕获的页面错误。 MyTEE 首先解引用 CB 地址并将 CB 复制到安全内存。由于可以通过设置 NEXT_CB 将多个 CB 链接在一起，NEXT_CB 表示下一个 CB 的 32 位总线地址，因此我们继续取消引用 NEXT_CB 的值并复制 CB，直到遇到设置为 0x0 的 NEXT_CB。

然后，验证复制的 CB 以阻止 DMA 访问任何受保护区域。根据 TXFR_INFO 中 TD_MODE 标志的设置，DMA 的数据传输以不同的方式执行。如图 5 所示，当设置该标志时，源内存缓冲区和目标内存缓冲区之间的传输以二维 (TD) 模式执行。源数据（其大小由 XLENGTH 指定）被传输到目标内存。此外，传输被执行YLENGTH次。 D_STRIDE和S_STRIDE包含有符号整数，并分别与SRC_ADDR和DST_ADDR相加，以确定下一次传输的源地址和目标地址。 TXFR_INFO 中的 SRC_WIDTH、SRC_INC、DST_WIDTH 和 DST_INC 标志也配置下一次传输的地址。具体来说，如果设置了 SRC_INC 或 DST_INC 标志，则每次从源读取存储器或向目标写入存储器时，根据 SRC_WIDTH 和 DST_WIDTH 的设置，将源地址和目标地址增加 4 或 32。相反，正常（非 TD）模式的工作方式更加简单。 TXFR_LEN 作为一个整体指定要传输的数据量。在此模式下，STRIDE 也会被忽略。

基于对 CB 如何对 DMA 控制器进行编程的观察，MyTEE 验证了 CB 的预期访问提前DMA过滤掉恶意CB。任何对控制器进行编程以对不可变区域（即内核文本、虚拟机管理程序、TEE）执行 DMA 的 CB 都被视为恶意并被阻止。最后，复制的 CB 地址（而不是原始地址）被写入 DMA 控制器寄存器，以消除验证和使用之间的竞争条件。将地址写入控制器寄存器后，CB 的每个字段都会复制到控制器中的只读寄存器中（图 4 中的 COPY_OF_CB）。此外，仅当源缓冲区和目标缓冲区都托管在安全内存中时，我们才允许 DMA 访问安全缓冲区。通过这样做，我们可以防止缓冲区中的秘密被泄露或被恶意 DMA 操纵。

Built-in DMA controller

DMA 控制器可以集成到其他设备中。在 Raspberry Pi 3 上，USB 控制器包含自己的 DMA 控制器。与外部 DMA 控制器相比，此类内置 DMA 控制器具有更简单的配置机制。它使操作系统能够直接更新配置数据传输存储器的大小和地址的存储器映射控制器寄存器，而不是使用首先位于存储器中然后被 DMA 控制器包含的 DMA CB。此外，该 DMA 控制器不会发生内存到内存的操作。源或目标设置为连接到 USB 集线器的外设的 FIFO。例如，执行用于获取USB键盘输入的DMA操作，使得从FIFO读取输入并将其写入主机存储器中的缓冲器。内置 DMA 控制器的这种性质简化了 DMA 过滤。控制器寄存器通过第 2 阶段分页锁定，以监视任何更新它们的尝试，但不需要将 CB 复制到安全存储器中。特别是，研究了用于配置缓冲区地址及其大小的寄存器的更新，以防止 DMA 访问内核文本和数据、管理程序、TEE 以及锁定的寄存器本身。此外，除了作为安全 IO 事务的一部分进行的访问之外，任何对安全缓冲区的 DMA 访问都会被丢弃（第 VI-B 节）。

Peripheral Isolation

TZPC和TZASC的缺失阻碍了基于TrustZone的安全IO的建立。在这里，我们说明 MyTEE 如何在不依赖此类 TrustZone 扩展的情况下在 TA 和外设之间建立安全 IO 通道。

1) Design primitives for secure IO

之前的工作[40]、[41]、[52]通过配置TZPC将外设的安全状态设置为安全，以便它们可以访问TZASC保护的内存，从而实现TEE和外设之间的安全IO。此外，外围设备驱动程序托管在 TEE 中。不幸的是，这种方法不能应用于不提供此类硬件保护单元的有限环境。将设备驱动移植到TEE也扩大了TEE的攻击面。 MyTEE 解决了这些限制并满足以下要求：R1）不应使 TEE 膨胀，R2）易于使用和部署，R3）确保 IO 可验证，R4）不应被滥用。

2) Temporal privilege escalation

为了满足 R1，我们重新访问设备驱动程序，而不是将它们托管在 TEE 中。 CA作为代理传递TA的请求。正如第 II-B 节中已经说明的，pDrv、cDrv 和控制器参与与外设的通信。我们保护其中的一部分以实现安全 IO，即分配用于传递 IO 请求和响应的控制器和缓冲区的内存映射寄存器。请注意，根据外设的类型和场景，保护安全缓冲区的机密性或完整性的要求有所不同。例如，应确保帧缓冲区中的医疗数据的机密性和完整性。相比之下，缓冲区中的 TPM 命令不是秘密，而是应完整传递给 TPM。

图6说明了MyTEE如何实现安全IO。通过管理第 2 阶段分页，内存映射寄存器被设置为不可从操作系统访问。安全（管理程序）内存中的预定义 IO 缓冲区按需使用，而不是内核分配的缓冲区。只有外围硬件和TA可以访问它们。即使从事安全 IO 的设备驱动程序也无法读取或写入这些屏蔽对象。因此，我们暂时提升管理安全缓冲区和寄存器的代码块的权限，以便驱动程序操作不会被阻止。正如第 V-B 节中所讨论的，共享页表来映射内核和管理程序。然而，由于实际的内核空间权限是由内核和stage-2页表的设置组合决定的，因此共享页表不会破坏虚拟机管理程序的安全性。也就是说，我们仍然可以在内核和管理程序之间强制执行不同的内存权限；仅当权限升级到虚拟机管理程序时，才能访问受屏蔽的对象。

权限升级是使用 MyTEE APIsmytee_priv_up 和 mytee_priv_down 进行的，它们包装了选定的代码块（表 II）。 API 以超级调用的形式实现。一旦调用 mytee_priv_up，当前 CPU 模式就会切换到管理程序，在安全内存中分配一个新堆栈，并禁用中断。尽管我们信任虚拟机管理程序，但权限提升的代码块可能容易受到攻击，从而使攻击者有机会获得具有虚拟机管理程序权限的任意读/写原语。这可能导致损坏 DMA 控制器，从而破坏基于分页的 TEE 隔离。我们采用基于调试观察点的内存保护[37]来防止这种攻击。观察点配置为在每次权限升级时监视 DMA 控制器的 MMIO 区域。因此，对控制器的任何写访问都会生成观察点异常，该异常由受信任的管理程序捕获和处理。最后，控制流转移到 API 调用之后的指令，而不会剥夺内核的权限。因此，mytee_priv_up 之后的代码块以虚拟机管理程序权限执行，因此可以访问安全缓冲区和寄存器。 mytee_priv_down 放置在代码块的末尾，并撤回 mytee_priv_up 设置的内容。请注意，为了防止攻击者滥用这些 API，我们强制只有作为内核文本一部分静态构建的驱动程序才能使用这些 API。我们检查链接寄存器（LR），当调用函数时，它会使用返回地址自动更新，以区分内核文本和可加载内核模块（LKM）。

由于使用了 MyTEE API，可以轻松建立与外设的安全 IO 通道（满足 R2）。这有助于最大限度地减少对特权软件（即管理程序）的修改，以反映外设特定逻辑和数据结构。例如，如第 VI-A 节中所讨论的，发送到 TPM 硬件的所有命令都必须记录下来，以便 TA 将来进行验证。日志记录需要理解 TPM 和协议的语义，例如 TPM 命令和 SPI 消息格式。使用 MyTEE API 使开发人员能够在相关设备驱动程序中管理此类外设特定数据和逻辑，而不必调整 MyTEE 管理程序。

3) Robustness and security

由于设备驱动程序中的 MyTEE API 调用会暴露给潜在的攻击者，因此它们可能会被滥用或绕过。攻击者可以通过改变控制流来简单地绕过 API 调用，以确保 MMIO 区域不被屏蔽。此外，权限升级的代码块可能被滥用以向外围设备发送恶意请求。这可以通过强制记录特权代码块中的操作并让 TA 验证操作来缓解，这符合 R3。 mytee_log_txn API 支持日志记录，它在权限升级块中调用以将事件记录在安全内存中。记录操作类型（例如，屏蔽 MMIO 寄存器、写入命令）、发送至外设的消息以及控制器的配置值。验证可以如下进行：检查(1)在事务期间缓冲区和MMIO区域是否被屏蔽以及(2)传递到外设的请求是否完好。可能存在对 MMIO 的恶意和多重访问。然而，只要 API 被正确植入，在特权块中执行的日志记录是不可绕过的。一旦检测到意外日志（例如 TPM 命令篡改），TA 可以简单地停止或继续迭代事务直到正常实现。

特权升级块中的内存操作（例如，write1）不应被滥用（R4）。为此，MyTEE 支持 mytee_verify_memopr API，该 API 验证特权块中内存操作的地址和大小。由于安全对象的地址是确定性的，例如外设的 MMIO 区域是由 SoC 制造商定义和固定的，因此只需检查内存操作是否在有效内存范围内执行即可进行验证。请注意，在验证之前，所有相关参数（例如源和目标的地址）及其取消引用的值都将编组到虚拟机管理程序内存中的安全堆栈中，以防止检查时间到使用时间 (TOCTOU)攻击。

此外，特权升级的驱动程序块可能容易受到攻击。然而，即使攻击者通过利用该漏洞获得了虚拟机管理程序特权的“write-what-where”原语，只读区域仍然是不可变的，因为TEE（即主动完整性监视器）是更新页面的唯一锚点表。尽管日志等可写对象可能会被破坏，但攻击的有效性仅限于 REE，因为设备驱动程序托管在 TEE 之外；因此，利用不能直接破坏 TEE。

最后，与一般 TEE 服务一样，受 MyTEE 保护的服务也容易受到拒绝服务 (DoS) 攻击。然而，如第六节所示，MyTEE 提供了一种方法构建安全 IO 激活指示器，防止将未受保护的 IO 伪装成安全 IO。此外，从 REE 和 TEE 对 IO 设备的同时访问的处理方式是 TEE 访问始终具有更高的优先级。这种方法与基于 TEE 的通用安全 IO 相一致，后者在从 TEE 进行 IO 时冻结 REE [46]、[52]。

4) Instrumentation example

清单 2 演示了使用 MyTEE 检测设备驱动程序的示例。在 Raspberry Pi 上，操作系统可以使用 Mailbox 协议与 GPU 进行通信 [10]。函数bcm2835_send_data旨在通过MMIO将消息写入Mailbox控制器，以便将其传递到GPU。在我们的示例中，假设 MMIO 区域已被屏蔽，并且我们尝试记录写入该区域的每条消息。如清单 2 所示，我们首先将原始 writel 函数放入新函数 mytee_wrapper_writel 中，并使用额外的 MyTEE API 来验证和记录写入。 API 的输入参数之一 MAILBOX_WRT 是一个常量值，指示当前日志记录上下文。在验证函数中引用它来检索带有邮箱控制器的 MMIO 的有效地址范围。开发人员可以添加更细粒度的过滤逻辑，以仅捕获邮箱传递的特定类型的请求消息（例如，显示配置）。由于 mytee_wrapper_writel 再次被 mytee_priv_up 和 mytee_priv_down 包装，因此它以虚拟机管理程序权限进行操作，因此可以访问受屏蔽的 MMIO 区域。请注意，在此示例中，我们没有封送 mytee_wrapper_writel 的参数，因为它们的大小为 4 个字节；因此，它们是使用通用寄存器来传递的。然而，传递地址变量作为参数需要在安全堆栈中进行编组。

SECURE IO APPLICATIONS

本节将通过三个示例来展示如何使用 MyTEE 强化 TEE 与外设（即硬件 TPM、USB 键盘和帧缓冲区）之间的通信通道。尽管实现（特别是如何使用 MyTEE API 检测驱动程序）可能会根据外设而变化，但 MyTEE 支持的安全 IO 可以如图 7 所示进行举例说明。

Secure TPM

对于安全 TPM 的 PoC，我们使用 Infineon 的 SLB 9670 TPM [11]。它是 TPM 2.0 的硬件实现，连接到 Raspberry Pi 3 上的 GPIO 引脚。操作系统和 TPM 之间的通信使用 SPI 协议进行。 TPM (pDrv) 和 SPI 控制器 (cDrv) 的设备驱动程序已集成在 Linux 主流中。来自 TPM 的用户应用程序的任何请求都会首先传递到 pDrv 并格式化为 SPI 消息。然后，消息通过 MMIO 写入 TPM 到控制器。 TPM 的响应也通过 MMIO 从控制器读取。两个 MMIO 均由 cDrv 执行。

TPM 的安全 IO 的构建和工作原理如下。 TA创建TPM命令并将其下发给代理CA。反过来，CA 将带有请求安全 IO 标志的命令传递给 pDrv。 SPI 的 MMIO 区域控制器受 pDrv 中的 mytee_shield_mmio 保护，并且此屏蔽操作也记录在安全（管理程序）内存中。在通过 pDrv 发送的 init 命令初始化 TPM 后，嵌入来自 CA 的命令和标志的 SPI 消息将发送到 cDrv。一旦 cDrv 检查该标志，它就会执行权限升级的 MMIO。为了实现这一点，bcm2835_wr 函数以与清单 2 中所示类似的方式进行检测。该函数被放置在新的包装函数中，然后在包装函数之前和之后调用 mytee_priv_up 和 mytee_priv_down API。用于参数编组、内存写入验证和命令日志记录的附加 API 放置在包装函数中。具体来说，我们在 SPI 消息中整理了命令及其长度字段。 bcm2835_wr函数将命令写入从机的FIFO（即TPM）；遵循 SPI 传输协议的循环中每次迭代都会写入一个字节。一旦所有命令都传递到 TPM，特权就会恢复到内核。

从 TPM 读取响应需要对受保护的 MMIO 区域进行特权读取访问。因此，bcm2835_rd 函数以类似的方式进行检测。读操作也以1字节粒度完成。 TPM 中的每个字节都写入安全内存中的缓冲区，而不是 SPI 消息中的缓冲区。随后，TA 通过检查日志来验证其 TPM 请求是否以可信方式进行管理，然后使用安全缓冲区中的输出。请注意，TPM 响应消息的标头包含事务的状态标志。具有成功状态的响应消息根据命令的类型传递输出（例如，随机数）。因此，只有具有成功状态的响应才会被过滤并写入安全缓冲区。此外，我们还维护一个事务标志，指示单个事务的完成，以防止在 TA 消耗输出之前发出进一步的（恶意）请求。该标志作为写入 TPM 命令的 MMIO 验证的一部分进行检查，并在消耗 TPM 输出后由 TA 清除。

Trusted USB Keyboard

在本节中，我们首先详细阐述主机与通用USB设备之间的通信机制。然后，我们通过提供与 USB 键盘强化通信的示例来演示 MyTEE 如何与 USB 设备建立安全 IO。

1) General USB Peripheral

USB 设备可以有多种配置。每个配置还可以定义多个接口。例如，USB 耳机具有麦克风和音频接口。每个单独的接口都有至少一个端点，该端点是外设处的硬件缓冲区，用于主机和外设之间的通信。有两种类型的端点：控制和数据。控制端点旨在设置和控制 USB 设备（例如键盘上的 LED 控制），而端点 0 专用于此目的。数据端点是可选的，是为数据传输而定义的。端点的方向是根据主机定义的。例如，IN端点用于从外设到主机的传输，而OUT端点用于从主机向设备传输数据。

在 Linux 上，USB 请求块 (URB) 是为与 USB 外设进行数据传输而定义的数据结构。 URB 由 pDrv 创建，包含事务所需的所有信息（例如端点、设备地址、缓冲区地址）。一旦 USB 控制器的 cDrv 从 pDrv 接收到 URB，它就会根据 URB 中的信息配置 USB 控制器以启动事务。一般来说，USB 控制器支持多个与外设通信的通道。每个通道都有映射到主机内存中的相同组配置寄存器。作为引导事务的一部分，cDrv 选择一个空闲通道并根据 URB 中的信息（例如设备地址和端点）对其进行配置。 URB 中的缓冲区地址也可以配置给控制器以启用主机和外设之间的 DMA。

DMA 完成会产生一个中断，该中断由内核线程捕获，最终调用 pDrv 注册的中断处理程序。中断的处理是根据URB中的更新信息来执行的。处理程序首先检查状态标志，该标志指示 URB 触发的上一个事务是否成功。如果状态标志设置为故障，则 URB 将重新发送到外设。处理程序执行外设特定服务例程以进一步处理带有成功标志的 URB。例如，参考URB来获取缓冲器中的扫描码。处理程序根据键盘映射 [8] 将扫描代码转换为按键代码。此外，键盘输入被写入文件中，以便应用程序可以使用事件（例如，/dev/input/eventX）。

2) Trusted Keyboard

基于对Linux下USB设备驱动的分析，我们利用MyTEE设计了可信键盘。可信键盘设计考虑了以下安全要求： (1) 用户应该能够识别当前是否与键盘建立了安全 IO。 (2) 应保证通信的保密性和完整性。

Control message inspection

我们使用 NUM Lock 键的 LED 作为安全 IO 激活的指示器。因此，只有当 TA 发起并请求可信键盘时，LED 才应该打开。 TA 首先在管理程序内存中设置可信键盘标志，并要求代理 CA 打开 LED。然后，CA 只需使用 xset 实用程序打开 NUM Lock LED [17]。这会触发 USB 键盘的 pDrv。在 pDrv 中，创建控制消息的 URB 并将其发送到 USB 控制器的 cDrv。请注意，如第 V-C 节所示，每个 DMA 数据包都是被监控。由于第 2 阶段分页的粒度（最小大小为 4 KB），这不仅会锁定 DMA 地址寄存器，还会锁定所有控制器寄存器。因此，我们基本上可以捕获任何配置控制器进行 URB 传输的尝试。

受益于这一特性，我们另外在虚拟机管理程序中实现了陷阱处理程序，以监视通道配置以及 DMA 数据包，从而实现对 LED 的访问控制。任何将设备（外设）地址和缓冲区地址写入控制器寄存器以进行通道配置的尝试都会受到监视。首先，通过解码写入通道特征寄存器（hcchar）的值，可以检索设备地址。我们将其与预定义的键盘地址进行比较，以过滤出其他外设的 URB。此外，还可以根据捕获的第二阶段页错误地址获取当前通道号。具体地，由于每个通道具有相同的配置寄存器的存储器布局，并且放置在连续的存储器中，因此我们可以根据第一通道地址与故障地址之间的偏移量来获取通道号。 DMA 控制器使用的以下缓冲区地址设置也会导致第 2 阶段页面错误。我们同样可以根据故障地址获取当前的通道号。如果当前通道是分配给键盘的通道，我们可以复制并解码安全（管理程序）内存中缓冲区的内容。仅当从解码内容中找到 LED 控制消息并且设置了可信键盘标志时，MyTEE 才会打开 LED。

Keyboard input protection

还通过监视控制器寄存器的 MMIO 来保护按键输入。我们根据第二阶段页面错误检索设备地址和通道号，其方式与控制消息检查所示的方式相同。唯一的区别在于我们如何管理因设置 DMA 缓冲区地址而引发的第 2 阶段分页错误。 DMA 使用获取的扫描代码更新缓冲区。应保护扫描码的完整性和机密性。为此，MyTEE 在处理捕获的 MMIO 时将缓冲区的地址与管理程序区域中分配的安全缓冲区的地址进行切换。通过这样做，我们可以确保不受信任的操作系统无法访问该缓冲区，但仍然可以获取扫描码，因为硬件（即 DMA 控制器）仍然可以访问安全缓冲区。

作为处理 DMA 完成中断的一部分，访问安全缓冲区以执行外设特定逻辑，例如扫描码转换。因此，需要升级权限才能从受保护的内存中读取数据。可以采用清单 2 所示的提升驱动程序代码块权限的方法来实现此目的；也就是说，访问安全缓冲区的代码块可以使用 mytee_priv_up 和 mytee_priv_down API 进行包装。为了简化实施，我们开发了一种新功能，集成了强制操作和最少操作，以翻译和保护键盘输入。然后，我们使用 MyTEE API 完整地包装该函数，而不是包装内核中访问安全缓冲区的分散代码块。在该函数中，扫描码被转换为按键码。此外，密钥代码被写入安全存储器以供TA将来使用。

请注意，可以通过以下方式执行进一步的操作设备驱动程序，超出了关键代码的翻译。例如，假设键盘支持音量控制键，则驱动程序可以将按键事件通知给另一个（例如，扬声器）设备驱动程序。在我们的示例实现中，我们让驱动程序的非特权部分继续执行此类任务。另请注意，由于按键事件产生的中断不会在 TEE 中直接处理。相反，使用 MyTEE 检测的操作系统和设备驱动程序会接管该任务。具体来说，每个关键事件都在 REE 中进行处理，直到 CA 完成收集用户输入。然后，TA消耗堆叠在安全存储器中的密钥代码。与直接处理 TEE 中的中断相比，我们的方法具有明显的优势，后者需要对操作系统和 TEE 进行额外更改，以将中断转发（和处理）到 TEE（以及 TEE 中），从而使系统设计复杂化并使 TEE 膨胀。

Tracking device address

在我们的示例中，设备地址应保持更新，以实现可靠的外设识别。为此，我们监视两个标准控制消息：GET_DESCRIPTOR 和 SET_ADDRESS。 USB 设备首次连接到 USB 端口时，其默认设备地址为 0x0。操作系统发送带有 GET_DESCRIPTOR 的 URB 以获取设备的 USB 类和协议等信息。 MyTEE 挂钩它来检测键盘连接。然后，进一步监视后面带有SET_ADDRESS的URB，其目的是为设备分配新的设备地址。

Trusted Display

在本节中，我们将演示 MyTEE 如何保护可信显示器的帧缓冲区。在 Raspberry Pi 上，视频核心（即 GPU）管理显示器的配置，例如帧缓冲区分配和显示分辨率设置。操作系统可以向视频核心发送显示配置请求。 CPU 和视频核心之间的处理器间通信是通过邮箱控制器进行的。任何请求或响应都是通过对邮箱控制器寄存器执行 MMIO 来交换的。

对于安全IO，我们首先确保显示配置不被恶意更改。为此，我们通过利用第 2 阶段分页来锁定邮箱控制器的内存映射寄存器。 mytee_shield_mmio 在 ioctl 处理程序中调用，用于 pDrv 中的显示配置（即 FBIOPUT_VSCREENINFO）。此外，邮箱控制器的 cDrv 以与清单 2 中所示类似的方式进行修补，以允许在 MyTEE 监督下访问屏蔽寄存器。为了防止 TOCTTOU 攻击，我们限制显示配置只能在邮箱控制器寄存器锁定后执行一次。在更新帧缓冲区之前，将根据 TA 的原始请求检查配置的有效性。一般来说，有两个接口用于操作帧缓冲区：write 和 mmap。 MyTEE 支持这两种机制来实现可信输出，如下所示。

mmap-based access

pDrv通常提供mmap机制来使用户应用程序能够直接访问帧缓冲区。为了支持 mmap 建立安全 IO，带有 MyTEE API 的特权块被放置在 pDrv 中 mmap 处理程序的末尾。当代理 CA 映射帧缓冲区以处理来自TA，已修补的 mmap 处理程序被触发。帧缓冲区的物理地址是作为一般 mmap 处理过程的一部分获得的。然后，特权块验证 mmap 的地址和大小，以防止任何 MyTEE 保护区域被恶意映射到 TA（例如，Boomerang 攻击 [44]）。此外，有效区域被屏蔽，其（物理）地址和大小被写入安全存储器。随后，TA验证控制器和帧缓冲区相关日志，并要求TEE操作系统参考安全内存中的信息直接将帧缓冲区映射到其地址空间。

pDrv 中的写入处理程序支持直接将数据写入帧缓冲区。在安全 IO 中启用此功能需要系统确保写入的数据不会被泄露或被不受信任的操作系统操纵。为此，TA首先将秘密数据放入安全存储器中，并要求CA使用虚拟数据调用写入系统调用。与基于 mmap 的方法类似，pDrv 的写入处理程序经过检测，使其需要屏蔽帧缓冲区并验证内存操作的特权代码块。然后，秘密数据从安全存储器复制到屏蔽帧缓冲区。请注意，由于更新帧缓冲区的任务被委托给检测设备驱动程序（与 mmap 支持不同），因此日志验证是在特权块中执行的。另请注意，可以类似地实现两种方法成功建立安全 IO 通道的指标，如第 VI-B2 节所示。

IMPLEMENTATION

MyTEE 的 PoC 是在配备 Broadcom BCM2837 SoC 的 Raspberry Pi 3 开发板上实现的。该SoC集成了四核ARM Cortex-A53处理器、DesignWare USB 2.0控制器[1]、具有16通道的DMA控制器和SPI控制器。具体来说，作为安全特性，仅支持CPU的安全状态；该 SoC 中缺少 TZPC、TZASC、TZMA 等 TrustZone 扩展。分别为 TEE 和 REE 软件平台部署了 OP-TEE 和 Linux（版本 4.14）。表 III 显示了安全 IO 的可信组件和设备驱动程序补丁（和 TA）的大小。请注意，内核中的 673 LoC 和监视器中的 821 LoC (ASM) 是为 TZ-RKP [27] 采用而添加的。

ARM Trusted Firmware

我们更新了 ARM 可信固件来创建 stage2 页表，用于将 TEE 和虚拟机管理程序与不受信任的操作系统隔离。具体来说，安全关键的内存区域包括表本身在内的对象（例如管理程序堆栈、安全缓冲区）不会映射到第 2 阶段转换层中。用于按需屏蔽控制器 MMIO 区域的第 2 阶段页表的运行时管理在监控模式下执行（即可信固件中的 BL31）。此外，关键内核操作（例如页表和系统寄存器的更新）的模拟也在监控模式下进行。

OS Kernel and Drivers

内核页表与管理程序共享（第 V-D 节）。因此，内核和管理程序支持的页表格式和虚拟地址范围应该是等效的。正如第 XI-B 节中所讨论的，当使用 64 位虚拟地址时，管理程序模式支持的虚拟地址范围小于内核模式支持的虚拟地址范围。相比之下，支持的地址范围与32位地址模式相同。此模式有两种类型的页表描述符格式可用：短描述符和长描述符[2]。但是，Hypervisor 模式仅支持长描述符格式。因此，我们将内核编译为具有大物理地址扩展选项（即.config文件中的CONFIG_ARM_LPAE）的32位二进制文​​件，以便内核也使用长描述符格式。

一旦内核文本、数据和管理程序加载到内存中，它们就会受到第 2 阶段分页的保护。屏蔽请求由 init 进程生成，该进程被用来调用 MyTEE。页表更新等关键操作通过 SMC 进行修补，以便由 MyTEE 进行验证和模拟。我们参考三星开源项目[13]，该项目提供了TZ-RKP实现的内核补丁，以在内核源代码中定位此类关键操作。表IV列出了在运行时在内核中动态重新配置的关键系统寄存器，从而导致配置的操作被模拟而不是简单地被删除。例如，TTBR0 在上下文切换时设置，SCTLR 配置为在用户模式的每个内核条目处激活内存对齐陷阱。

Hypervisor

微型虚拟机管理程序是在 ASM 中从头开始实现的。对于页表共享，我们将 hyp 转换表基址寄存器 (HTTBR) 配置为与包含内核页表地址的转换表基址寄存器 (TTBR1) 相同的值。此配置是在启动时进行的，并且设置 HTTBR 的指令无效，以确保它不被攻击者滥用。超级调用处理程序的实现是为了支持 MyTEE API，例如 mytee_priv_up。当调用超级调用时，内核的上下文存储在保存的程序状态寄存器（SPSR）中。一般来说，保存的上下文是通过使用返回内核时的eret指令。相反，我们使用 ret 指令返回内核而不剥夺特权，以便所选（包装的）设备驱动程序块以虚拟机管理程序特权运行。请注意，基于观察点的 DMA 寄存器保护未实现，因为 ARM 架构 [2] 不支持为 32 位管理程序配置观察点（即第 XI-B 节）。

OP-TEE

在我们的用例中，TA 实现需要支持一些操作系统级服务。例如，需要创建映射到管理程序区域中的安全内存的页表，以使TA能够访问安全缓冲区。为此，我们利用 OP-TEE API，而不是添加新的系统服务。相比之下，构建安全 IO 所需的外设特定逻辑（例如 TPM 命令生成和日志验证）是在 TA 中实现的。请注意，我们使用了支持 Raspberry Pi OS（即 Raspbian）的 OP-TEE [4] 的 GitHub 分支。不过，将MyTEE应用到OP-TEE正式版中并没有技术难度[6]。

SECURITY ANALYSIS

Race condition attack

MyTEE 将操作记录在特权块中，并允许 TA 稍后对其进行验证。但由于API可以被不可信操作系统任意调用，因此可以进行TOCTOU攻击，降低或消除日志验证的有效性。例如，不可信操作系统可以在 TA 验证 TPM 命令日志后立即尝试引导 TPM 用已知的哈希值覆盖 TA 请求的随机数。为了消除这种竞争条件，我们维护在任何事务完成时设置的事务标志，并在将新命令传递到 TPM 之前检查该标志（第 VI-A 节）。在可信显示示例中，可以通过让多个内核写入同一屏蔽帧缓冲区来进行类似的竞争条件攻击。然而，在特权块中，对帧缓冲区的写操作的源始终固定到只能由TA更新的安全缓冲区。因此，利用竞争条件对于不受信任的操作系统没有好处。

Abusing MyTEE APIs

特权升级原语可能被滥用来破坏 TEE 以及 MyTEE 本身的安全性。由于TEE没有映射到共享页表中，提权的恶意代码无法直接访问TEE。此外，页表被设置为只读，以防止对其进行操作。然而，攻击者可以尝试使用映射到 TEE 的恶意页表来更新页表基址寄存器（即 HTTBR、VTTBR）。因此，我们使在启动时配置虚拟机管理程序的系统寄存器的关键指令无效。此外，我们确保 mytee_priv_up API 在静态内核文本中执行，而不是在潜在恶意的动态加载模块（例如 LKM）中执行。特权内存操作也可能被滥用。为了防止这种情况，我们使用指示目标外设加入安全 IO 的上下文信息来验证内存操作。通过这样做，我们可以限制在控制器寄存器和安全缓冲区的预定义区域内执行的内存操作。

Exploiting vulnerabilities

特权代码块足够小，可以进行形式验证。即使攻击者通过利用特权块中的漏洞劫持控制流，TEE仍然是安全的，因为可执行区域中不存在配置HTTBR的关键指令。此外，通过利用基于观察点的内存保护来监控对 DMA 控制器寄存器的任何非法写入。与包含此类关键指令的动态加载的内核模块串通可能会为攻击者提供帮助。但是，仍然可以通过添加进一步的安全设施来进行权限升级来解决这个问题。例如，当权限升级时，我们可以删除对除静态内核文本之外的所有可执行区域的映射。我们将其留作未来的工作。

PERFORMANCE EVALUATION

由于用于内存隔离和过滤 DMA 数据包的第 2 阶段分页，采用 MyTEE 会给操作系统带来开销。我们通过运行 LMBench 和 CoreMark-PRO 测量了这一开销。此外，还测量了 DMA 和三个带有 TPM、USB 键盘和帧缓冲区的安全 IO 示例的性能。

LMBench

我们运行 LMBench 来测量操作系统的基本操作。图 8(a) 描述了 LMBench 中测试 10 次迭代的平均延迟。我们观察到写入和退出的最小开销分别为 2% 和最大开销为 23%。 execve 和 /bin/sh 也导致相对较高的开销，分别为 15% 和 11%。这些高开销的产生不仅是由于启用了 stage2 分页，而且还因为模拟了在监控模式下执行的关键操作。具体来说，exit、execve 和 /bin/sh 会生成更多页面错误来派生新进程，并且由于与其他测试相比执行时间相对较长，因此会产生更多上下文切换。因此，切换 CPU 模式和模拟关键操作需要更多的开销。

CoreMark-PRO

CoreMark-PRO 基准测试支持五个整数和四个浮点工作负载来测量处理器和内存子系统的性能。我们运行每个工作负载 10 次并评估平均延迟。如图 8(b) 所示，观察到的开销可以忽略不计。大多数测试的开销为 1% 到 2%。考虑到CoreMark-PRO测试的平均运行时间比LMBench长得多（大约22426×），据推测，当总体运行时间增加超过一定时间时，开销会有些模糊。

DMA Performance

通过测量配置 DMA 控制器的时间来评估 DMA 过滤带来的开销，该控制器由 MyTEE 捕获、验证和模拟。具体来说，我们创建了 CB，对 DMA 控制器进行编程，以在 TD 模式下执行内存到内存的数据传输。链接的 CB 数量和单个 CB 定义的传输数量均在 1 到 16 之间。图 9 显示了结果。该时间包括准备 CB（例如，分配不可缓存内存）以及控制器的 MMIO 的延迟。每个 CB 的传输次数对性能的影响可以忽略不计。相比之下，随着 CB 数量的增加，平均管理费用从 17% 下降到 8%。根据我们的分析，这是因为MyTEE验证（包括复制CB和验证预期的内存访问）的时间比创建CB的时间短；因此，随着链接CB数量的增加，开销逐渐减少。

Trusted Applications

1) Hardware TPM

我们评估了采用 MyTEE 给 TPM 带来的开销。在TPM操作中，我们专门测量了随机数生成和使用SHA256和SHA1算法进行散列的延迟。 TPM 生成的随机数大小范围为 2 字节到 32 字节。对于散列，输入大小范围为 64 到 1024 字节。每个 TPM 操作执行 10 次，平均延迟如图 10 所示。我们观察到性能下降了 3.68 倍生成 2 字节随机数。然而，随着输出大小的增加，性能略有提高。相比之下，在散列中观察到性能下降最多 2.71 倍。开销是由于设备驱动程序中的其他特权操作（例如记录 TPM 命令和保护 TPM 输出）而产生的。此外，CA和TA之间的通信延迟也包含在开销中。在随机数生成的情况下，观察到随着随机数大小的增加，开销略有减少的趋势。这是因为 MyTEE 施加的开销几乎是不变的，而 TPM 生成随机数所需的时间通常受随机数大小的影响。相比之下，由于在 TPM 的哈希操作中输入大小的影响可以忽略不计，因此无论输入大小如何，在哈希测试中都观察到几乎不变的开销。

2) Framebuffer

评估了帧缓冲区保护的开销。为此，我们比较了屏蔽和非屏蔽帧缓冲区的写入数据（大小范围为 1.6 MB 至 6.4 MB）的性能。数据从帧缓冲存储器的起始点线性写入。基于 mmap 和基于写入的方法都进行了评估。表 V 说明了每次测试 10 次运行的平均延迟以及由此产生的开销。我们观察到使用基于写入的方法写入 1.6 MB 数据时会产生 14% 的开销。然而，写入更大的数据可以提高性能：3.2 MB 和 6.4 MB 数据分别提高 32% 和 38%。使用基于 mmap 的方法，写入受保护的帧缓冲区在所有测试用例中都表现出色。具体来说，当使用 mmap 将 6.4 MB 数据写入帧缓冲区时，我们观察到性能提高了 47%。根据我们的分析，性能的提高是由于访问受保护的帧缓冲区的代码块的权限提升的设置所致。也就是说，因为在特权块中禁用了中断，所以可以原子地执行写操作。相比之下，在基线中，写入期间会发生多次上下文切换，并且切换所消耗的时间足够大，足以掩盖 MyTEE 的开销。

3) USB Keyboard

受保护的 USB 键盘的性能从两个方面进行评估：(1) 在内核中处理单个按键的开销，以及 (2) 生成安全按键输入的应用程序的性能。内核处理按键输入的一个周期由两个阶段组成：URB 通过 DMA 从键盘读取扫描代码并处理 DMA 完成时引发的中断。分别测量这两个阶段的性能，每个阶段 10 次运行的平均延迟如表 VI 所示。由于采用了 MyTEE，发送 URB 所需的时间大约是原来的 3 倍。特别是，处理第 2 阶段分页错误以访问 USB 控制器的屏蔽 MMIO 区域会产生开销。如第 VI-B2 节中所述，监视故障以跟踪当前分配的通道并将安全缓冲区配置为 DMA 目标。通过测量 hid_irq_in 函数的执行时间来评估中断处理的性能，该函数根据 URB 的状态字段定义了几个用于处理 URB 的分支。状态字段指示发送的 URB 是否已成功处理，或者是否遇到错误。我们只测量了处理成功的 URB 的时间，URB 的 urb->status 字段被清除，并观察到 ​​33% 的开销。如第 VI-B2 节所示，转换扫描代码并包装为特权代码块的新函数是开销的主要原因。

在应用程序基准测试中，虚拟生成了 125 到 1000 个之间的多个关键输入。我们在每个按键输入之间添加了 10 毫秒的延迟，并将相同数量的字符写入帧缓冲区。应用程序的开销在5%到9%之间。我们预计，在一般安全 IO 场景中，开销是合理的，因为输入大小更小（例如密码、OTP），并且与虚拟按键输入相比，人工输入速度更慢且变化更大，从而导致更多因素（例如中断） ）来掩盖开销。

RELATED WORK

Adoption of TrustZone

先前的研究提出了基于 TrustZone 的 TEE 中的安全设施，通过配置 TZASC 和 TZMA 来保护这些安全设施。 TrustShadow [33] 在 TEE 中托管一个轻量级代理，将未修改的应用程序与不受信任的操作系统隔离，同时仍然使它们能够与操作系统服务进行通信。 TZ-RKP [27] 和 Sprobes [32] 在 TEE 中实现了内核完整性监视器。 SeCReT [38] 和 Ginseng [59] 挂钩不受信任的操作系统服务并在 TEE 中验证它们，以分别对 CA 进行身份验证并保护应用程序机密。隐形恶意软件分析器 [47]、软件 TPM [49]、内存转储器 [53] 和移动设备管理 (MDM) 服务 [29] 也利用 TrustZone他们的孤立。一些研究动态地重新配置TZASC以实现灵活的隔离。也就是说，TZASC 在运行时按需设置，以在每个核心的基础上屏蔽应用程序 [28]，并在不受信任的操作系统 [30]、[54] 中构建额外的安全执行环境。 TZPC 还被用来隔离外设，供 TEE 专用。 Adattester [40] 将 TZPC 配置为将键盘和显示器与不受信任的操作系统隔离，从而防止广告欺诈。类似地，TrustOTP [52] 通过隔离此类 IO 外设，提出了基于 TEE 的一次性密码（OTP）。以前的研究基本上是基于这样的假设进行的：TrustZone 及其扩展已正确部署并且可供任何需要使用它们的人使用。相比之下，MyTEE 试图确保 TEE 的安全性和通用性，即使该假设未得到满足。还可以重新审视 TrustZone 虚拟化 [34]、[39] 和创建新的隔离执行环境 [36] 的方法，以在不利用 TrustZone 硬件扩展的情况下创建 TEE。然而，MyTEE 仍然优于此类方法，因为它可以实现安全 IO，而不会使 TEE 拥挤，并且不限于模拟缺失的功能。

Secure IO

为了构建安全的 IO 通道，之前的工作已经提出了保护作为外设接口的设备驱动程序的方法。 Wimpy Kernel [62] 剥夺了 USB 设备驱动程序的关键部分的权限，并将其作为受屏蔽的用户进程进行保护。 Trusted Display [58] 添加并屏蔽了一个内核组件，用于调解和模拟对 GPU 的安全关键访问。这些工作需要对设备驱动程序进行彻底分析，以分离设备驱动程序的安全关键逻辑。此外，预计将安全管理程序框架[45]、[55]移植到嵌入式设备的工程工作。相比之下，MyTEE提供的API可以植入现有的设备驱动中，而不是对设备驱动进行分区和屏蔽。此外，采用事实上的标准公共 TEE 平台（例如 OP-TEE [6]）通过将屏蔽用户进程的任务委托给 TEE 来最大限度地降低虚拟机管理程序实现的复杂性。 BitVisor [51] 将设备驱动程序的关键部分迁移到虚拟机管理程序层，这也需要大量的分析和工程工作，并扩大了可信计算基础（TCB）。 Tabellion [46] 提供了在设备驱动程序中调用的管理程序和 TEE API，以保护 IO 缓冲区。我们提出了一种更灵活的方法，即需要以更高权限执行的外设特定逻辑（例如，访问 URB 中的 IO 缓冲区）可以集成为设备驱动程序的一部分，而不是迁移到特权软件。 AdAtester [40] 和 TrustOTP [52] 在 TEE 中维护单独的设备驱动程序，可能会扩大 TEE 的攻击面。此外，假设存在 TrustZone 扩展，但根据 SoC 设计的不同，这并不总是正确的。

DISCUSSION AND FUTURE WORK

Usability and Security

采用MyTEE构建安全IO通道需要对设备驱动进行深入分析，确定MyTEE API植入的合适位置。然而，除了根据驱动程序实现的复杂性需要进行大量工作的分析之外，装备使用 MyTEE API 的驱动程序，如清单 2 中所述。这种方法的一个问题是升级内存操作的权限，这可能会扩大攻击面。为了解决这个问题，我们验证在特权块中执行的内存复制操作的参数。此外，由于在我们的一般使用模型中只有简单的内存复制 API（例如 writel）会受到有限的权限升级，因此我们可以轻松地针对包括 API 在内的检测（特权）代码块执行形式验证。开发人员可能会滥用 MyTEE API，从而造成新的安全漏洞。例如，缺少日志记录可能会破坏安全 IO 的可靠性。在编译时检查特权块实现的正确性可能是一个合理的解决方案，但我们将其留到将来的工作中。

64-bit OS Support

尽管 ARMv8 支持 32 位和 64 位虚拟地址，但操作系统和 MyTEE 虚拟机管理程序在我们的 PoC 中编译为 32 位二进制文​​件。其目的是在我们的开发环境（即 Raspberry Pi 3）（配备 Cortex-A53 处理器）中实现内核和虚拟机管理程序之间的页表共享。特别是，该处理器实现了 ARMv8.0 规范，支持内核和管理程序模式的不同虚拟地址范围。内核模式支持两个虚拟地址子范围：底部范围 0x0 到 0x0000_FFFF_FFFF_FFFF 和顶部范围 0xFFFF_0000_0000_0000 到 0xFFFF_FFFF_FFFF_FFFF。 64位Linux通过为每个空间维护不同的页表来将用户空间和内核空间映射到底部和顶部范围。相比之下，64 位管理程序模式仅支持 ARMv8.0 上的底部范围。因此，即使管理程序使用内核页表，它也无法映射与 Linux 中虚拟地址的顶部范围映射的提权设备驱动程序。

因此，我们为内核和虚拟机管理程序使用32位虚拟地址，它可以用单个页表来呈现整个虚拟地址空间。唯一的要求是能够使用 LPAE 选项编译内核，如第 VII-B 节所示。不幸的是，回退到 32 位会禁用基于观察点的 DMA 保护，防止虚拟机管理程序特权攻击。因此，在这种情况下，MyTEE的安全性取决于特权块是否包含漏洞，因此需要对其进行彻底验证。不过，从 ARMv8.1 开始可以取消此限制。虚拟化主机扩展 (VHE) 也支持在管理程序模式下使用两个虚拟地址子范围。我们将在未来的工作中探索在 MyTEE 中采用此功能。

CONCLUSION

在本文中，我们提出了 MyTEE，用于在嵌入式设备上构建和增强 TEE，而不依赖于先前工作中假设普遍可用的 TrustZone 硬件扩展。为此，提出了内核剥夺和仔细的内存管理、DMA 数据包过滤和临时特权升级技术。此外，MyTEE 及其安全 IO 示例用例是在 Raspberry Pi 3 开发板上实现的，该开发板缺乏用于构建 TEE 的强制性 TrustZone 扩展。 MyTEE 位于：https://github.com/sssecret2019/mytee。