blog
0%

riscv 硬件安全机制.md

发表于 更新于 分类于 Valine：

PMP

RISC-V架构提供了一种PMP物理内存保护机制，用于隔离M模式与S/U模式下的内存访问。只有M模式才有权限配置PMP。

PMP包含几组(通常是8到16个)地址寄存器以及相应的配置寄存器，这些配置寄存器可以授予或拒绝S/U模式的读、写和执行权限。

PMP同时也能保护内存映射I/O (MMIO)，M模式可信固件可以通过配置PMP来约束处理器对外设I/O的访问。

配置cpu csr
物理内存保护设置寄存器（PMPCFG）
物理内存保护地址寄存器（PMPADDR）
PMP 共实现了 8 个地址寄存器 pmpaddr0-pmpaddr7，存放表项的物理地址

缺点:

仅适用于单一核心, 无法与其他核心同步, 需要添加同步控制.
只能够对内存进行保护

GPU/PPU/NPU never check

IOPMP

ANDES thead 安全扩展

进riscv 主线进展: The IOPMP specification is still under discussion, and its ratification target date is Q4, 2023.

  • A source-ID represents a bus master or a group of bus masters with the same permission.
  • A bus master has one, but could be the same as another.
  • A bus master with multi-channel, multi-VM or multi-mode may need 1+ SIDs.

 IOPMP被用来规范请求。谁可以访问哪些数据？
 Source-ID, entry, ports, matching rules and violation responses.

总线上的其他主设备同样需要对内存的访问进行保护，也就是外设需要增加IOPMP。IOPMP可以像PMP一样定义访问权限，他会检查从总线或者主设备过来的读、写传输是否符合权限访问规则，只有合法的读、写请求才能进一步传输到目标设备上。通常有3种方法来连接IOPMP：

请求端连接IOPMP

在每个主设备和总线之间增加一个IOPMP，类似RISC-V的PMP。不同的主设备需要分别新增一个IOPMP，IOPMP之间互相独立。这种设计较为简单，也提供了灵活性，但IOPMP不能在主设备之间共享。如下图所示:

目标端连接IOPMP

目标端的IOPMP需要对不同主设备发来的传输进行区分，这就需要每个主设备的访问请求都要附带额外的Master ID。如下图所示:

请求端和目标端级联IOPMP

在复杂的SoC系统中，往往存在IOPMP级联的使用情况。典型的场景就是RISC-Cores自身带有PMP，处理器并不需要目标端的IOPMP再次对他的访问进行过滤。通用的处理方法是，在IOPMP的表项里取消对CPU访问的约束，但缺点是这会占用IOPMP表项，也会影响效率。为了提高IOPMP级联下的访问效率，IOPMP需要提供一种机制来直通部分主设备的访问，比如提供可配置的以直通模式访问的主设备列表。

ANDES/THEAD

sifive shield

SiFive WorldGuard是一个用于隔离代码执行和数据保护的细粒度安全模型。SiFive Worldguard提供SoC级别的信息控制，具有先进的隔离控制，基于每个世界的多个权限级别。SiFive WorldGuard为多域安全提供了核心驱动和进程ID驱动的模式，为核心、缓存、互连、外围和内存提供数据保护。


在多核处理器中，如上图所示，世界ID标记被用来将进程相互隔离，以确保保护和隔离的执行。在SoC内部，WID标记从核心延伸到缓存、互连、外设、总线master、DMA区域和存储器。应用程序或操作系统环境可以在一个高性能的多核系统中被隔离和保护。对于单核更常见的嵌入式系统，PID驱动的世界ID在用户和机器模式之间保护和隔离执行。

这个解决方案并没有取代RISC‑V核心的PMP机制（适用于单核的存储器），也没有取代存储器管理单元（MMU），而是将它们扩展到有其他发起者的多核系统，并提供更强的安全性

对于更复杂的多核平台，PMP和特权模式方法有一个主要的限制。由于特权模式和PMP作用域仅限于其核心和软件，它们只能控制单个核心的内存映射区域。特权管理寄存器属于那个单一的内核，所以它们的值和产生的控制既不与其他内核共享，也不和其他核心协同，因此需要复杂的同步工作。在这种情况下，使用受信任的核心可能是首选。

PMP方法的另一个限制适用于”fractured” 物理地址内存map。在这种情况下，所需的PMP条目数可能会变得太大，无法接受。SiFive WorldGuard解决方案是一个很好的选择。


发起方（绿色）都配备了一个wgMarker，标记他们的出站请求

受信核心，通过发送标有受信任的WID的请求来配置wgMarkers（蓝色）和wgCheckers（粉红色）。

Any marked transaction goes through the wg-aware bus and blocks (e.g., L2 cache) until the targeted wgChecker is reached

The wgChecker (regardless of complexity) determines if the WID and related meta-data (access type) are consistent with the rules it contains; if it matches, the transaction is authorized

请求从其WID信息中释放出来，被发送到资源（中断控制器、调试模块）或出站端口（内存端口、外围端口、系统端口）。

VirtualZone

玄铁C系列处理器的安全拓展

该扩展主要基于RISC-V架构提供的PMP保护机制和多层特权模型，虚拟出多个相互隔离的可执行域(Zone)，从而实现了RISC-V架构上的可信执行环境（TEE），并保护Zone内的软硬件信息，包括软件、内存、外设、I/O等免受其他Zone的非法访问。处理器资源包括Cache、中断、内存、代码执行等经过隔离之后，处理器将分时地运行在不同的Zone内，配合SoC其他的保护机制如IOPMP，共同构建一个基于软硬件协同工作的安全系统。

