RISC-V“安全”那些事儿

背景

SpacemiT

在数字化浪潮汹涌澎湃的当下，计算机已深度融入人们生活的各个方面，成为社会运转不可或缺的 “中枢神经”。

从清晨唤醒我们的智能设备，到工作中处理的海量数据，再到夜晚休闲时畅享的娱乐内容，计算机的身影无处不在, 它串联起生活的方方面面，已然成为信息交互、数据存储与处理的核心载体。

然而，计算机技术迅猛发展的同时，安全问题也如影随形。

网络空间并非一片净土，恶意软件如同隐匿在黑暗中的幽灵，随时可能入侵计算机，窃取保密信息；黑客们则像狡黠的盗贼，利用系统漏洞，肆意破坏、非法获取数据。这些安全威胁，严重扰乱了我们的数字生活秩序。

“The more connected we get, the more vulnerable we become.”（我们的联系越紧密，就越容易受到攻击）。

软件攻击

SpacemiT

如今，许多底层软件（如操作系统）都是用 C 或 C++ 等非内存安全的编程语言编写的，这使得这类软件容易受到软件的攻击，攻击者往往会利用这些漏洞来达到非法的目的，诸如系统提权、隐私窃取等。先简单介绍一下软件常用的几种攻击手段:

Buffer Overflow

ret2libc/ret2text

Return Oriented Programming / Jump Oriented Programming

Buffer Overflow 攻击

对于底层操作系统而言， buffer overflow和memory corruption是漏洞的主要来源，因为操作系统主要是通过C/C++来实现的， 而C/C++并非内存安全的编程语言。

图片来自：https://www.cvedetails.com/vulnerabilities-by-types.php

Buffer Overflow（缓冲区溢出）是一种常见且危害严重的计算机安全漏洞的利用方式。在程序运行过程中，当向缓冲区写入的数据量超过其预先分配的容量时，就会发生缓冲区溢出。

当函数返回地址被覆盖时，攻击者可以将其修改为恶意代码（shellcode）的地址或者程序中其他关键函数的地址, 这使得攻击者能够以与被攻击程序相同的权限执行恶意操作，可能导致系统敏感信息泄露、系统被完全控制等严重后果。

为了防范 Buffer Overflow 攻击，现代操作系统和编译器采用了多种技术。如引入了栈金丝雀（Stack Canary）机制，在函数返回地址和局部变量之间放置一个特定值（canary 值），在函数返回前验证该值是否被修改，若被修改则说明可能发生了缓冲区溢出攻击，程序会立即终止运行，从而防止攻击者进一步篡改返回地址。

同时，非可执行（NX）内存技术，也称为 W⊕X（Write XOR eXecute）或数据执行预防（DEP），为每个内存页面分配一个 NX 位，标记其为可读可执行或不可执行但可写，防止攻击者在数据区域（如栈）上执行恶意代码，有效抵御了传统基于栈的代码注入攻击。

ret2libc/ret2text 攻击

在存在缓冲区溢出漏洞的情况下，当 Data Execution Prevention (DEP) 等机制禁止在数据区（如栈）执行代码时，ret2libc 攻击应运而生。

由于攻击者无法直接执行放置在栈上的 shellcode，于是转向利用程序中已有的库函数来达到恶意目的。

ret2text 攻击则是在程序未开启 Position-independent Code (PIE) 时，利用程序自身代码段中固定的地址来执行恶意操作。

在未开启 PIE 的情况下，程序自身某些关键代码段的地址在每次运行时是固定的，攻击者通过溢出漏洞覆盖函数返回地址，使其跳转到程序自身代码段中可利用的指令序列处。

这些攻击技术的出现促使安全研究人员不断研发新的防御策略，如强化内存保护机制、增强程序的地址随机化（ASLR）程度等，以应对不断变化的安全威胁，保障计算机系统的安全稳定运行。

然而，攻击者也在不断发展新的攻击手段来绕过这些防御机制，如代码重用攻击（CRAs）中的 Return Oriented Programming（ROP）等技术，使得计算机安全防御面临持续的挑战。

ROP/JOP 攻击

ROP（Return-Oriented Programming，返回导向编程）和 JOP（Jump-Oriented Programming，跳转导向编程）是两种先进且具有强大危害性的代码重用攻击技术。

ROP 攻击基于程序中已有的代码片段（gadgets）来构建攻击链。这些 gadgets 通常是位于程序的.text 段等可执行区域内，以 ret 指令结尾的短指令序列。在存在缓冲区溢出等漏洞的情况下，攻击者通过精心构造输入数据，将一系列 gadget 地址和对应的参数填充到栈上。

Example of ROP attack

ROP 攻击的优势在于能够绕过诸如 DEP（Data Execution Prevention）等内存保护机制，因为它利用的是程序自身合法的代码片段，而不是注入新的可执行代码。JOP 攻击与 ROP 类似，但它的 gadgets 是以间接分支（如 jmp 或 call 等）指令结尾，而不是 ret 指令。

JOP 攻击构建在一个 dispatch table（调度表）之上，该表存储着各种 gadgets 的地址和相关数据。攻击者通过控制程序的执行流程，使 CPU 寄存器（通常是一个用作虚拟程序计数器的寄存器）指向 dispatch table 中的不同 gadgets 地址，从而实现连续的 gadget 调用。

ROP 和 JOP 攻击的出现，促使安全研究人员不断探索新的防御技术，如更严格的控制流完整性检查、硬件辅助的安全机制等，以应对这些复杂的攻击手段，保护计算机系统的安全。

RISC-V Control Flow Integrity (CFI)

基于代码重用攻击(CRAs)不需要在受攻击的程序中引入新代码, CRAs基于通过覆盖函数指针和返回地址来转移应用程序的控制流。RISC-V 提供了影子栈(Shadow Stack, Zicfiss)和Landing Pads(Zicfilp) ISA 扩展（统称CFI扩展），通过该扩展来保护程序的控制流完整性。

