使用Cortex-M内存保护单元来提高MCU安全性的方法

这是由四部分组成的系列文章的第一部分，介绍了独特的产品 MPU-Plus® 以及使用 Cortex-M 内存保护单元 （MPU） 实现改进的微控制器单元 （MCU） 安全性的方法。

模压传感器与模压单元

几十年来，大型操作系统在具有MMU的微处理器上使用隔离过程来实现分离和系统安全性。我们最近增强的产品 MPU-Plus 使用带有 MPU 的微控制器为 SMX 实时操作系统添加了类似的功能。这已经为Cortex-M架构完成了，并将在将来扩展到其他架构。

内存管理单元 （MMU） 与完整操作系统 （OS） 一起使用，为进程提供隔离的虚拟内存。进程是独立编译和链接的，然后由操作系统（如 Windows 和 Linux）单独加载和运行。进程到进程的隔离已经足够好了，如果一个进程被恶意软件感染或由于任何其他原因开始出现故障，操作系统通常可以将其关闭，而对其他进程几乎没有损害。因此，安全性很好。MMU的使用是经过充分研究和充分理解的。MMU使用的缺点是它通常需要高性能处理器和非常大的内存。

快速、耗电的处理器和巨大的内存与大多数嵌入式系统的要求不兼容。此外，完整的操作系统没有许多应用程序所需的实时响应时间。因此，大多数嵌入式系统使用低功耗、中等性能的微控制器单元 （MCU） 和实时操作系统 （RETOS）。与完整的操作系统系统相比，这些系统通常具有较小的内存。出于安全考虑，许多 MCU 提供内存保护单元 （MPU），这些单元无法像 MMU 那样创建虚拟地址空间。

在大多数嵌入式系统中，我们处理的是分区而不是进程。这个想法基本上是相同的 - 分区包括一个或多个任务，并为系统执行特定功能。就像进程一样，希望将分区彼此隔离，以便在一个分区被穿透或开始出现故障时，可以停止它，同时对系统其余部分的损害最小。不幸的是，这在使用 MPU 的嵌入式系统中并不像在使用 MMU 的完整操作系统系统中那样容易实现。这里最大的挑战是所有MCU软件都被编译并链接到一个可执行文件中。此外，MPU 还施加了自己的限制。MPU的安全性使用没有得到很好的研究，也没有得到充分的了解，并且涉及许多复杂的权衡，特别是因为嵌入式系统通常具有较小的存储器，中等性能的处理器，功率限制以及对确定性实时性能的需求。

对安全性的需求日益增加

如果它如此困难，为什么要打扰呢？这似乎是嵌入式系统行业在过去几十年中采用的方法。不幸的是，这还不够长，因为嵌入式系统正在快速连接到物联网（IoT）中。因此，一旦被隔离，无防御的嵌入式系统就可以通过黑客高速公路（又名互联网）进行访问。这意味着麻烦。

保护目标

保护的主要目标是保护受信任的关键软件和数据免受不太受信任的非关键软件的侵害，这些软件可能会感染恶意软件或有缺陷。受信任软件的示例包括 RTOS、异常处理程序、安全软件（例如加密、身份验证、安全启动、安全更新等）和任务关键型软件。不太受信任的软件的示例是易受恶意软件攻击的代码，例如协议堆栈、设备驱动程序、SOUP 和未充分测试的代码。

第二个目标是检测入侵和错误并关闭它们，以便关键系统操作不会受到威胁，敏感数据也不会被盗。处理入侵和错误可以通过停止和重新启动渗透的任务来处理，或者可能需要停止并重新启动整个系统。

第三个目标是最大限度地减少受信任的代码量，因为仔细编写少量代码更容易。在非特权模式下运行更多代码可增加分区隔离，从而提高可靠性。

必须实施的保护程度取决于特定系统的安全和安全要求及其面临的威胁。MPU-Plus 提供一系列安全服务，可实现适合给定系统的保护级别。此外，随着系统分布范围越来越广，因此更容易受到攻击，在将来的版本中可以增加保护。MPU-Plus旨在促进逐步的保护改进。

超强快照

MPU-Plus的主要目的是增强基于SMX®实时操作系统的多任务系统的安全性。MPU-Plus 为帮助实现更好的安全性所做的主要工作是：

允许为每个任务定义不同的MPU模板;

在任务切换期间处理MPU切换;

提供 SVC API 以允许非特权代码调用特权服务;

限制哪些服务可以从非特权代码调用以及它们可以做什么;

允许分配受保护的块和消息;

在特权模式下运行SMX RTOS和系统代码，在非特权模式下运行中间件和应用程序代码;

允许任务具有特权或非特权。

作为构建安全性的平台。

MPU-Plus 有两个主要设计目标：

更轻松地转换旧代码以使用 MPU 和 SVC API。

允许开发人员专注于保护策略，而不会被 MPU 特性和其他硬件细节所困扰。

