构建安全计算生态 | RISC-V 安全机制的架构设计

 

玄铁 RISC-V 软硬件技术深度解读系列，将从 AI、高性能计算、安全和边缘计算等多个方向，全面介绍玄铁 RISC-V 软硬件技术实现。本周我们将带来 RISC-V 安全机制相关技术分享。

赵思齐

阿里巴巴达摩院 高级技术专家

 

RVI Technical Steering Committee(TSC) 成员，担任 Memory Tagging TG 的 Vice Chair、Unified Discovery TG 的 Chair 及 Scalar Efficiency SIG 的 Vice Chair，RISC-V IOMMU Spec 贡献者。

 

引言

“I have witnessed their capacity for courage,

and though we are worlds apart,
like us, there's more to them than meets the eye.
……”

“我亲眼见证了他们的勇敢无畏，
尽管我们来自不同的世界，
跟我们一样，他们远不是表面所看到的那样。
……”

2007年上映的电影《变形金刚》片尾，擎天柱面对宇宙繁星发出了这么一番独白。之所以引用这段话是因为里面这句“ more than meets the eye ”，在某种程度上可以用来描述现实世界的方方面面，包括本文想要探讨的安全问题。“ More than meets the eye ”想要表达的意思很简单：“事物并不是看上去那样”，笔者同样也认为，不是只有能看得到的事情才会发生，看不见的事情，也在发生。

什么看不见的事情正在发生？

比如对暴露在公网上的计算机端口无时无刻都在进行的端口扫描、弱密码登录试探，偶尔登上头条的加密货币交易所被攻破的新闻，对各种服务平台的用户信息的搜集、交叉引用，对各种互联网平台的数据库的整体窃取、倒卖，如此等等。

计算机系统的安全问题一直存在，悄无声息，普罗大众无从知晓又无所适从。如果你将自家的某台电脑暴露在公网上，查看下系统 log，那么大概率你会发现时不时会有那么几条连续不断的失败登录请求。对，你被攻击了。笔者印象里曾经有安全研究人员做过实验，将一台没有安装任何防护软件的电脑直接暴露在公网上，从放上去开始到这台电脑被成功入侵的平均时间只有几十分钟。

所有这些简单的现象表明，安全问题是真实存在的。世界并不是所有人想象的、希望的和认为的那么遵守规矩和法则，阳光普照的世界总会有阴暗的地方。

“There's more than meets the eye.”

 

 01 系统安全机制

既然有了问题，那么不得不防。计算机安全这个话题涉及的范围甚广，本文的篇幅内无法面面俱到。本文希望基于 RISC-V 架构，介绍 RISC-V 架构面向安全问题所做的针对性设计。这些设计是在系统架构设计内面对一部分特定安全问题作出的应对，并不能解决所有的安全问题；完整的安全架构通常需要纵深防御，defence-in-depth，需要系统全面的共同抵御。本文将主要介绍 RISC-V 内相比其他架构更为独特的设计，一些基础的安全保护功能比如特权级和 MMU 这里不做赘述。

此处需要特别指出的是中文的“安全”有两个相关的英文词汇。英文文献内有两个概念 Safety 和 Security，通常翻译成中文都是“安全”。但是两者的含义不同，前者指在自然发生的错误、事故情况下，保证正确的功能性。后者指在人为恶意制造的错误、事故前提下，保证正确的功能性；后者对系统设计的要求更高，可以通过 ECC 码的例子来区分两者。ECC 码是一种 Safety 机制但不是 Security 机制，因为它可以预防自然发生的比如宇宙射线引起的数据错误，但是无法预防人为制造 ECC 码，使系统采用被篡改但是同时被 ECC 覆盖的数据的攻击。

本文将介绍 RISC-V 架构的针对性安全功能，将主要围绕如下三个关键的安全问题展开：

1. 针对固件的代码和数据的隔离：确保系统内的固件代码和数据具有严格的访问权限，防止未经授权的访问或篡改。

2. Return-Oriented Programming （ROP）攻击：通过防御机制抑制此类基于控制流劫持的攻击手段，提升系统的抗攻击能力。