具体来说，为了保护后向边缘（backward-edges），RISC-V定义一个影子堆栈来存储每个特权级别的返回地址, 主要用来防护ROP攻击；为了保护前向边缘（forward-edges), RISC-V设计了一种基于标签的指令着陆方法(Landing Pads)，主要用来防御JOP攻击。

影子栈Zicfiss 扩展引入了影子栈来强制执行后向边缘控制流的完整性。影子堆栈是第二个堆栈，用于将返回地址的影子副本存储在链接寄存器（RA）中。

当启用 Zicfiss 后，每个需要返回地址完整性的函数（通常是非叶子函数）在进入函数（序言）时将链接寄存器值存储到常规堆栈，并将链接寄存器值的影子副本存储到影子堆栈。当此类函数返回（结尾）时，该函数从普通堆栈加载RA，从影子堆栈加载RA的影子副本，然后比较常规堆栈中的RA值和影子堆栈中的RA值。两个值不匹配表示return address被破坏，并触发软件异常。

Ladding pads旨在为使用间接调用和跳转执行的控制执行提供完整性（前向边缘保护）。当 Zicfilp 处于活动状态时，hart 会跟踪预期Ladding pads 的状态（ELP），该状态由 indirect_call 或 indirect_jump 更新，要求是否在分支目标处存在ladding pads指令。如果目标处的指令不是ladding pad指令，则会引发软件异常。

function_entry: lpad # loading pad check addi sp,sp,-8 # push link register x1 sd x1,(sp) # on regular stack sspush x1 # push link register x1 on shadow stack : ld x1,(sp) # pop link register x1 from regular stack addi sp,sp,8 sspopchk x1 # fault if x1 not equal to shadow return address ret

RISC-V CFI （Shadow Stack and Ladding Pads）Example

Trusted Execution

Environment (TEE)

SpacemiT

对于各类软件攻击，硬件以及操作系统提供了多种缓解和防御手段， 但是由于软件问题导致的软件漏洞数量每年仍然呈上升趋势。

图片来自：https://www.cvedetails.com/

尽管软硬件安全工程师付出很多的努力去修复漏洞，但是绝大多数底层基础软件都是用内存不安全的语言（如 C 和 C++）编写的，这很容易引入内存漏洞，从而使软件遭受代码重用攻击（CRAs），像缓冲区溢出、Return-Oriented Programming（ROP）和 Jump-Oriented Programming（JOP）等攻击手段频繁出现。

传统的安全机制在应对这些复杂攻击时往往存在局限性，难以全面保障系统的安全，这也导致计算机操作系统每年呈现的缺陷和漏洞每年都在呈上升趋势。

新的攻击手段层出不穷，黑客们不断寻找着系统的薄弱环节，试图突破安全防线，获取非法利益或达成恶意目的。这就如同一场永不停歇的攻防博弈，正应了那句 “道高一尺，魔高一丈”。

与其像一个补锅匠一样拆东墙补西墙，有没有一种更加彻底的方法来杜绝绝大部分的软件攻击呢？

比如，把应用程序放到一个与主系统隔离的环境里，主系统的软件（包括特权软件）、DMA外设都无法获取该环境里软件的执行状态、数据，从而就算再厉害的黑客也无法通过普通的软件手段来获取内部信息。

这是一个非常朴实的想法，而且早就有人这么做了，这便是TEE（Trusted Execution Enviromnent）技术。

The approaches of IoT TEE

Intel 的SGX

(Software Guard Extenstion)

Intel Software Guard Extensions（Intel SGX）是英特尔推出的一项基于硬件的可信执行环境（TEE）技术，旨在为应用程序提供更高级别的安全性，尤其是保护应用程序代码和数据的机密性与完整性。

这个隔离的区域， Intel 称之为Enclave, 它是应用程序地址空间内一个受保护的区域，由 CPU 提供硬件层面的安全隔离。Encalve中的代码和数据在内存中加密存储，只有Enclave内的代码才能够访问，即使操作系统内核、虚拟机监视器或其他特权软件也无法窥探或篡改Enclave的内容。

Intel SGX Enclave示意图

TEE（Tusted Execution Environment）可信执行环境能够为敏感数据和关键应用程序提供一个隔离且受保护的运行空间。它确保在这个环境中执行的代码和处理的数据不会被外部恶意软件或未经授权的实体所干扰或窃取。在物联网领域，众多设备收集和传输大量敏感数据，如医疗设备中的患者健康数据、工业控制系统中的关键生产数据等，TEE 可以为这些设备提供安全的执行环境，确保数据在设备端的处理过程中的安全性，防止数据泄露和恶意控制；在云计算环境中，不同用户的应用程序和数据在共享的硬件资源上运行，TEE 能够隔离用户的工作负载，保证每个用户的隐私和数据安全，防止云服务提供商或其他租户的非法访问。

Trusted Execution Environment: What It is, and What It is Not [2] 这篇论文对 TEE做了详细定义：可信执行环境 (TEE) 是在分离内核上运行的防篡改处理环境。它保证执行代码的真实性、运行时状态（例如 CPU 寄存器、内存和敏感 I/O）的完整性以及存储在持久内存中的代码、数据和运行时状态的机密性。此外，它还应能够提供远程认证，以证明其对第三方的可信度。TEE 的内容不是静态的，它可以安全地更新。TEE 技术主要用于抵御软件攻击以及部分非侵入式物理攻击。

An Overview of TEE Building Blocks

TEE主要包含以下几个方面：

安全启动

