浅析RISC-V TEE的SoC级安全模块——IOPMP

前言

安全问题一直是体系结构领域的热门话题，《RISC-V处理器的安全挑战——浅析体系结构漏洞与攻击风险》一文中详细介绍了现代处理器微架构设计中遇到的缓存侧信道攻击、内存漏洞攻击等安全挑战，并归纳了学术界和业界针对这些架构漏洞所提出的防御措施。

上述这篇文章主要是围绕处理器核内安全展开的，因此本文换个角度出发，试着揭露目前RISC-V处理器核外存在的安全问题，并着重探讨用于保障RISC-V SoC系统安全的新模块——IOPMP。

一、IOPMP的提出背景

刚看到文章标题的读者内心肯定会有三个疑问：什么是IOPMP？IOPMP和PMP的区别是什么？为什么TEE需要IOPMP？别急，故事的来龙去脉可以从TEE的概念开始慢慢谈起。

1.1 TEE简介

我们熟知的Linux、Android、IOS等通用操作系统，提供有丰富的用户接口和管理功能，故亦被称为Rich OS，而运行这些Rich OS的系统环境，则相应地称作REE(Rich Execution Environment) 。基于相对开放的REE环境，开发者可以灵活研发应用并部署自身业务，但这同时也意味着更多的危险，恶意软件可能会试图窃取敏感数据、盗用支付密码、滥用数字版权等等，严重威胁用户的信息和财产安全。而且随着操作系统代码体量的逐年增大，Rich OS自身存在的安全漏洞也不断涌现，这种猫捉老鼠般的Bug修复游戏困扰着每一代软件工程师，至今仍是未解之谜。

面对REE日益凸显的安全问题，GP(Global Platform)在2010年7月提出了TEE(Trusted Execution Environment)的概念并陆续制定了相关技术标准。TEE是一个与REE并存但相互隔离的执行环境，其拥有比REE更高的安全等级，可以保证内部代码和数据的机密性以及完整性。通过密钥验证后，在其内部构建独立于Rich OS的小型操作系统，可以运行对安全和隐私有高度诉求的可信应用程序(Trusted Application)，例如数字版权保护、指纹识别、移动支付等，从而避免来自REE中的软件漏洞攻击。

针对不同指令集架构，目前业界均已提出了对应的TEE解决方案，例如ARM的TrustZone、Intel的SGX(Software Guard Extensions)、AMD的PSP(Platform Security Processor)等。而近年来随着RISC-V指令集的蓬勃发展，Hex Five Security的MultiZone Security方案、加州大学伯克利分校的Keystone Enclave方案以及上海交通大学夏教授团队提出的Penglai Enclave方案相继问世。

1.2 PMP与IOPMP

TEE是软硬件协同设计的典型代表，其核心在于利用硬件安全模块和软件驱动配置来实现代码和数据的隔离！隔离！隔离！重要的事情必须说三遍！在RISC-V TEE解决方案中，最关键的隔离单元分别有MMU(Memory Management Unit)、PMP(Physical Memory Protection)、sPMP(S-Mode PMP)以及ePMP(Enhanced PMP)。

温馨提示：对上述专有名词概念较为模糊的读者可以学习本专栏的玄铁C910微架构学习(13)——内存管理单元、RISC-V Privilege Specification[2]、RISC-V SPMP Specification[3]以及RISC-V Smepmp Specification[4]。

其中，MMU内存管理单元主要负责虚拟地址到物理地址的翻译任务，内存虚拟化技术不仅能增加进程允许使用的地址空间范围，还能实现不同用户进程(U-Mode)之间以及用户进程与操作系统(S-Mode)之间的内存隔离；PMP物理内存保护单元主要负责对RISC-V HART的访存权限进行检查，实现不同操作系统之间以及M-Mode与S/U-Mode的隔离；sPMP单元则面向未支持MMU功能的IoT嵌入式场景，由于该系统直接使用物理地址进行寻址，需要借助sPMP来替代MMU单元限制U-Mode和S-Mode的访存权限，从而实现S/U-Mode的隔离；ePMP单元是RISC-V HART内部的最后一块拼图，用于解决PMP中M-Mode访存权限过高的问题，通过增加mseccfg寄存器来扩展PMPCFG.L位的功能，实现M-Mode和S/U-Mode访存权限的针对性检查，以保障整个RISC-V处理器核的安全。