3. 机密计算：提供硬件支持的隔离与保护技术，保障敏感数据和计算过程的隐私与安全。

第一个问题之所以存在，更多源于 RISC-V 架构本身的设计。RISC-V 的 M 模式虽然拥有更高的特权等级，但由于缺少 MMU（内存管理单元）的支持，如何保护 M 模式自身的代码和数据便成了一个亟待解决的难题。为应对此挑战，RISC-V 引入了 PMP（物理内存保护）机制，并进一步扩展为 EPMP（扩展物理内存保护），以实现对 M 模式资源的有效保护。

讨论第二个问题前，有必要先介绍更多的背景。ROP 之所以流行，源于一种早期流行攻击方式被硬件引入的不可执行页机制所抑制。更早期的黑客面对的世界更简单，通常只需要构造一些指令，并通过漏洞将这些指令的二进制写到被攻击机器的某个地址，再设法通过 jump 指令跳转到这些代码执行，从而达到能够执行任意指令的目的。

为了防御此类攻击，DEP（Data Execution Prevention，数据执行预防）和“ W XOR X ”的页映射策略被引入。这些机制的核心思想是将数据存储的内存页标记为不可执行，从而使得写入的数据无法被 CPU 直接执行。这一防御策略大幅降低了传统代码注入攻击的成功率。

但是后来的黑客找到了不注入代码的攻击方法 —— 代码复用攻击（code reuse attack）。这种攻击仅仅利用被攻击的机器上已有的代码，通过精心设计的跳转方法，将这些已有的代码块串起来以完成攻击意图。其中，ROP 是这类攻击中最著名的一种。ROP 攻击通过在栈上注入的一连串返回地址，跳转到预先选定的代码片段（称为“ Gadget ”）中。每段 Gadget 通常以 ‘return’ 指令结束，执行完成后，return 指令会从栈上取出下一段的地址并跳转。如此一来，攻击者能够灵活地串联多个 gadget，实现复杂的攻击行为。

为了抵御 ROP 攻击，需要在代码执行过程中提供的保证被称作“控制流完整性” (Control Flow Integrity, CFI）。也就是说，代码真正执行的控制流要符合某种事先规定好的控制流，而不能任意跳转。需要特别注意的是，理论上完美的控制流完整性需要的代价相当昂贵，现有硬件架构内的CFI机制都是对完美 CFI 的一种近似实现。

针对 ROP 攻击，RISC-V 架构提出了影子栈（Shadow Stack）扩展，作为一种专门设计的 CFI 防御机制。

第三个问题是云服务的流行，特别是公有云的流行带来的。在公有云的架构中，云服务商对所有租户的虚拟机具有完全的访问权限。这里的权限指的是技术上可能的权限，法规上可能禁止这些访问，但是在技术上依旧是可行的。既然在技术上可行，那么租户的数据依旧可能被无意的访问到。虽然云服务商并没有主观去访问这些数据的意图，但事故总会发生。这对处理敏感数据的业务，比如政务、财务、医疗等，始终是一种担忧。

机密计算旨在解决这个问题。机密计算提供一系列的硬件扩展，将本来存在于低特权级的租户数据进行隔离或者加密，使得云服务商无法触碰到租户的敏感数据。租户不再需要同时信任云服务商和云硬件提供商，而只需要信任后者，从而显著提升数据的安全性。

RISC-V 为机密计算提供了多项关键扩展，包括：

• CoVE（Confidential VM Extension，机密虚拟机扩展）
• MTT（Memory Tracking Table，内存跟踪表，暂定名）扩展
• IO-MTT（Input/Output Memory Tracking Table，输入输出内存跟踪表，暂定名）扩展

这些扩展共同为 RISC-V 架构的机密计算定义了明确的 ABI（应用二进制接口）和硬件基础。

需要特别指出的是，机密计算的概念和常见的源自 Arm 的 TEE 概念所面对的使用场景和系统设计完全不同。两者关系类似苹果和梨，不能直接对比。有 TEE 背景的读者需要先忘记已有的经验，重新理解。

 02 RISC-V 的安全机制

在介绍完 RISC-V 的安全系统后，我们进一步探讨 RISC-V 安全机制的实现。针对上述三个问题，RISC-V 是如何解决这些问题的，以提供安全基座。以下将介绍 RISC-V 架构中用到的不同安全机制。

1. 对来自 CPU 的数据访问进行授权：PMP 和 ePMP

1.1 物理内存保护（PMP，Physical Memory Protection）

PMP 机制使用访问权限（读取、写入、执行）来限制对物理内存区域的访问。这种机制允许对小至4字节的区域进行细粒度的访问控制。通过这种方式，PMP 能够提供更加安全和精确的内存保护，防止未授权的访问或操作，确保系统的稳定性和安全性。

PMP 检查在指令获取、数据访问以及页表访问时对运行在 S 模式或 U 模式下的软件强制执行。此外 PMP 还提供可选功能，可以扩展到对 M 模式的内存访问进行监控。

PMP 的配置是通过 PMP CSR 寄存器来实现的，这些寄存器保存了区域的地址、大小、允许的权限（读取、写入、执行），以及一个锁定位（lock bit）。锁定位可以用来禁止对该 PMP 配置进行进一步的更改，一旦设置了锁定位，相应的 PMP 规则就不能再被修改，直到系统复位或者该锁定位被清除。这种机制提供了灵活且强大的内存保护能力，确保不同特权级别的代码只能按照预设的安全策略访问特定的内存区域。

1.2 增强型物理内存保护（ePMP，Enhanced Physical Memory Protection)