在启动时，TEE 安全启动从信任根开始，信任根是预先内置在硬件中的高度可信组件，如可信平台模块（TPM）中的密钥或固化在芯片中的根证书。启动过程是一个链式验证过程，从引导加载程序开始，每加载一个软件组件，都会依据前一个已验证的组件来验证其完整性和真实性。例如，引导加载程序会验证内核的数字签名，确保内核未被篡改，内核加载后又会验证系统服务和驱动程序等的合法性。这种链式验证确保了整个启动链条的可信性，只有经过授权和未被篡改的软件才能在 TEE 中加载和执行。

在启动阶段阻止恶意软件的加载和执行，避免系统在启动过程中就被恶意软件入侵，从而保护系统的安全性和稳定性。

保障数据安全：确保 TEE 在启动时加载的是可信的数据处理和存储模块，防止敏感数据在系统启动阶段就面临被窃取或篡改的风险。

支持远程证明：安全启动过程中对软件组件的验证信息可用于远程证明，向远程服务器或其他设备证明本地 TEE 的可信状态，使得远程实体可以放心与本地设备进行交互。

安全启动需要依赖硬件信任根(HW RoT), 主要包含ROM、eFuse以及HW Crypto Engine。ROM用来运行启动代码，因为ROM不可修改，所以ROM的功能是固化的；eFuse主要用来存储密钥（HUK等）以及软硬件相关的配置，安全eFuse需要做到敏感数据特别是密钥信息不允许被导出；密码学引擎（Crypto Engine）需要提供密钥管理、密钥存储、密钥派生等功能，需要确保密钥信息不能被CPU所获取。基于HW RoT的密码学使用方法大致如下图所示：

The Usage of HW RoT during Secure Boot

安全调度

安全调度确保TEE与系统其余部分之间的“平衡”和“高效”的协同运作。实际上，它需要确保在TEE中运行的任务不会影响主操作系统的正常响应。如OP-TEE提出了一种安全调度策略，它把OP-TEE的线程设计为主操作系统线程的“延伸”，OP-TEE不再需要提供调度器而完全依赖主操作系统的调度，它可以减少对主操作系统调度的影响。

环境间通信

环境间通信定义了允许TEE 与系统其余部分通信的接口。通信接口应满足三个关键属性：可靠性（内存/时间隔离）、最小开销（不必要的数据复制和上下文切换）和通信结构的保护。较为常见的通信接口模型如：GlobalPlatform TEE Client API。

安全存储

安全存储是指保证存储数据的机密性、完整性和新鲜度（即防止重放攻击）的存储，并且只有授权实体才能访问数据 。实现安全存储的一种常见方法是加密(sealed)存储。加密存储基于三个组件：

仅可由 TEE 访问的完整性保护密钥；

加密机制，例如经过身份验证的加密算法；

数据回滚保护机制，例如重放保护内存块 (RPMB)。

可信 I/O

可信I/O确保TEE 与外围设备（例如键盘或指纹）之间通信的真实性和机密性，因此，输入和输出数据不会被恶意应用程序嗅探或篡改。更准确地说，可信 I/O 需要防范以下四类攻击：屏幕捕获攻击、键盘记录攻击、覆盖攻击和网络钓鱼攻击。Trust UI的可信路径可在 TEE 内实现更广泛的功能，它允许用户直接与 TEE 内运行的应用程序交互。

前面介绍了TEE的通用模型，接下来我们来简单了解一下Arm基于TrustZone实现的TEE架构。为什么要先了解Arm TrustZone的实现原理，是因为RISC-V在嵌入式上的安全架构与Arm有很多相似之处，TrustZone作为嵌入式安全的先行者，已经有比较好的群众基础，通过了解TrustZone能让用户更好地理解RISC-V的安全机制。

TrustZone-based TEE

Arm TrustZone 技术可以看作是一种特殊的虚拟化，具有对内存、I/O 和中断虚拟化的硬件支持 。这种虚拟化使 Arm 内核能够提供两个虚拟内核 (VCPU) 的抽象：安全 VCPU 和非安全 VCPU。

Secure monitor被视为一个最小的虚拟机管理程序，其主要作用是控制两个虚拟内核之间的上下文管理和调度。我们可以从操作系统管理应用程序（进程）的视角来看TrustZone的轻量级虚拟化。从操作系统视角，每个应用程序都完全独占他的用户空间，不同的应用程序之间相互独立，即使在单个物理核的情况下，应用程序在操作系统的管理下能够“并发”运行（单核的情况下，并不是真正意义上的同时运行)。

TrustZone 的物理世界虚拟化的本质也是一样，我们把"虚拟世界“看成应用程序的用户空间，secure monitor看成是操作系统内核， 虚拟世界(安全世界和非安全世界)在secure monitor的管理下”并行“运行。在单核情况下，这并不是真正意义上的并发运行，而是一种对CPU物理资源的分时复用。

当然，因为是一个物理核，也就是硬件资源是多个vcpu（其实就2个，安全和非全vcpu）共享的，那么在世界切换的时候，除了做一些额外的上下文切换的工作以外，比如cpu上下文（通用寄存器、系统寄存器等）切换，还需要做一些清理的工作，主要是清理cache和TLB，这会带来一定的性能损耗，所以TrustZone在cachline和tlb的entry上额外增加了NS bit（这个下面会详细介绍）来标注cacheline和tlb的安全属性，不同属性之前的cacheline和tlb entry不会相互打架，相当于内部做了一层隔离。

于是， trustzone enxtension的软件整体架构如下：

Armv8 Software Architecture with TrustZone Extension

虽然1个物理核被虚拟出了2个vcpu（可以理解为相比2个物理核，TrustZone虚拟化技术节省了物理核资源)， 但是不同vcpu访问资源是如何做到对资源访问(比如ddr)的保护的？

首先，TrustZone 技术在AMBA总线上扩展了 NS（Non-Secure，非安全）位，它作为一个标识位，用于在总线事务中标明该事务是属于安全域还是非安全域，这也是TrustZone技术的核心思想（将资源划分成安全世界和非安全世界)。