基于MMU、PMP和ePMP，芯片供应商可以定制Application级的TEE解决方案，而基于sPMP、PMP、ePMP，则可以设计Embedded级的方案，以此来满足大部分的安全业务需求。但细心的读者很快可以发现，上述四类隔离单元是针对RISC-V处理器核设计的，那放眼整个SoC芯片系统，RISC-V处理器核外还有部分不含有RISC-V核的XPU(例如GPU、NPU、TPU等)、HAC (Hardware Accelerator)、具备访存能力的外设单元如NIC(Network Interface Card)等，它们的安全得到保障了嘛？

答案显然是“没有”！以DMA(Direct Memory Access Unit)为例，其作用是为了提高系统内数据搬运的效率，由于缺失与PMP功能类似的保护单元，DMA竟然拥有整个物理内存空间的访问权限，而这就是SoC系统的安全漏洞所在。如果黑客劫持了芯片内某个拥有DMA功能的外设单元，则其可以不受任何权限限制而轻松获取到用户的认证密钥、账户密码、Face ID等机密数据，造成不可估量的损失。参照以往关于PMP的设计经验，IOPMP(Input/Output Physical Memory Protection)的概念便由此应运而生，该安全模块由拥有M-Mode最高安全权限的Secure Monitor进行检查规则配置，专门用于规范具有DMA功能或者拥有Bus Master端口的外设的访存行为，在SoC级别为整个芯片系统提供安全保护。

二、术语

在正式介绍IOPMP的模型结构与设计方案之前，首先需要定义一些基本概念来帮助读者更好地理解其原理，而在本文剩余篇幅中也将直接引用这些专业术语，不再做详细的解释。

2.1 Transaction

对于事务(Transaction)的精确定义，或许可以在ARM的AXI Specification[6]中找到，这里所描述的AXI Transaction，指AXI Manager发送请求所需要完成的一系列总线操作。

When an AXI Manager initiates an AXI operation, targeting an AXI Subordinate: The complete set of required operations on the AXI bus form the AXI Transaction.

Transaction的事务类型有很多，例如负责数据读写的Read/Write Transaction、负责缓存信息维护的CMO Transaction、负责数据一致性维护的Snoop Transaction等等，在不同的总线协议中，其分类与定义也大相径庭。考虑到不同系统总线的传输位宽和突发长度的差异性，单条Transaction可被拆分为多条Transaction，而多条Transaction亦可进行合并。但不管怎样，我们可以试着引申Transaction的具体含义，将Bus Master向Bus Slave发送一次请求的完整动作称为一条Transaction。

IOPMP面向的检查对象其实就是Transaction，其需要拦截Bus Master发送的每条Transaction，然后利用Transaction内包含的请求类型、地址信息和数据位宽等信息，进行地址访问范围和访问权限的检查，只有符合IOPMP表项规定的Legal Transaction才会被转发给Bus Slave，并继续完成后续的数据传输动作。反之，不符合表项规定的Illegal Transaction则会被IOPMP无视，或者IOPMP会伪造假的总线响应信号给Bus Master，而Bus Slave几乎察觉不到非法事务的发生。

2.2 Source Identification (SID)

根据RISC-V IOPMP Specification[7]的描述，Source ID(SID)是指单个Bus Master或一组拥有相同访存权限的Bus Master所特有的ID号。

Source-ID, SID for short, is a unique ID to identify a bus master or a group of bus masters with the same permission.