通过 PMP 无法实现仅对非机器模式强制执行规则，而同时禁止对机器模式访问内存区域的规定。即只能拥有对所有模式都生效的锁定规则，或者只对非机器模式生效、而被机器模式忽略的规则。因此，对于任何没有用锁定规则保护的物理内存区域，机器模式具有无限访问权限，包括执行能力。为了弥补这一差距，Smepmp 标准（Smepmp 是 ePMP 在 RISC-V 规范中被分配的专有名称）于 2021 年得到 RVI 批准。

ePMP 引入了一种覆盖 PMP 规则锁定机制的方法。可以在 PMP 重置后进行锁定，并且可以通过设置 ePMP CSR 中的一个位来阻止锁定（以确定 PMP 的行为）。此外，ePMP 引入了一种机制，可以仅对 M 模式或仅对 S/U 模式强制执行 PMP 规则。ePMP 允许建立增强的 PMP 规则，防止 M 模式访问来自 S/U 模式代码的资源。这一机制有效减少了在 M 模式代码中出现特权升级漏洞可能带来的攻击。类似的机制在 x86 架构内被称作 SMEP（Supervisor Mode Execution Protection）和 SMAP（Supervisor Mode Access Prevention），通过设置 CR4 控制寄存器完成。不同的是 x86 上的这两种机制是针对内核态的保护设置的。从安全设计的角度来看，这些机制的相同点是都可能存在类似的漏洞，利用高特权级的代码来帮助低特权级的攻击者访问到攻击者本不应该访问到的数据或者代码。只是具体的特权态不同。一组可能的 ePMP 规则可以包括：

• 一个内存区域，仅在 M 模式下可访问（可读和可执行），用于固件代码。

一个内存区域，仅在 M 模式下可访问（可读和可写），用于固件数据。

• 一个内存区域，在 S/U 模式下可访问（可读、可写和可执行），用于操作系统在 S 模式下的进一步资源管理。然后，操作系统可以使用 MMU（内存管理单元）来进一步限制对此内存区域的访问。

2. 防护来自外设的 DMA 攻击：IOMMURISC-V 的 MMU 通过定义一组页表来映射虚拟地址到物理内存中的地址，从而连接 CPU 到系统内存。IOMMU 扩展提供了相应的机制，用于将 DMA 设备连接到系统内存。IOMMU 的加入可以有效防止利用设备 DMA 发起的对非授权数据的访问，比如著名的利用早期苹果电脑上具有 DMA 能力的火线（Firewire 或者 IEEE1394）外设进行攻击的案例。这类攻击被简单的称作 DMA Attack。3. 防护 ROP 攻击：影子栈扩展(Shadow Stack Extension)