在整个系统中，NS bit 就是一个 “安全标签”，当总线上的事务携带 NS bit 信息时，系统的各个组件（如总线仲裁器、内存filter、从设备等）可以根据这个位来判断是否允许该事务的进行，从而实现了安全与非安全区域的隔离和数据访问控制。

接下来就要说TrustZone的TZASC(Trustzone Address Space Controller) IP了，也就是上面说的内存filter。TZASC是 ARM TrustZone 技术的关键组件，主要用于管理和保护系统（包括CPU和DMA设备）对内存的访问：

TZASC 通过检测总线事务的安全状态位来确定当前的传输事务是安全事务还是非安全事务。当处理器处于安全状态时，会发出安全访问事务（NS=0），允许访问安全世界的内存区域；处于非安全状态时，则会发出非安全访问事务(NS=1), 只允许访问非安全区域，限制对安全世界内存的访问。

内存属性配置：系统开发者可以通过配置 TZASC 的配置寄存器，为不同的内存区域设置安全属性，包括安全 / 非安全属性、可读写权限等。这些配置信息被 TZASC 用于在内存访问时进行实时检查和控制。

TZASC IP是用来保护DDR内存的，也就是所有的master设备（包括CPU和DMA设备）对内存的访问都会经过TZASC的保护，那除了DDR以外的地址空间呢？

TrustZone系统中，DDR以外的地址空间都需要额外的安全IP来进行访问控制，主要包括ROM、SRAM和外设的MMIO。TrustZone提供了TZMA（TrustZone Memory Adaptor）IP对ROM或SRAM进行访问控制（可以简单理解TZMA是个轻量级的TZASC), 同时TrustZone也提供了AXI2APB桥 以及TZPC (TrustZone Protection Controller) IP对MMIO的访问进行权限管控。

以上便是实现TrustZone方案需要提供的几个核心的安全IP。当然，除了上述公共的安全IP以外，SoC在设计外设时然需要考量基于NS bit的访问控制，比如对于DMA设备，需要考虑该DMA设备是安全设备还是非安全设备，带来的影响就是该DMA设备在发出读写访问时需要携带NS信号以表明当前访问时安全访问（NS=0）还是非安全访问（NS=1），这需要在SoC设计时就静态绑定。

当然Arm也提供了一种更加灵活通用的方式来绑定DMA设备的安全属性，那就是在DMA设备后面再挂一个SMMU， 因为SMMU可以通过软件编程页表的方式动态地修改DMA的访问属性。这种方式的优点是DMA设备集成时不需要额外的改动，并且灵活性高；缺点就是需要集成SMMU，会增加额外的硅面积。

以上便是Arm TrustZone的核心内容，总结一下就是， TrustZone将资源划分成安全世界和非安全世界，并通过NS bit来标注资源的安全属性，最后通过slave侧(划重点, 关注和后面的RISC-V做对比)的安全IP（如TZASC, TZMA, AXI2APB bridge等）基于NS属性对地址空间的访问进行访问控制。当然，有些事务很可能是不会到达slave侧的安全IP的（如cpu cache hit的情况），这就需要事务的发起者(如 cpu)需要在内部实现访问的隔离，比如在cache中增加NS属性。

接下来我们来看一下RISC-V的安全架构。

RISC-V PMP/ePMP based TEE

RISC-V在特权架构上和Arm v8/9架构有非常相似之处， RISC-V特权级架构如下：

用户态（U 态）：运行一般的用户应用程序，具有最低的特权级别，只能访问有限的指令和资源，对硬件的直接访问受到严格限制，以防止用户程序对系统造成破坏。

内核态（S 态和 H 态）：S 态用于操作系统的内核或监督程序。H 态则用于 Hypervisor，负责虚拟机的运行和管理。

机器模式（M 态）：具有最高的特权级别，可执行M态特权级指令，运行特权级固件(如OpenSBI), 提供特权级服务，类似Arm v8/v9的EL3或者Root 态。

前面我们已经了解了TrustZone的实现原理，TrustZone Extension在特权架构上增加了EL3，用于运行特权固件(如TF-A), 而RISC-V 在诞生之初就拥有比S/H态更高的特权级模式M态，所以RISC-V 也完全可以像TrustZone一样实现物理核(Hart)的虚拟化。

不同的是，TrustZone只能虚拟出2个世界，而RISC-V则没有这方面的限制，RISC-V可以在特权固件（OpenSBI）的管理下，能更像创建进程一样创建出任意多的虚拟”世界“（数量依赖与系统资源）。

每一个”世界“RISC-V通常称之为Domain， vCPU(这里借用CPU虚拟化中的虚拟CPU的概念，本质上是一样的)是物理CPU在每个Domain中运行时的抽象，本质上是一个物理CPU在不同Domain之间分时运行，而安全固件（增加了Domain管理功能的特权固件）则提供了Domain之间的上下文管理和切换。

我们仍然可以按照理解操作系统管理应用程序或者Hypervisor管理虚拟机的方式来理解安全固件对Domain的管理，于是RSIC-V可以实现如下的软件整体架构：

RISC-V Generic Software Architecture with TEE Enabled

上图展示RISC-V"虚拟"出多个Domain来实现TEE架构的软件参考模型，但最关键的是RISC-V如何解决不同Domain之间的隔离问题。所谓隔离，从技术上看就是如何实现权限管理和访问控制。我们仍然通过用户态和内核态的隔离来举例，因为用户态和内核态的隔离大家都比较熟悉，而且不同CPU架构之间都大同小异。

用户态和内核态的隔离是通过内存管理单元(MMU)来实现的。MMU 的主要功能是将虚拟地址转换为物理地址，并对访问进行权限检查。在操作系统中，用户态和内核态运行在不同的虚拟地址空间，操作系统内核可以通过管理MMU 页表来控制不同特权下对物理内存的访问权限，从而实现两者的隔离。