但需要注意的是，针对DMA设备等拥有多个传输通道的Bus Master，如果通道间的权限不一致，则需要为每个通道都设置专属的SID号；而针对拥有多个特权等级的XPU，由于U/S/H/M-Mode间的权限是不同的，也需要为每个特权模式都单独设置SID号。所以笔者认为，SID更为确切的含义应该是每个总线设备的访存权限类型，即不同SID间的访存范围和操作权限是不同的，而具有相同权限的设备可以共享SID来节省硬件开销。

通过在Bus Master发送的Transaction中增加SID信息，IOPMP可以分辨出事务请求的来源，并根据规则表项进行针对性的权限检查工作。需要注意的是，有些读者在查阅资料时会发现SiFive和NVIDIA都使用World ID(WID)来指代SID，这两者是截然不同的，SiFive的WID指代每个进程的权限ID，而NVIDIA的WID与上述的SID含义是完全一致的，都用于指代每个Master的权限ID。

2.3 Memory Domain (MD)

同理，根据RISC-V IOPMP Specification的描述，内存域(Memory Domain)指一组拥有特定功能的内存区域。以NIC为例子，其内部拥有三个内存区域(Region)，分别是发射队列、接受队列和控制寄存器堆，将这三个区域组合起来就可称为一个MD。如果需要定义某个Bus Master对网卡的操作权限，可以先将其SID与网卡的MD关联在一起，再制定SID在各个Region内的访问权限。

A memory domain, MD for short, is a concept inside an IOPMP. It is used to group a set of memory regions for a specific purpose and is indexed from zero.

Memory Domain的划分与TEE方案实现的SoC架构密切相关，例如DDR内存可以单独作为一个MD，也可以细分为多个MD，具体设定因平台而异。为加以区分，每个MD还需单独设有Memory Domain Identification(MDID或DID)标志。这里要注意，MDID编号越小代表其规则检查的优先级越高，因此建议为安全等级更高或者访问较为频繁的内存域分配数值较小的MDID号。

内存域的作用在于以MD为粒度实现规则表项的复用，通过将多个SID与指定MD关联，可以复用该MD内现有的检查规则，而无需为每个SID再额外单独设置检查规则。通过简单更改SID和MD的映射关系，还可帮助用户对Bus Master的访存权限进行批量化修改，提高软硬件协同的效率。

2.4 IOPMP Entry

IOPMP Entry是整个IOPMP的核心，其定义了Transaction检查的相关规则。熟悉PMP的读者应该知道，PMP在PMPCFG寄存器中定义了检查规则的锁定位(L)、地址匹配模式位(A)、执行权限位(X)、写权限位(W)和读权限位®，并在PMPADDR寄存器中定义了具有特定格式的物理地址信息。IOPMP Entry顺延了PMPCFG和PMPADDR寄存器的这种设计理念，其内部同样设有锁定位、读写执行权限、地址匹配模式和地址信息位，并针对特定优化方案进行了适当的扩展，例如静态IOPMP Entry技术等。

根据IOPMP Entry的地址匹配模式和地址信息，我们可以推断出一个Region的物理地址范围，而考虑到单个MD内部又存在多个Region，其自然会拥有多条IOPMP Entry。在事务检查过程中，需要根据其携带的SID确定MD，然后与MD内所有的表项进行比较，只有发现Transaction所访问的字节都在Entry规定的物理地址范围内，且访存类型符合Entry规定的读写执行权限，才将其认定为合法事务，否则按照非法事务进行处理(默认为黑名单机制)。需要注意的是，IOPMP Entry同样存在静态优先级的概念，表项索引值(Index)越低代表其优先级越高，这样当Transaction的访存范围与多条IOPMP Entry相匹配时，仅以优先级最高的IOPMP Entry检查结果为准。

三、IOPMP的结构框架介绍

阅读完前面章节的读者应该对IOPMP的整体功能有了较为抽象的认知，IOPMP是利用Bus Master的SID进行Transaction检查的，其内部定义了每个MD所对应的IOPMP Entry规则表项，而MD是在TEE方案设计中预先划分好的。那么本章节将会更细致地讲解IOPMP的组成结构以及规则检查流程，帮助读者具化IOPMP的硬件模型概念。