虽然RISC-V架构的处理器具备物理内存保护、多层权限模型、内存管理单元等技术来支持可信执行环境功能的实现，但处理器仍然需要支持其他安全规范才能创建完全可用的安全执行环境。为了满足TEE(Trusted Execution Environment)的隔离要求，玄铁C系列处理器在RISC-V架构基础上进行了安全扩展。 该系列处理器在软件的协调下可以虚拟出多个执行域(Zone)，每个Zone增加了域标识，也就是Zone ID，整体架构如Figure 2所示。每个Zone可以独立地运行各自的操作系统以及基于该操作系统的应用程序。操作系统运行在超级用户特权模式，应用程序运行在普通用户特权模式。处理器根据需要在不同的Zone里切换运行。当处理器切换到某一Zone运行时，他将实时占用整个物理核，并且处理器的域标识也将同时被更新成相应执行域的标识。Zone的切换由运行在最高模式(机器模式)下的可信固件(TF)来完成。

Zone之间访问隔离通过PMP(Physical Memory Protection)实时切换来实现，PMP是RISC-V特权ISA的一部分，用于隔离机器模式和超级用户模式/普通用户模式之间的物理地址访问，玄铁处理器的L1/L2 Cache同时也受PMP保护。

当硬件线程从一个Zone切换到另一个Zone时，PMP配置同时也需要切换。M模式可信固件需要先保存当前Zone的PMP配置，然后载入下一个即将切换的Zone的PMP配置，完成对内存和内存映射I/O (MMIO)访问权限的切换。

当多个Zone需要共享内存时，可以将需要共同访问的内存区域的访问权限同时授予给多个Zone，也就是将该块内存的允许访问权限写到每个Zone的PMP配置表里，PMP表会在Zone切换时由可信固件进行更新。Figure 3是一个典型的多个Zone的PMP配置图， SHM区域是Zone间允许共同访问的共享内存区域。

机器模式可以通过PMP的锁定功能将机器模式的访问限制在有限的区域内，比如只允许机器模式访问、执行划分给可信固件的内存区域，以减少受到对机器模式攻击的影响，也就是Supervisor Memory Access Prevention（SMAP）和Supervisor Memory Execution Prevention（SMEP），从而增加对关键信息的保护。

下图是玄铁处理器采用PMP、IOPMP来构建安全SoC的系统参考框图:

当不同Zone之间需要切换时，运行在机器模式的可信固件需要对Zone的上下文进行保存和切换。虽然看起来这会带来开销，但像ARM TrustZone的虚拟化技术同样需要对世界进行切换，这部分切换的工作同样被隐藏在Monitor的可信固件中。不同的是，ARM TrustZone只虚拟出了2个世界，而玄铁RISC-V处理器在安全扩展之后，最多允许同时支持16个Zone，这为以后的软件安全方案提供了更多的可能。

Mips 软件tee方案

在mips 指令集架构上比较著名的tee方案为SierraTEE

SierraTEE 采用mips的硬件虚拟化辅助来实现teeos 和 richos 之间的运行环境隔离

下图为 SierraTEE 的基础框架:

绿色部分为 SierraTEE 的组件.

  • host os中 user mode下的GPI 库, 即通用的api, app 可以通过该库的api 发送安全请求, 该请求首先会发到 host os的kernel的负责接管安全需求的driver.
  • host os中 os mode下的 kernel 中添加的 Secure Driver, 该Driver 负责向 hypervisor 发送安全请求
  • hypervisor 虚拟化mode下的 hypervisor TEE HAL, 用来接收 rich os 和 teeos的请求
  • secure os, 该os 和 rich os 处于同一mode, 可以把该os理解为guest os. hypervisor monitor 监视层收到 host os的安全请求后, 会进行os切换, 切换到对应的 teeos 处理对应的请求.
  • secure os的GPI库, 即符合某个规范的通用api, 该api 是给secure os下的app 用的, secure os下的app 也叫ta, 每个ta负责单一的业务.
  • secure os下的app, 也叫ta, 负责单一业务, 每个ta 都有一个uuid, host os下的app 要处理某一安全业务时, 需要指定对应的 ta的uuid, 来处理特定的业务.

可以看到 SierraTEE 是利用了mips的硬件虚拟化辅助来实现运行环境隔离的.

通过vcpu的调度由 host os 切换到 guest os. host os为richos, guest os 为 teeos, 两者之间的通信由高一权限级别的hypervisor mode接管.

riscv tee 方案

riscv 开源的tee方案有伯克利的keystone 和 上交大实验室的 蓬莱 方案.

两者的架构差不多

下图是大概的架构

其中绿色部分为 keystone/蓬莱 方案增加的组件.

  • rich os 中 secure clint api 库, 供richos 下的u-mode下的app使用, 用来发送安全请求
  • rich os的kernel 中添加 secure driver, 负责承接 u-mode下的app请求, 并负责解析加载 tee enclave app elf, 发送安全请求给opensbi
  • M-mode的opensbi中新增的 secure hal 负责richos 和 tee运行环境的切换, 还有PMP 的配置, tee 运行环境的内存和rich os的运行内存是隔离的, 由cpu的core的配置的pmp策略进行保护
  • tee 运行环境包含了 S-mode 的rt 运行时和 U-mode的enclave app 两部分构成, 最终由enclave app负责具体的安全边界计算. 而rt 运行时则负责 trap 中断等.

值得注意的是这两个方案目前都比较基础, secure 世界运行的实体还没进化到完全os的阶段, 是由运行时(Supervisor mode) + enclave app (user mode) 组成, 只能处理比较简单的请求, 也没有定义通用的符合tee规范的 GPI. 所以使用场景是受限的. enclave app所能使用的基础的软件接口非常少. 只能写比较简单的类似baremental的应用, 使用受限.

而大型的teeos 如op-tee 还没有对riscv 适配完成.