用户态页表：用户态程序使用的页表只包含用户程序可以访问的物理内存区域的映射。这些区域通常是用户程序的代码、数据和栈等。用户态页表中的映射项会设置相应的访问权限，一般只允许用户态程序进行读、写和执行操作，并且不允许访问内核空间的物理内存。

内核态页表：内核态使用的页表包含了整个系统的物理内存映射，不仅包括用户程序的内存区域，还包括内核代码、内核数据结构和设备内存等。内核态页表中的映射项权限设置更为灵活，内核可以根据需要进行各种操作，如对硬件设备的直接访问等。

每个应用程序都有自己独立的页表，每个页表包含了应用程序完整的用户空间。当操作系统从一个应用程序切换到另一个应用程序时，操作系统主要做的其中一个事儿就是进行页表切换。

应用程序地址空间是通过MMU来管理的，那RSIC-V domain的地址空间是通过什么来管理的呢？这就是RISC-V架构特有的物理内存保护（PMP）模块。

RISC-V PMP (Physical Memory Protection）

RISC-V 物理内存保护（Physical Memory Protection，PMP）是 RISC-V 特权架构的重要组成部分，在硬件层面提供灵活且细粒度的内存访问控制。它允许操作系统或监督程序依据实际需求，对不同物理内存区域设置各异的访问权限，以此防止低特权级(U, H/S)程序进行非法的内存访问操作，增强系统安全性和稳定性。简单地讲， PMP是一个轻量级的MPU， 它基于实地址(MMU是虚地址)模式对低特权等级的程序提供地址空间访问的权限管理， 而M模式并不受PMP的影响（除非把PMP的表项锁住，具体细节不展开介绍）。

PMP只允许M模式下的特权固件对它进行编程（MMU是受S态的Kernel管理），M态固件可以像操作系统内核维护MMU页表一样来维护PMP的表项，从而实现不同Domain之间访问权限的切换(类似MMU页表切换)。基于PMP实现多个Domain访问隔离的机制如下图所示：

RISC-V Memory Isolations Using PMP Swapping

RISC-V SUM (Supervisor User Memory)

在早期的操作系统内存管理机制中，用户空间和内核空间虽然在概念上有所区分，但在实际的内存使用和访问控制方面存在一定的漏洞。用户程序可以在用户空间分配内存，并且这些内存可以被标记为可执行。

攻击者利用这一特性，通过精心构造的攻击代码，将恶意代码注入到用户空间的可执行内存中。当系统因某些操作进入内核模式后，攻击者可以诱导内核跳转到这些恶意代码所在的用户空间内存区域并执行，从而实现提权攻击，获取系统的最高权限，进而控制整个系统。这种攻击方式严重威胁到系统的安全性和稳定性。

同时，仅仅禁止内核模式下执行用户空间代码已经不足以保障系统的安全。在一些情况下，即使内核不执行用户空间的代码，但如果可以随意访问用户空间的内存，仍然可能被攻击者利用。例如，攻击者可以通过操纵用户空间的内存数据，诱导内核在访问这些数据时执行不安全的操作，从而绕过其他安全机制。

为了抵御这种类型的攻击，SMEP（Supervisor Mode Execution Protection）和 SMAP（Supervisor Mode Access Prevention）机制应运而生。SMEP 的核心思想是在内核模式下禁止执行用户空间的代码。当内核尝试执行位于用户空间的指令时，SMEP 会触发异常，阻止恶意代码的执行，从而大大增强了系统对提权攻击的抵抗能力；SMAP 进一步限制了内核模式下对用户空间内存的访问，当内核尝试在没有明确授权的情况下访问用户空间的内存时，SMAP 会触发异常，阻止这种不安全的访问操作，从而进一步增强了系统的安全性。

RISC-V SUM（Supervisor User Memory） bit 是 RISC-V 架构中用于增强内存访问控制安全性的一种机制，内核态程序对用户态内存的访问会受到严格限制。当SUM=0时，内核态只能访问自身的内存区域，而无法直接访问用户态的内存。这就确保了用户态内存数据的隔离性和安全性，防止内核态代码意外或恶意地访问用户态数据，即使内核态具有较高的特权级别， 从而为系统提供SMAP保护能力。

RISC-V ePMP (Enhanced Physical Memory Protection)

前面说到PMP主要作用于U、S/H等特权级，而M态是不受PMP约束的（Lock模式这种特殊场景我们暂且不讨论），过高的权限往往会带来安全上隐患。RISC-V ePMP (Enhanced Physical Memory Protection)增强型物理内存保护是对传统 RISC-V PMP（Physical Memory Protection，物理内存保护）机制的扩展和增强，旨在提供更强大、更灵活的内存访问控制, 提供对M模式SMEP和SMAP的保护能力。

RISC-V ePMP SMEP/SMAP Protection

RISC-V I/O Physical Memory Protection

上一章节介绍了RISC-V基于PMP/ePMP的物理地址空间访问的保护机制， 但PMP/ePMP是RISC-V特权架构的一部分，是用来约束CPU对物理内存、MMIO的访问权限的，但RISC-V又是如何对DMA master设备进行访问控制的呢？这就要说到RISC-V IOPMP（Input/Output Physical Memory Protection)这个RISC-V Non-ISA 扩展了。

IOPMP 和PMP/ePMPl类似，本质上是一种物理内存保护机制，只不过它聚焦于 DMA设备的访问控制。相比与PMP，IOPMP的实现会更加复杂，因为它需要考量同时来自不同设备的访问请求，同时也还要做到低时延。IOPMP也提供了类似PMP的访问权限配置表，能够允许安全固件配置针对不同设备对物理地址空间的访问设置特定的访问权限，确保I/O设备只允许访问授权的物理地址空间。