图3展示的是NVIDIA的IOPMP提议示例，可以发现其共有三个总线端口，其中一个Slave端口构成控制通路，专门用于检查规则的配置，通过读写寄存器或SRAM来修改内部的各类映射查找表和规则表；而另一组Master和Slave口构成数据通路，专门用于拦截Bus Master与Bus Slave间的Transaction，通过规则检查机制来规范外设的访存行为。当然这只是IOPMP端口设计方案的简单示例而已，只要确保IOPMP的端口数在三个即以上，就可以实现其在SoC系统平台的集成，读者在实现过程中可以适当将其扩展成为多Channel结构，但这意味着硬件资源的成倍增加，需要权衡考虑(具体设计可以参见[9])。

图4展示的则是Andes提议的IOPMP组织结构示例，其主要由三部分组成，分别是SRCMD Table、MDCFG Table和IOPMP Entry Array，下面将分别介绍这三个子模块的功能。

3.1 SRCMD Table

SRCMD Table由SRCMD寄存器堆组成，负责记录SID与MD的映射关系。IOPMP Spec定义的SRCMD寄存器位宽为64 bit，最高位为锁定位(SRCMD.L)，用于控制整个SRCMD寄存器的写权限，而剩余的63 bit(SRCMD.MD)以位图的形式来表示SID与MD的映射向量。若SRCMDx的第y位为“1”，则代表SID x在访问MDID y时需要通过MDID y内的全部检查规则。

3.2 MDCFG Table

MDCFG Table由MDCFG寄存器堆组成，负责记录MD对应的IOPMP Entry索引范围。IOPMP Spec定义的MDCFG寄存器位宽为32 bit，其低16位(MDCFG.T)用于表示与该MD相关的IOPMP Entry的Index上界，同时又表示与该MD编号相邻的下一个MD的IOPMP Entry地址下界，这种寻址方法被称为TOR(Top of Range)模式。若MDID为y，则其对应的IOPMP Entry地址范围为MDy-1CFG.T到MDyCFG.T，特殊地，MDID 0的下界为0。

3.3 IOPMP Entry Array

IOPMP Entry Array顾名思义，由IOPMP Entry组成，负责记录物理地址范围与相应的访问权限，用于Transaction的规则检查。由于IOPMP Entry的数量较多，推荐使用SRAM的方式来实现。

3.4 事务检查的基本流程

IOPMP的Transaction检查工作主要围绕上述三个表格展开，其具体流程描述如下：

• ① 数据通路的Slave端口接收到亟待检查的Transaction

• ② 解析Transaction中的SID号，查询SRCMD Table，得到MD映射向量

• ③ 根据位图记录的MDID查找MDCFG Table，得到MD对应的IOPMP Entry范围

• ④ 根据索引地址查找IOPMP Entry Table，进行地址范围匹配与访问权限比对

• ⑤ 重复步骤③和④来遍历所有与SID相关的MD，直到地址匹配成功或遍历结束

• ⑥ 根据检查结果进行相应的处理，若为合法事务则控制数据通路的Master端口进行事务转发；若为非法事务则Sink该事务或伪造结果，同时记录非法事务信息、响应总线错误信号或触发中断。

四、五种IOPMP的模型变体

IOPMP的基本结构主要由三类表格构成，其查表所消耗的延时直接处于关键路径当中，且为实现这些表格需要消耗相当大的硬件资源，因此在对性能和面积有更严格限制的应用领域，有必要对IOPMP模型进行适当的裁剪以满足指标要求，由此诞生了下述的五种IOPMP模型。

4.1 Full Model

全模型完整地实现了三个表格的全部功能，其事务规则检查延时最长且硬件开销最大，但可以灵活地管理数量众多的IOPMP检查规则表项，不同SID之间可以共享MD，不同MD对应的IOPMP Entry数量也可自由设定，因此适合应用于复杂的大型SoC系统。