实施良好的保护策略已经够困难的了。细节层面的过度复杂化不仅令人沮丧，还可能导致采用不太理想的系统保护。

Cortex-v7M

Cortex-v7M 处理器架构于 2005 年推出，适用于中型嵌入式系统。从那时起，半导体行业开发了数千种不同的Cortex-v7M微控制器单元（MCU）。它们用于设备制造商开发的数以万计的产品中;迄今为止，已经出货了数十亿个芯片。它是迄今为止占主导地位的MCU架构（70%的市场份额），因此也是我们支持的架构。

Cortex-v7M体系结构提供以下安全功能：

特权模式。

主管呼叫 （SVC） 指令。

内存保护单元。

第一种是通过三种处理器操作模式实现的：

处理程序模式：ISR、错误处理程序、SVC 处理程序和 PendSV 处理程序的特权模式。只能通过中断或异常进入此模式。

特权线程模式：特权任务在此模式下运行。它只能通过设置 CONTROL.nPRIV = 0 从处理程序模式输入。

非特权线程模式：非特权任务在此模式下运行。可以通过设置 CONTROL.nPRIV = 1 从上述两种模式中的任何一种模式输入它。

为了减少接下来讨论中的冗长，我们使用以下缩写术语：前两种模式统称为pmode，第三种模式称为umode。p 前缀可以解释为特权或受保护;u 前缀可以解释为非特权或用户。在 pmode 中运行的代码和任务称为 p 代码和 ptask;在 umode 中运行的代码和任务称为 ucode 和 utasks

Cortex-M架构的关键方面是，只能通过中断或异常输入 pmode。SVC N 指令会导致此类异常。它可以从带有 8 位参数 N 的 umode 执行。这允许从 umode 进行系统调用，其中 N 指定要调用的函数。被调用的函数在 pmode 中执行。SVC 也可以从模数执行。

MPU 为 M 区域提供 M 插槽。每个区域都有起始地址、大小和访问参数，例如只读 （RO）、读/写 （RW）、从不读取 （XN） 等。如果 MPU 中的至少一个区域不允许内存访问，则会生成内存管理故障 （MMF）。MMF 是导致 MMF 处理程序运行的异常，该处理程序通常会停止有问题的任务并确定要执行的操作以进行恢复。

图 1 显示了一个只有 4 个插槽的示例 MPU。（大多数 MPU 有 8 个插槽，有些有 16 个插槽。存储在 MPU［0］ 中的区域是任务代码的 RO 区域。MPU［1］ 区域是代码的 RO 区域，与其他任务通用。存储在 MPU［2］ 中的区域是用于数据的 RW 和 XN 区域。最后一个区域是任务堆栈，也是 RW 和 XN。下面显示了可选的任务本地存储 （TLS），它可以是任务堆栈区域的一部分，可用于本地任务数据。由于仅提供了指向 TLS 的指针，因此数据必须是结构或数组。它具有与任务堆栈相同的属性。此任务无法访问内存的白色区域。

v7 MPU 的一个严重缺点是区域大小必须是 2 的幂，并且区域必须在其大小边界上对齐。这一要求可能是v7 MPU使用率低的主要原因，但可以克服。实际上，MPU的最大缺点是插槽不足。几乎所有的 Cortex-M 处理器都有带有八个插槽的 MPU。当一个人开始为实际分区创建区域时，八个是不够的 - 12个可能刚刚好。一些处理器有16个插槽;强烈建议将这些用于新设计。我们同时支持 8 个和 16 个插槽 MPU，但我们的重点是前者，因为它们是迄今为止最常见的。

尽管 Cortex-v7M MPU 具有显著的局限性，使其难以使用，但它是 Cortex-v7M 处理器可用的硬件内存保护的唯一手段，硬件保护是唯一有效防止黑客攻击的保护措施。因此，重要的是要找到有效使用它的方法，以实现现代嵌入式系统所需的可靠性，安全性和安全性。

Cortex-v8M

Cortex-v8M 架构是在几年前宣布的。迄今为止，使用它的处理器很少。v8 MPU 将区域大小和对齐要求大大降低到 32 字节的倍数。这对于内存有限的嵌入式系统很有帮助。但是，MPU 插槽的数量在 v8 体系结构中保持不变。希望半导体供应商能够选择16个而不是8个插槽，至少在非安全状态下是这样。我们将很快支持 v8 MPU。

Cortex-v8M 体系结构还提供了一个名为 TrustZone 的新功能，该功能允许安全和非安全状态。信任区安全状态适用于密钥和其他私有数据的存储。但是，在安全状态下运行代码可能不值得额外的代码复杂性和调试难度。阿姆说不然，所以我们得看看。此外，我们预计大多数设备制造商都需要一个同时适用于 v7 和 v8 处理器的安全解决方案。

审核编辑：郭婷