RISC-V IOPMP Reference Model

IOPMP也不仅仅用来保护DMA外设的物理地址空间访问，它也可以作用于CPU。这种情况下， IOPMP往往会部署在slave侧，但由于RISC-V系统里的RV CPU已经有PMP/ePMP保护了, 所以一般会将IOPMP对RV CPU的访问配置成直通方式(Bypass)。部署在slave侧的IOPMP就和Arm上的TZASC IP非常相似了，差别在于TZASC是基于NS信号来进行访问控制，而IOPMP是基于Source ID (或者叫Reqester ID), 也就是TZASC是把设备分成Group（安全和非安全）， 而IOPMP则可以为每个设备单独配置权限，提供了更加细粒度的权限管控。

以上便是RISC-V 架构实现可惜执行环境所提供的核心组件。我们再简单对比一下RISC-V 安全架构和Arm TrustZone的差别。

TrustZone的核心思想是将资源划分成安全"世界"和非安全”世界“，并通过NS位进行标记，资源的访问控制主要集中在slave侧的安全IP，只能采用slave端防护策略，不同的slave（如内存控制器、ROM/SRAM控制器、MMIO等）采用不同的安全IP（TZASC、TZMA、TZPC、AXI2APB Bridge等）， 安全IP基于NS信号进行权限管控。

而RISC-V在架构上并没有2个”世界“的限制，理论上可以虚拟出任意数目的Domain， Domain隔离所提供的安全IP（也就是PMP和IOPMP）都是基于地址空间的权限管控（TrustZone是基于NS信号），管控策略更加灵活。

其中PMP采用master端(核内)防护策略，而IOPMP既可采用master端防护策略也可以采用slave端防护策略，甚至采用混合方式的防护策略，IOPMP部署方式可以灵活多样，并且不需要像TrustZone那样，不同的slave设备采用不同的安全IP，RISC-V完全可以采用同一个IOPMP IP（但允许不同的配置，比如entry表项的数目）。但总的来说，RISC-V和Arm在实现TEE隔离机制上是殊途同归。

进迭时空 V100 TEE 扩展

进迭时空 V100 AI CPU原型除了实现了上述基于RISC-V架构的TEE 标准组件(PMP/ePMP、IOPMP)以外，还实现了基于HSM（Hardware Security Module）的硬件信任根（HW RoT), 并基于此信任根实现了整个AI CPU系统的安全启动、安全调试，旨在构建和提供完整的TEE软硬件系统和TEE解决方案。

HSM（Hardware Security Module）

V100 AI CPU集成了HSM硬件安全模块，旨在提供密码与安全功能。HSM能够实现密钥管理（密钥的生成、存储和处理）、安全启动、数据加密解密等一系列密码相关的功能，以及提供物理防护、安全传感器等安全保障机制，能够隔离外部恶意软件的攻击。HSM可以用于构建、验证可靠的软件,以保护在软件加载并初次访问之前的安全启动。HSM包含有加密/解密硬件加速功能, 和软件解决方案相比能够有效降低CPU负载并提高密码学运算的安全性。

根密钥作为整个硬件信任根(HW RoT)的基础，其密钥的安全性是整个安全子系统的核心考量。本方案使用HSM作为系统的RoT，密钥存储在OTP中，需要保证其机密性和完整性，同时需要严格管理密钥的访问和使用权限。加密后的密钥及其属性、CRC校验码均存储在OTP中，HSM硬件自动读取并校验CRC后，通过专用的SKE解密模块对密钥进行解密，并存储在KMU中以供后续使用。

HSM Key Management Overview

安全启动

安全启动主要提供以下功能：

安全启动机制

信任根RoT: OTP加密存储芯片唯一密钥(HUK), 支持客户根秘钥

信任链CoT: 通过ROT逐级验签, 实现信任链传递

安全启动组件

HSM: 国密二级认证安全岛, 提供秘钥的安全存储、派生和使用、国际(RSA/ECC/AES/DES/SHA等)、国密（SM2/3/4等）密码算法引擎

RMU子系统: 从BootROM到Bootloader到Firmware的安全启动

ROM安全启动流程

使用根公钥（Root Public Key）对Cerfiticates进行验签, 用HUK对加密密钥进行解密

参数段验签并传递参数

下一跳代码镜像解密

下一条代码镜像验签

传递Certfiticates并跳转到下一跳启动固件（FSBL）

ROM安全启动信任链

安全调试

当芯片/设备进入产品阶段, 也就是安全功能被激活之后，调试功能将会被关闭或者授权开启。HSM支持安全调试授权认证，只有通过认证之后，调试才允许被开启。安全调试的授权认证支持非对称或对称算法。

安全调试的授权认证流程如下：

主机通过 UART 或邮箱向 eHSM 发送调试请求

HSM 向主机发送challenge（UID + 随机数）

主机使用调试密钥对challenge进行签名，并发返回给HSM(a) 非对称：使用 hsm/ap 调试密钥的相应私钥进行签名(b) 对称：使用 hsm/ap 调试密钥计算 CMAC 值

HSM 使用 hsm/ap 调试密钥验证其签名

如果验证通过，HSM启用 hsm/ap 调试端口。

基于HSM实现AI CPU安全调试

TEE 软件架构

OP-TEE（Open Portable Trusted Execution Environment）是一个开源的可信执行环境（TEE）软件实现框架，它利用 ARM TrustZone 等硬件隔离技术（OP-TEE 早期专门为TrustZone设计实现，目前也已经支持RISC-V架构），将设备的运行环境分为安全世界（Secure World）和普通世界（Normal World）。