4.2 Isolation Model

孤立模型对SRCMD Table进行了简化处理，SID将直接与MDID编号相同的MD形成映射关系，而不再采用全模型中多对多的映射方案，这意味着SID x仅能访问MDID为x的MD。该模型可以节省SRCMD Table的实现面积，减少事务规则检查的总延时。需要注意的是，SID与MD依次对应后，会失去MD的复用优势，若需要实现多个SID共享MD，只能额外设置相应的IOPMP Entry规则，但这部分开销显然小于SRCMD Table本身。

4.3 Rapid-K Model

快速-K模型对MDCFG Table进行了简化处理，每个MD对应的IOPMP Entry数量固定为K个，这里的K通常为2的指数形式，因此利用移位器就可以计算出每个MD对应的IOPMP Entry的索引地址范围，而无需查找MDCFG寄存器。IOPMP Spec在此处特意强调，为保持不同模型在语义上的一致性，Rapid-K模型仍然需要实现MDCFG Table，并设定相应的MDCFG.T位以帮助用户获悉IOPMP模块的配置信息，因此该模型可以减少事务规则检查的总延时。但笔者认为，在更定制化的TEE方案设计中，省去MDCFG Table来节省硬件面积开销或许也是个不错的选择。

4.4 Dynamic-K Model

与快速-K模型相比，动态-K模型唯一的区别在于其K值是动态可配置的，可以更灵活地分配IOPMP Entry表项，提高IOPMP Entry Array的空间利用率。同样为保持模型语义的一致性，MDCFG.T位需要反映出K值的变化，以帮助用户获悉IOPMP模块的配置信息，因此该模型可以减少事务规则检查的总延时。但笔者仍然认为，可以专门设置CFG寄存器来反映IOPMP的模型变化，从而省去MDCFG Table来节省硬件面积开销。

4.5 Compact-K Model

精简-K模型结合了孤立模型和快速-K模型的优势，对SRCMD Table和MDCFG Table都进行了简化处理，每个SID直接与固定数量的IOPMP Entry相对应，事务规则检查总延时短且硬件开销小，适合应用于对资源和成本有严格限制的应用场景。

五、IOPMP模块的拓扑组织结构

对IOPMP模块的功能和结构有了更清晰的认知后，我们可以试着将其集成到现有的SoC系统当中去。而得益于总线拓扑结构的规整性和高度可扩展性，IOPMP模块的集成方式也随之变得灵活化、多元化，因SoC系统的具体实现平台而异，但大体可将其分为下述的四种拓扑组织方式。

5.1 Source Enforcement

Source Enforcement方案指将IOPMP放置在总线和拥有Bus Master端口或DMA能力的主设备之间，即靠近Transaction发送方的一侧，除RISC-V核外的其余主设备均需要单独配备IOPMP单元，示例方案如图9所示。这种放置模式较为简单，仅需要为每个主设备配置与SID号个数相同的IOPMP单元即可，且由于IOPMP直接与Transaction的发送端口相连，其不再需要SID号来识别发送端口，可以省去内部的SRCMD Table和MDCFG Table，仅需要实现IOPMP Entry Array即可，提高了事务规则检查的速度，还显著降低了IOPMP的设计难度。

图9 IOPMP的Source Enforcement方案示例(摘自[9])

除此之外，该方案的另一个优势是所有主设备的事务可以进行分布式的并行检查，无需像后续提到的Destination Enforcement方案那样需要进行集中式地检查，可以减少因集成IOPMP单元而造成的系统性能损失。但该方案的致命缺陷在于每个位于源端的IOPMP不能在主设备之间共享，无法实现检查规则的复用，存在较为普遍的冗余现象。更为重要的是，虽然单个IOPMP的硬件开销有所下降，但当主设备数量过多时，需要实现的IOPMP单元数量会激增，使得TCO显著增加。

