【STM32应用笔记】移植 SBSFU 到 STM32G070 的过程
【STM32应用笔记】移植 SBSFU 到 STM32G070 的过程目录预览1、前言2、基于STM32G070和STM32G071的SBSFU 实现差异3、开始移植4、测试安全保护特性5、后述
01前言
客户使用 STM32G070RBT6 给海外用户开发产品，由于当地新需求，产品需要增加安全启动的功能。但是由于 X-Cube-SBSFU 包提供的示例中，只有基于 STM32G071 的示例。客户因此询问该怎么移植。本文将讲解这个移植过程。
02基于STM32G070和STM32G071的SBSFU 实现差异
在正式讲解之前，我们首先来看一看 STM32G070 和 STM32G071 的 SBSFU 实现差异。
STM32G070 是一个 value line 产品，首先，我们要意识到，有一些安全特性，相比于STM32G071，它是没有的，比如：PCROP，BOOT_LOCK 和 Secure User Memory。那么，缺少了这些安全特性的 STM32G070，是否还能实现安全启动的功能呢 ? 答案是肯定的。我们先来看 PCROP，BOOT_LOCK，以及 Secure User Memory 在 STM32G071 上的 SBSFU 实现中所扮演的角色是什么?
图1.STM32G0 的 SBSFU 安全实现
如上图，在 STM32G071 中，在安全启动的实现中，BOOT_LOCK 用来参与实现唯一启动入口，Secure User Memory 则用来参与实现信任根。PCROP 在安全固件升级实现中用来与MPU 配合实现密钥的安全存储，同时在安全升级过程中涉及到一些密钥的加解密操作，借助于Secure User Memory 和 MPU 的功能， 将 App 与 SBSFU 本身实现完美隔离。
图2.STM32G0 内存安全映射(运行 SBSFU 时)
回到当前问题，一旦 BOOT_LOCK，PCROP，以及 Secure User Memory 缺少的情况下，这些功能还能实现吗?
我们再来看下对于安全启动而言， 它需要实现哪些基本功能? 1> 不可更改不可绕过的一段启动代码 2> 每次复位必先执行安全启动代码 3> 验证系统配置的完整性 • 时钟配置 • 寄存器配置 • 存储器保护设置， …. 4> 启动信任根服务 • 通过密码学算法与密钥，校验 App 的完整性与合法性（来源可信，未经篡改）
这里需要注意地是，上面提到的某一项安全属性也只是参与实现某一项功能，比如BOOT_LOCK，它只是”参与”实现了唯一启动入口这个功能。从图 1 可知， 除了BOOT_LOCK，还有 RDP，那么在缺少 BOOT_LOCK 的情况下，RDP 是否也可以实现唯一入口启动的功能。很明显，在 RDP2 时，MCU 的入口是唯一的。也就是说，没有 BOOT_LOCK的参与下，RDP2 一样可以实现安全启动对唯一入口启动的需求。RDP2+WRP 就可以实现安全启动的前两条基本要求。而第三条基本要求，完全是 SBSFU 内的纯软件实现。第四条要求，通过 RDP2+WRP+MPU 也可以实现。其实， 在缺少了 PCROP，BOOT_LOCK 和Secure User Memory 后，STM32G070 的安全特性其实跟 STM32F4 差不多，我们不妨来看下STM32F4 是如何来实现 SBSFU 功能的。
图3.STM32F4 的 SBSFU 安全实现
如上图所示，在 STM32F4 中，借助于 RDPL2，WRP，MPU 就实现了 SBSFU 的全部功能。
图4.STM32F4 的 SBSFU 内存映射
到这里，我们完全可以确信，在缺少了 BOOT_LOCK，PCROP 和 Secure User Memory这些安全特性之后，STM32G070 完全可以按照 STM32F4 实现 SBSFU 的方式来进行!
在确立了大方向后， 我们接下来看具体如何实现。
03开始移植
第一步 : 确保原始工程运行正常 从 ST 官网上下载最新了 SBSFU 包(v2.6.1)，打开STM32CubeExpansion_SBSFU_V2.6.1\Projects\NUCLEO-G071RB\Applications\2_Images目录，其下有三个工程，2_Images_SECoreBin(后续简称 SECoreBin 工程)，2_Images_SBSFU(后续简称 SBSFU 工程)，2_Images_UserApp(后续简称 UserApp 工程)。使用对应 IDE 按顺序依次编译， 然后将 SBSFU 工程生成的 bin 文件烧录到 NUCLEO-G071RB板内，打开 Tera Term 串口终端， 通过 Tera Term 烧录 APP 进去。目的是首先确认原始工程一切运行正常。接下来就开始修改了。
第二步 : 将与 BOOT_LOCK， PCROP， Secure User Memory 相关的宏全部关闭 打开 SBSFU 工程的 app_sfu.h 头文件，找到并关闭下面三个宏 :
重新依次编译 SBCoreBin，SBSFU，UserApp 三个工程，并重新测试通过。
至此， NUCLEO-G071RB 板上运行的是移除了 BOOT_LOCK， PCROP，Secure User Memory 三个安全特性后的 SBSFU 程序，这个原理上与 STM32G070 上原则上是一致的。接下来就是要移植到 NUCLEO-G070RB 板上了，剩下的就只有 STM32G070 与 STM32G071 的非安全特性方面的差异了。
第三步 : 移植到 STM32G070RB 首先得准备下一块 NUCLEO-G070RB 板。接着将三个工程 SBCoreBin，SBSFU，UserApp 的 device 修改成目标 MCU STM32G070RB，然后将三个工程的 C++预定义宏STM32G071xx 修改成 STM32G070xx。
以 Keil 为例 :
图5.device 选择 STM32G070RBTx
图6.C++编译宏修改
STM32CubeIDE 工程的 device 配置比较难修改，因为它原本是灰色的，不允许修改。但我们使用 UE 打开.cproject 一样可以强制修改 :
打开对应的.cproject 文件，搜索关键字 G071，将以下几处替换成 G070(修改两处) :
图7.STM32CubeIDE 下的 device 修改
修改完后，打开 STM32CubeIDE 工程，在其 MCU 和 Board 的配置也会有相应的变化:
图8.STM32CubeIDE 的 MCU 配置
由此可见，在 STM32CubeIDE 工程的 MCU 配置也可以做相应的修改了。这是一个小技巧。
至此，三个工程的工程配置都做完了相应修改。接下来的就是代码方面的修改了。
首先 STM32G070 的时钟树是没有 PLLQ 输出的，因此，在 SBSFU 和 UserApp 这两个工程内找到 SystemClock_Config()函数，注释掉 PLLQ 的设置，如下所示 ：
原先 STM32G071 的工程中的打印信息是通过 LPUART1 对应的 PA2，PA3 打印的，换成NUCLEO-G070RB 板后，其引脚虽仍然是 PA2，PA3 引脚用来串口打印，但是 STM32G070中是没有 LPUART1 这个外设的，需要换成 USART2，因此，其对应的代码修改如下 :
在 SBSFU 工程中， 打开 sfu_low_level.h 头文件 ， 和 UserApp 工程的 com.h 头文件中:
如上红色部分即为修改处。
至此，代码部分全部修改完成。重新按顺序依次编译 SBCoreBin，SBSFU，UserApp 三个工程，将 SBSFU 工程首先烧录到 NUCLEO-G070RB 板，然后通过串口终端，按提示，用 YModern 协议将 UserApp 对应的.sfu 文件烧录进去。整个流程都可以正常运行的。这说明软件框架基本已经 OK。接下来运行下 APP 中各种安全测试。
04测试安全保护特性
当程序跳入到 APP 后，显示如下界面
图9.测试主界面
当选择 2 Test Protection :Secure User Memory 时，结果会出错 :
图10.测试保护
很明显，这里需要修改下，因为 STM32G070 是没有 Secure User Memory 的。查看其对应代码：
原来 UserApp 是测试直接读取保存在 SECoreBin 内的密钥数据， 测试是否能读出。结果发现是可以的，因此，保护效果是出问题了。
首先我们修改下此函数，由于 STM32G070 中 Secure User Memory 是不存在的， 此函数叫 TEST_PROTECTIONS_RunSecUserMem_CODE()已经不再合适， 依照 STM32F4 的SBSFU 实现，将此函数换成 TEST_PROTECTIONS_RunSE_CODE()函数:
同样的尝试读取密钥：
图11.UserApp 尝试读取密钥
测试结果可想而知， 肯定是可以读取的。于是得查看下为什么可以。
仔细查看图 2 的 STM32G071 的 SBSFU 原来实现中，SE Key 是通过 PCROP+Secure User Memory 来保护的，现在换成 STM32G070，原本 Secure User Memory 用来作隔离机制， 现在换成了 MPU， 而原本保护 SE Key 的 PCROP 在 G070 中压根就不存在，于是 SE Key 只剩下 MPU 来保护，因此，我们接下来得着重分析 MPU 对 SE Key 的保护。
为了方便调试，我们首先得将除 MPU 以外的所有保护通通关闭，只剩下 MPU 保护。于是在 SBSFU 工程中，在 app_sfu.h 头文件中，将以下宏通通注释掉:
然后开始调试。在调试过程中，发现程序在从 SBSFU 跳转到 UserApp 之前，在代码中特意将 MPU 关闭：
如在 sfu_low_level_security.c 源文件中的内存函数 SFU_LL_SECU_ActivateSecUser()中有这么一行代码：
这就是为什么 UserApp 中仍然可以直接读取密钥的原因了。很明显，接下来我们需要将 SEKey 用 MPU 保护起来。但在这之前，我们得首先弄清楚，当程序跳转到 UserApp 后，Flash 和Ram 该如何设置 MPU 保护?
在 UM2262 中， 有提到当程序跳转到 UserApp 后 flash 和 RAM 的状态：
图12.UserApp 运行时的 flash 和 RAM 状态
从上图可以看出，原本 Secure User Memory 保护的区域，我们得使用 MPU 来替代实现相应功能，包含 SBSFU 整个代码和 Slot#1 内的 header 信息。这也就是在代码跳转到 UserApp之前需要做的事情。而黄色对应的 SRAM 区别已经擦除，当程序跳转到 UserApp 后其实已经没必要再保护。
于是在跳转到 UserApp 的内存函数中配置 MPU：
注意这里是一个内存函数，它所调用的所有子函数也都是内存函数。在这个函数中我们将SBSFU 所在的 64K Flash，再加上 2K 的 Active Slot 的 header 信息保护起来。内存 RAM 我们并没有配置保护，因为跳转到 UserApp 后它就完全开放，且内容已经清空。
对应的， 我们在 UserApp 中增加对 Header 的测试函数 ：
重新烧录程序，当程序运行后，选择 2 进行 protection 测试，然后再选择 2，测试访问SBSFU 所有的 64K 区域：
图13.测试 SBSFU 的 64K 代码区
发现会一直卡住， 这说明 MPU 对整个 SBSFU 64K 区域的保护已经生效。同样的，选择’3’测试 header 所在区域：
图14.测试 Header 对应的 2K 区域
发现程序读取 0x0801 0000 地址时会一直卡住，这说明 MPU 对 header 的保护也已经生效。然后再测试了下其它选项，包含下载新固件，还有其它默认的一些安全特性，基本都是OK 的。这说明整个程序基本已经 OK。
最后再恢复之前注释掉的除 MPU 之后的保护。
05后述
本文旨在通过一个相对容易的移植， 让读者对 SBSFU 的移植过程有一个大概了解以起到参考和示范作用。
页:
[1]