普通世界运行主操作系统，如 Linux、Android 等；安全世界则用于运行 OP-TEE 及执行敏感任务，确保安全世界中的应用程序和数据不受普通世界的干扰。OP-TEE支持 GlobalPlatform TEE 国际标准，保证与其他遵循同一标准的应用和服务能无缝协作，提高了其通用性和互操作性， 相比其他的TEE OS，OP-TEE目前支持几十种SoC板级，具有更好的软件生态。

而 OP-TEE Virtualization 是指 OP-TEE 具备对虚拟机场景的支持，允许TEE世界在不创建多个虚拟机运行多个TEE OS的情况下，使一个 OP-TEE 实例就能够服务于多个REE虚拟机各自的可信应用（TA)。进迭V100 支持CPU虚拟化，目前采用OP-TEE作为TEE OS，既能满足平台虚拟化的要求，也能很好地融入OP-TEE的软件生态，降低用户开发和学习成本。

基于OP-TEE 实现虚拟机场景的TEE整体软件框架

RISC-V机密计算

"机密计算"是一个商业用语，它旨在解决云计算场景下的可信计算问题。云服务提供商（CSP）主要提供云计算服务，也就是向用户出租算力，他们通常需要维护一组服务器作为专用或分时资源出租给用户。

为了实现算力分配和管理的灵活性，租用给用户的服务器通常通过虚拟机（VM）来呈现，CSP利用虚拟化技术将物理服务器”切割“成细粒度的虚拟机，这些虚拟机的资源可以通过Hypervisor（虚拟机管理器）灵活分配，并且虚拟机（VM）之间相互隔离，最终物理服务器的算力以虚拟机的方式呈现给用户，CSP通过虚拟化技术实现了算力的”池化“，并且能做到算力的灵活分配和管理，提高了算力的利用率。

从虚拟化技术来看，Hypervisor需要被VM完全的信任，就像操作系统上运行的应用程序需要完全地信任操作系统内核一样。由于Hypervisor可以任意地访问VM资源，而且Hypervisor的控制权是掌握在CSP手里，那就意味着CSP 必须被信任可以完全访问客户的 VM。然而，在传统的云计算场景下，租户和CSP之间存在如下的信任问题：

云租户的工作负载（特别是包含客户敏感数据的负载）可能被CSP访问到

云租户的敏感信息可能被泄露给其他租户（由于软件问题、错误配置或者其他漏洞);

云服务商和租户可能有相互冲突的商业目的， 例如，Amazon 为多家零售公司提供云服务，同时通过其在线市场与他们竞争

云服务商可能与租户的商业目标、国家安全目标和隐私法规相冲突的法规下运作

所以，为了实现真正的机密计算，使客户能够部署对隐私敏感的工作负载，机密计算的首要任务是要解决云租户和CSP(云提供商)之间的信任问题。

实现云计算场景的机密计算，同样可以采用TEE技术。相比于IoT TEE是将可信应用部署到TEE环境，机密计算技术需要实现的是将可信虚拟机（或者叫机密虚拟机）部署到TEE环境。

Deploying VM to TEE environment in Server Scenario

在云模型中，我们考虑以下参与者：

云服务提供商 （CSP） 运营所有基础设施，对所有机器具有物理访问权限，并控制除可信固件之外的所有平台软件。

云客户部署可能敏感的工作负载，以便在 CSP 托管的虚拟机中执行。

Silicon Provider 是提供硬件和可信固件组件的可信实体。

Adversary 旨在破坏客户工作负载的机密性、完整性和有限程度的可用性。

下图是云场景机密计算的通用参考架构，主要说明了基于 VM 的机密计算中的常见组件。

普通 VM 之间可以通过共享内存相互通信 。

普通 VM 与虚拟机管理程序通信 。

安全 VM 通常不允许由虚拟机管理程序访问，而是由新的安全软件层管理。该软件层还可以监督其他虚拟化功能，例如处理 hypercall 和中断 。请注意，可能需要修改 VM 操作系统 （OS） 以支持在此新环境中执行。

最后，需要提供新的安全机制保护安全内存区域，防止虚拟机管理程序直接访问 。

The Reference Model of Deploying Secure VM to TEE environment

RISC-V Confidential Virtual Machine Extension (CoVE)

上述参考架构需要解决的核心问题是解决REE和TEE之间的隔离问题。那RISC-V是否可以仍然利用PMP/IOPMP隔离组件实现TEE机密执行环境呢？答案是不可以，原因是目前的PMP/IOPMP不符合虚拟机管理的用户场景。

前面介绍的IoT TEE的执行环境的资源通常是静态分配的，这些资源主要包括物理内存、MMIO以及外设等， 由于资源是静态分配，内存管理可以不依赖与操作系统按页方式的页式存储管理，直接将安全内存通过PMP静态隔离，不纳入操作系统管理。

TrustZone也是类似的方式，所以Arm也称TrustZone为Static TrustZone (Armv9 CCA架构也叫做Dynamic TrustZone)。

但是，虚拟化场景下的物理资源（物理内存、MMIO等）并不是静态划分的，而是统一纳入Hypervisor管理。由于Hypervisor (如Linux作为Type2 hypervisor) 通常通过MMU来实现页式存储管理，这意味着内存管理的颗粒度至少需要达到按页的力度（如4KB每页)。

同时，虚拟机资源的管理包括虚拟机的创建、销毁都是Hypervisor负责的，那么通过PMP去实现内存隔离的颗粒度也要满足按页的要求，这是PMP/ePMP无法满足的，PMP/ePMP基于region的管理方式无法做到像MMU那样的颗粒度和灵活度。

于是， RISC-V为了满足机密计算的物理地址空间的隔离要求，实现了page颗粒度的物理内存保护,也就是Page-based PMP和Paged-based IOPMP, RISC-V称之为SMMTT（Supervisor Domain Access Protection）扩展。