图10展示的是玄铁C系列处理器的VirtualZone安全解决方案，该示例采用了Source Enforcement的策略来集成IOPMP单元，其中GPU和XPU拥有各自的IOPMP单元，而两个具备DMA功能的加密设备通过共享IOPMP单元来降低实现成本。

5.2 Destination Enforcement

与Source Enforcement方案相反，Destination Enforcement方案将IOPMP放置在总线和拥有Bus Slave端口的从设备之间，即靠近Transaction接收方的一侧，示例方案如图11所示。由于从设备无法辨识Transaction的来源，需要为每个主设备额外添加特定的SID编号来加以区分。

该方案的优势在于事务检查工作更加中心化，方便用户集中管理IOPMP单元。通过合理划分SID和MD，还可以充分利用MD被不同SID共享的特性，提高IOPMP Entry的复用度，从而节约硬件开销。但正如前文所提到的，Destination Enforcement方案需要在目的地端进行集中式检查，若多个主设备并发访问从设备，会因为事务检查的串行化处理过程导致仲裁优先级最低的主设备被长时间阻塞，显著影响整个SoC系统的性能。

图12展示的是SiFive WorldGuard安全解决方案，虽然WorldGuard与IOPMP在实现方式上存在本质性的不同，但究其实现目的是一致的，所以也具有一定的参考价值。该示例采用了Destination Enforcement的策略来实现WG PMP与WG Filter单元的集成，在WorldGuard Specification的社区讨论中还可以惊奇地发现，SiFive一度摒弃了Source Enforcement的方案，选择采用客户更为喜欢的Destination Enforcement方案。

We have declined the IOPMP approach (i.e. putting filters at master side) because a lot of customers prefer the QoS approach of WG (checking transactions at slaves side). 摘自参考文献[14]

5.3 Cascading IOPMP

堆叠式IOPMP指SoC系统内存在IOPMP的级联，例如混合使用Source和Destination Enforcement方案、集成多个带有IOPMP单元的SoC子系统等都会产生这种现象。更特殊的来说，图11中PMP与IOPMP也存在级联现象，即RISC-V HART的事务经过PMP的规则检查后，会再次经过IOPMP的检查。如果该RISC-V核已经实现了Smepmp安全扩展，则其发送的事务经PMP检查后是安全可信的，第二次检查不免显得过于冗余，不仅事务请求的速度变慢了，整个SoC系统的性能也降低了。

同理，级联的IOPMP也可能存在检查的冗余问题，因此在Cascading IOPMP拓扑结构中，需要遵循Pass-One的检查原则，即确保每条事务在其请求路径上至多被检查一次。为此可以设置特定的旁路策略，比如首先规定所有IOPMP单元旁路SID为0的Transaction，然后规定IOPMP单元会将所有经检查后判定为合法事务的SID值修改为0，这样就可以实现上述的Pass-One原则。

堆叠式IOPMP方案的初衷是为解决单个IOPMP检查覆盖面不足的问题，回顾SRCMD Table的结构可以发现，Spec规定的MD数量最多为63个，如果SoC系统的MD数量超过了该阈值，则可以级联若干个IOPMP单元，除最后一级IOPMP则采用白名单检查机制外，其余前序IOPMP都采用黑名单检查机制，从而来覆盖所有MD的规则检查。而且在遵守Pass-One原则的前提下，该级联方案对关键路径延时的影响微乎其微。

5.4 IOMMU & IOPMP

IOMMU(Input/Output Memory Management Unit)是位于具备DMA功能的IO设备和系统内存之间的内存管理单元，主要负责DMA地址重映射和MSI中断重定向。在未开启虚拟化(Virtual Machine)的系统中，IOMMU允许操作系统使用虚拟地址IOVA(I/O Virtual Address)来控制DMA，从而将DMA读写区域与特权内存区域相隔离，防止恶意软件或故障的IO设备驱动利用DMA来篡改特权内存区域的数据。IOVA还允许设备访问大范围的连续虚拟地址空间，免受物理地址空间碎片化的影响，例如32位设备在IOMMU的辅助下能够访问64位的物理空间。而在开启虚拟化的系统中，IOMMU通过支持GPA(Guest Physical Address)到PA的单级地址翻译和从IOVA到GPA再到PA的二级地址翻译的功能，来帮助系统实现IO设备的透传，从而节省虚拟化技术实现的软件开销。