影子栈扩展引入了一种新的页面类型，即影子栈（Shadow Stack，SS）页面。这种页面不能通过普通的加载/存储指令访问，而是指定了两条指令 —— sspush 和 sspop：

sspush: 将值压入影子栈。

• sspop: 从影子栈弹出最后压入的值。

软件可以利用这一机制将返回地址推入影子栈，并在函数返回时读回该值并与正常栈上的值进行比较。这使得能够识别栈上可能被篡改的返回地址。

除了 sspush 和 sspop 之外，规范还指定了 ssamoswap 指令，用于在监督模式下交换当前的影子栈指针，以支持上下文切换。

4. S模式物理内存保护（SPMP）SPMP 机制与 ePMP 机制类似，但允许 S 模式管理 U 模式对物理内存的访问限制。这在没有 MMU 的情景中特别有用，其中需要隔离 S 模式代码和 U 模式代码。

5. 机密计算相关的扩展

5.1 监督域访问保护（Smmtt）

Smmtt 扩展定义了多个扩展，以有效管理多租户系统中的多个监督域。根域安全管理器（RDSM）可以利用 PMP、ePMP 和/或 IO-PMP 来隔离不同监督域之间的物理内存。Smmtt 还支持基于 RISC-V 虚拟化扩展的虚拟化监督域。

Smmtt 的各个子扩展分别是：

• Smsdid：用于切换 hart 正在运行的活动监督域的扩展。
• Smmpt：用于设置与监督域相关联的访问权限的扩展。
• IO-MPT：指定由 IOMMU 和与该监督域关联的设备执行的内存访问控制机制的扩展。
• Smsdia：启用 IMSIC 中断文件或 APLIC 域分配给监督域的扩展。
• Smsdedbg：指定监督域调试设置的扩展。
• Smsdetrc：指定监督域跟踪设置的扩展。
• Smsqosid：指定监督域 QoS 设置的扩展。

5.2 AP-TEE / CoVE

RISC-V 机密虚拟机扩展（CoVE）是一个非 ISA 扩展，它定义了 RISC-V 的抽象可信执行环境（TEE）架构，包括相关的软件组件及其职责。此外，还指定了 SBI 扩展，允许多个软件组件之间进行交互。

CoVE 的关键组件是 TEE 安全管理器（TSM），其在 HS 模式下运行，并管理 S 和 U 模式中的可信代码（即可信虚拟机或 TVM）。TVM 可以使用 COVG-ABI 与 TSM 交互。第二个接口，COVEH-ABI，允许非可信主机操作系统与 TSM 交互。这两个接口都是基于 RISC-V SBI 规范构建的。由于 TSM 在 HS 模式下运行，因此需要在 M 模式下有一个 TSM 驱动程序来委托请求给 TSM。

CoVE 并不定义一个严格的架构，而是足够灵活，可以扩展到从简单的嵌入式系统到多租户数据中心解决方案。这意味着，无论解决方案如何，所有与安全相关的 SBI 调用都已经由支持 CoVE 的组件指定并支持。

测量（提供表示 TVM 状态的哈希值）和（远程）证明是可信应用程序的常见用例。因此，CoVE 也定义了实现这些用例的 ABIs。

结语

RISC-V 通过引入多层次、多维度的安全机制，为计算服务提供了强有力的安全保障。从基础的物理内存保护（如 ePMP 和 SPMP ）到针对多租户环境的监督域访问保护（Smmtt），再到支持可信执行环境的 CoVE 扩展，这些机制体现了 RISC-V 架构在性能与安全性上的深度融合与灵活性。无论是在嵌入式设备还是云端数据中心，这些安全特性均可因地制宜地部署，满足多样化的应用需求，为构建更安全的计算生态打下坚实基础。

正如我们在宇宙繁星中寻找答案，RISC-V 的安全设计也提醒我们，看不见的威胁正在发生，而只有 “more than meets the eye” 的技术创新，才能让计算的世界更加安全与可靠。