它主要用于支持多租户安全场景下的Supervisor Domain隔离，涵盖机密计算、可信平台服务、故障隔离等领域。smmtt通过对Supervisor Domain内存的有效管理和访问控制，实现不同安全域之间的隔离与保护, 限制Hypervisor对机密虚拟机内存的非法访问。

在机密计算场景中，smmtt 确保一个租户无法非法访问其他租户的内存空间, 能防止不同租户的机密数据相互泄露，增强了系统的安全性和稳定性。

RISC-V SMMTT定义了通过硬件保证的可信计算基(TCB) 保护使用中数据的机密性和完整性以抵御软件和硬件攻击的机制。同时， RISC-V 也定义了机密计算架构的软件规范，CoVE和CoVE-IO。

RISC-V CoVE和CoVE-IO，定义了基于 RISC-V 应用处理器平台上可扩展的可信执行环境的威胁模型、参考架构和ABI接口规范，以支持机密计算场景。

CoVE的ABI规范主要定义了TCB 和非 TCB 组件之间的 ABI 的非 ISA 规范，此 ABI 使 OS/VMM 软件能够管理机密工作负载，同时将 OS/VMM 软件、固件、开发人员和系统操作员置于 TCB 之外，并且也定义了 TCB 和工作负载组件之间的 ABI（例如 TEE VM）的相关非 ISA 规范。

RISC-V 机密计算参考架构如下：

RISC-V TEE Reference Model in Server Scenario

以上便是RISC-V 架构机密计算的主要轮廓。总结一下就是，RISC-V重新定义了基于页表管理的物理地址保护组件（SMMTT， IOMTT包含在SMMTT规范中)， 旨在满足机密虚拟机场景的隔离要求。同时， RISC-V也定义了机密计算可信执行环境的威胁模型、参考架构和ABI接口规范，以支持机密计算场景。

RISC-V TEE-IO (CoVE-IO)

但有的小伙伴可能会问，那RISC-V在机密计算场景下是如何管理安全外设(TEE-IO)的，因为机密虚拟机（租户）往往需要将设备直通到虚拟机以提高I/O吞吐，而服务器下的I/O设备通常是PCIe设备，这些设备通常是可动态插拔的，机密虚机管理器是如何识别动态可插拔设备的安全性的呢？

早期的时候，设备的I/O虚拟化是基于软件来实现的，也就是I/O设备不会直通到机密虚拟机，因为当时还没有完整的规范来定义TEE-IO设备，于是所有的IO设备被当作Non TEE-IO挂在非安全Domain, 不受信任的虚拟机管理程序（VMM）使用由他管理的共享IO（不受信任）和半虚拟化设备接口将虚拟设备呈现给机密虚拟机，机密虚拟机使用VirtIO的方式访问虚拟设备, 比如Intel TDX 1.0就是这么干的。

基于软件的 IO 模型很慢，因为 CVM和设备之间的通信是通过共享内存（不受信任）完成的，这需要机密虚拟机在TEE domain内运行的应用程序的私有缓冲区和设备使用的共享 IO 缓冲区之间来回复制和加密/解密数据。

因为共享IO缓冲区是不受信任的，这就需要机密虚拟机在生产数据的时候将数据先加密之后Copy到共享缓冲区；而在消费数据的时候则需要先将数据解密之后再将数据Copy到CVM私有缓冲区。对于某些 IO 用例，例如网络和存储，这种IO方式与 通过IOMMU 实现设备直通的低延迟和高吞吐量相比，这种方法存在性能开销问题。除了性能开销之外，加密数据保护还不允许 TEE domain将计算卸载到传统的 GPU 或 FPGA 加速器上。

IO Transactions with IO Virtualizations (VirtIO) in Server Scenario

TEE-IO 旨在从两个方面改进 TEE 的 IO 虚拟化：

功能：TEE domain和设备无需使用共享缓冲区来存储私有数据，包括与设备建立安全传输级会话（通常使用专有协议来调整特定设备的数据处理和转换需求）。

性能：消除在共享设备缓冲区和私有 TEE domain内存之间来回复制加密或复制解密数据所需的额外资源和工作，从而大大提高工作负载性能（就带宽和延迟而言）。

简单来说，就是TEE-IO能够建立IO设备和机密虚拟机之间的信任关系，从而将IO设备直通到机密虚拟机。

IO Transactions with IO Virtualizations (Passthrough) in Server Scenario

RISC-V 机密计算为了实现高性能I/O 操作，可信执行环境虚拟机 (TVM) 必须扩展其信任边界，包含分配TEE-I/O 设备的功能。如果没有这种能力，TVM 就不得不使用半虚拟化 I/O，使用非机密内存区域，这会因上面提到的内存副本拷贝和加解密而影响性能，并且无法将密集计算卸载到加速卡。同时RISC-V CoVE-IO TG定义了 ABI 扩展，为机密 VM 分配的设备提供对机密内存以及 MMIO 和消息信号中断 (MSI) 的安全直接访问，从而消除对半虚拟化 I/O 的依赖。

RISC-V TEE-IO 依赖于以下扩展和行业框架：

CPU：smmtt扩展， 提供机密计算隔离环境

传输：使用 PCIe selective IDE 流进行端到端数据保护

设备：允许 TEE domain 使用 SPDM、IDE 和 TDISP 等功能、行业协议将TEE 和 TCB扩展到他们选择信任的 TEE-IO 设备

RISC-V完整的TEE-IO软硬件框架如下图所示：

The Overview of RISC-V TEE-IO Architecture

结束语

我们既要铭记计算机之父图灵“机器也许有一天能像人类一样思考”的远见，也要直面爱德华·斯诺登（Edward Snowden）“隐私已死”的警示。正如著名的网络安全专家 Bruce Schneier 所言：“Security is a process, not a product.”（安全是一个过程，而非一种产品), 唯有将安全的基因融入技术的每一处脉络, 方能在数字洪流中筑起可信的方舟。