图13以IO Bridge为例，对IOMMU、PMA Checker(Physical Memory Attribute Checker)以及IOPMP的组织结构关系进行了解释说明。当IO设备发起访存请求后，IOMMU首先需要将其访问的虚拟地址翻译成物理地址，然后由IO Bridge进行总线协议转换并发起Transaction请求，接着PMA Checker负责对待访问物理地址的属性特征进行检查，而IOPMP则最后负责检查待访问物理地址的范围和权限是否符合设定的规则要求，并在检查通过后才正式将该访存请求发送给Bus Interconnect等待仲裁和结果返回。需要注意的是，IOMMU自身也会发送访存请求例如获取上下文信息、翻译规则和页表信息、访问请求队列等等，所以每个IOMMU也需要单独配置SID编号以供IOPMP进行访存的权限检查。

六、IOPMP的设计小指南

至此IOPMP的故事已经接近尾声了，相信读者对“什么是IOPMP？IOPMP和PMP的区别是什么？为什么TEE需要IOPMP？”这三个问题已经有了明确的答案，文章最后再分享一些关于IOPMP的设计思想，希望能对各位读者的思考有所启发。

6.1 IOPMP的性能优化技巧

• ① 全局检查规则表项(Global IOPMP Entry)：基于全局检查规则表项的事务检查是与常规的事务检查并行化展开的，如果事务在全局表项中匹配成功，则可以提前结束常规的检查流程，从而大幅度节省规则表项的查找时间，缩短访存路径的延时。

• ② 静态检查规则表项(Static IOPMP Entry)：部分外设的MMIO寄存器或Buffer等内存空间的物理地址以及相应的读写权限是相对固化的，使用静态检查规则表项不但可以节省可编程地址解码器的硬件开销，还可以减轻IOPMP驱动配置检查规则的任务负担，降低用户错误配置的概率。

• ③ 提高事务检查并行度：通过增加IOPMP的Channel通道数、MD的遍历并行度、IOPMP Entry比较器的数量等都可以提高事务检查的并行度，牺牲面积来换取性能的方案固然可行，但需要合理Trade-Off以找到设计最优点。

• ④ 投机执行：通过拦截总线响应通道的信号，IOPMP可以在接收到Transaction后，先推测性地将其转发给Bus Slave，并开启事务检查流程，当接收到响应数据且完成规则检查后，再根据检查结果来选择转发、伪造或丢弃响应信号。投机执行技术通过隐藏事务规则检查的时间，可以显著提高IOPMP的性能。

6.2 IOPMP的设计难点

• ① 原子性问题：IOPMP检查规则的修改可能涉及到多条Transaction，例如MD的创建和销毁操作会影响多个SRCMD寄存器和多条IOPMP Entry规则表项。而在检查规则修改的过程中，若IOPMP数据通路仍在进行事务规则的检查工作，则会遇到典型的TOCTOU(Time-of-Check Time-of-Use)问题，即此时检查应该按照旧的规则进行呢？还是按照新的但又未修改完成的规则进行呢？这或许会带来新的安全问题。

• ② 死锁问题：若采用阻塞IOPMP数据通路的方式来解决原子性问题，则会导致负责所有IOPMP控制通路事务检查工作的IOPMP发生自锁现象；若额外增加控制寄存器，仅选择Stall住那些与规则改动相关的SID，则Bus Master在规则配置时会因涉及到修改与自身存在映射关系的MD，而再次进入死锁状态。

• ③ 其他问题：如何开启IOPMP、重置IOPMP、动态切换其工作状态？IOPMP又该在何时响应这些控制信号？如何拦截Bus Master的请求信号和Bus Slave的响应信号？如何利用死锁机制保护规则表项的安全？这些问题都值得读者在设计过程中去深入思考。

七、总结

RISC-V IOPMP Specification的制定任务还在如火如荼地进行当中，IOPMP Task Group计划将在今年的第三季度完成Spec设计并冻结相关方案。但学术界和工业界对IOPMP的设计探索其实很早就开始了，赛昉科技在[9]中实现了Rapid-1类型的IOPMP模型，详细描述了修改检查规则时遇到的原子性操作问题，并在理论上分析了IOPMP导致的SoC系统性能损失情况；阿里云在[12]中提出了玄铁RISC-V处理器的VirtualZone安全解决方案，并列举了三种IOPMP模块的组织方式；广东工业大学在[16]中实现了Rapid-K类型的IOPMP模型，并基于玄铁E902处理器搭建了轻量级的DITES安全解决方案原型；SiFive的WorldGuard方案虽然与IOPMP方案背道而驰，但也持续为RISC-V TEE方案的推进贡献着智慧。相信在企业和各界翘楚的引领下，RISC-V TEE安全解决方案将逐步完善并落地，为RISC-V处理器核和整个SoC芯片系统保驾护航！

八、参考文献

声明：本文所引用的图片与部分设计理念均来自公开的文献资料，且已标明相关出处，如有任何侵权行为请联系本专栏管理员或作者本人。

【1】《浅析安全启动 (Secure Boot)》https://bbs.kanxue.com/thread-260399.htm

【2】“The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Document Version 20211203”, Editors Andrew Waterman, Krste Asanovi´c, and John Hauser, RISC-V International, December 2021.

【3】《RISC-V SPMP Specification》 https://github.com/riscv/riscv-spmp/blob/main/rv-spmp-spec.pdf

【4】《RISC-V Smepmp Specification》 https://github.com/riscv/riscv-tee/blob/main/Smepmp/Smepmp.pdf

【5】《Andes Building a Secure Platform with the Enhanced IOPMP》 https://www.slideshare.net/RISC-VFoundation1/andes-building-a-secure-platform-with-the-enhanced-iopmp

【6】《AMBA AXI and ACE Protocol Specification》 https://developer.arm.com/documentation/ihi0022/hc/?lang=en

【7】《RISC-V IOPMP specification》 https://github.com/riscv-admin/iopmp/blob/main/specification/riscv_iopmp_specification.pdf

【8】《IOPMP proposal 0.5.1》 https://lists.riscv.org/g/tech-tee/topic/file_iopmp_proposal_0p5_pptx/80135860

【9】Ng J H, Ang C H, Law H C. A Realization of IO Physical Memory Protection for RISC-V Systems[C]//2022 IEEE 15th International Symposium on Embedded Multicore/Many-core Systems-on-Chip (MCSoC). IEEE, 2022: 375-380.

【10】《What in RISC-V IOPMP》 https://riscvsecurityforum2021.sched.com/event/iWe4/lightning-talk-what-in-risc-v-iopmp-shan-chyun-ku-andes-technology

【11】《IOPMP models》 https://lists.riscv.org/g/tech-tee/topic/iopmp_models/87723547

【12】《XuanTie VirtualZone: RISC-V-based Security Extensions》 https://riscv.org/blog/2022/04/xuantie-virtualzone-risc-v-based-security-extensions-xuan-jian-alibaba/

【13】https://www.sifive.com/technology/shield-soc-security

【14】https://lists.riscv.org/g/tech-tee/message/312

【15】《RISC-V IOMMU specification》 https://github.com/riscv-non-isa/riscv-iommu/blob/main/riscv-iommu.pdf

【16】Chen Y, Chen H, Chen S, et al. DITES: A Lightweight and Flexible Dual-Core Isolated Trusted Execution SoC Based on RISC-V[J]. Sensors, 2022, 22(16): 5981.

内容来自

浅析RISC-V TEE的SoC级安全模块——IOPMP

更多的关于RiscV的内容，看Mr.Tuzik的专栏文章，干货很干！！！