M-CRPS服务器安全启动与升级：X-Cube-SBSFU 使用技巧（之三）——移植到另一个STM32 硬件平台

1. 引言

    安全启动与安全更新是嵌入式设备的基本安全要求之一：安全启动提供信任根，保证每次设备启动运行的应用程序的完整性与合法性；安全更新则在固件升级环节避免系统软件被恶意修改或替换。

    为了方便客户在其嵌入式设备的设计中更加容易地集成安全启动和安全更新功能，STM32 提供了安全启动与安全更新的参考实现，支持众多STM32 MCU 系列。其中XCUBE-SBSFU 是针对Cortex V6/V7M 内核的STM32 MCU 产品的参考方案，软件包下载地址：https://www.st.com/x-cube-sbsfu。

    在X-CUBE-SBSFU 使用技巧的第一篇，我们对软件包及其软件架构等进行了介绍，让读者对这个软件包有了初步认识；第二篇重点介绍了如何将SBSFU 与应用程序集成，实现安全启动和安全升级的话题；在这一篇我们将讨论如何将SBSFU 参考实现从一个STM32 MCU 平台移植到另外一个STM32 MCU 型号的硬件平台。

2. 参考实现的选择

    X-CUBE-SBSFU 的参考实现通常基于STM32 现有的ST 官方开发板，例如Nucleo 开发板、Discovery 探索套件板，这些开发板上的STM32 MCU 型号是事先确定的，而用户在他们实际的项目中很可能并非使用相同的STM32 MCU 型号，这时候就需要对XCUBE-SBSFU 的参考实现做硬件平台的移植。移植通常基于一个已有的参考实现，因而移植前的第一步就是选择最合适的参考实现。

    参考实现的选择需要考虑几个方面：首先是STM32 MCU 系列，其次是所需要的功能和配置，最后就是根据需求找到最接近的STM32 MCU 型号的参考实现。功能和配置的需求可能涉及多个方面，例如

• Flash 布局
o 单镜像还是双镜像方案
o 是否需要使用外部Flash 等
• Crypto 方案
o 是否需要加密
o 是否使用X509 数字证书
o 是否需要STSAFE 等
• Crypto 实现选择
o 使用STM32 Cryptolib 还是开源的mbedtls/mbedcrypto
• 是否需要KMS密钥管理服务

    确定了需求之后，找到同一STM32系列所有满足需求的参考工程，Projects目录下的STM32SBSFUProjectsList.html文件列出了不同开发的参考实现支持的配置组合，例如表1所示。

3. 底层硬件配置的相关修改

    SBSFU参考实现涉及到的底层硬件主要包括串口，FLASH，用户按键GPIO，DAP调试端口GPIO，Tamper GPIO，STSAFE接口等等。

3.1. 串口

    UART主要用于串口打印和基于YModem协议的通信。需要根据目标STM32 MCU及其硬件板的串口定义修改对应的UART外设及其GPIO管脚配置。SBSFU中的相关定义在sfu_low_level.h文件中，例如

3.2. FLASH

    安全启动和固件更新的过程中需要对Flash进行读写操作，因此底层驱动的一个重要部分就是Flash驱动。如果Flash有变化，那么这部分驱动的修改在SBSFU和SECoreBin，UserApp几个工程中都需要。

    通常我们尽量选择Flash类型相同或相近的芯片平台的参考实现，例如目标MCU的Flash是基于page的，那么也选择基于page的芯片的参考实现；如果目标MCU的Flash是基于sector的，那也选择基于sector的芯片的参考实现；目标MCU的Flash是双bank的，那么也选择基于双bank的芯片的参考实现。

    Flash驱动在SBSFU工程中涉及三个源文件：
• sfu_low_level_flash.c：底层的Flash初始化、读、写、擦除、配置等。
• sfu_low_level_flash_int.c：SBSFU使用内部flash的驱动接口，如果page/sector或者bank模式不同，可能需要查看这个部分是否需要修改。
• sfu_low_level_flash_ext.c：主要针对外部Flash的操作，如果使用外部Flash，那么可能需要重新适配这个部分。

    SECoreBin工程同样会用到Flash驱动做读写等操作，主要在se_low_level.c文件中，类似sfu_low_level_flash.c中的实现也需要复制到这个文件中。

    UserApp最终会被实际的用户应用程序替代，所以并不是一定需要移植，但是在前期SBSFU还没有和应用集成又希望先验证SBSFU移植的时候，可以考虑将UserApp也做移植，由于涉及的硬件不多，这个移植也不会很复杂。UserApp的Flash驱动在flash_if.c中，类似SBSFU工程中的Flash驱动修改也需要体现在这个文件中。

    X-Cube-SBSFU参考实现中的内部Flash操作是基于HAL Driver实现的，所以一般来说，如果Flash的类型相同，通常是不需要做特别的修改的。如果真的进行了跨STM32系列的移植，那么需要特别关注Flash操作的几个方面，例如基于sector还是page的操作，单bank还是双bank，调用HAL_FLASH_Program写操作时每次写的大小等等。

4. Memory布局的调整

    X-CUBE-SBSFU在每一个参考工程的实现中都有缺省的memory map的定义（例如图1所示），不同平台上SecureBoot区占用的空间也不尽相同。

    如果目标MCU与参考实现使用的MCU的Flash、RAM大小不一致，则需要对memory布局做调整。通常如果目标MCU的存储空间更大，那么即使不做调整，移植后的SBSFU应该也可以直接运行，只需要后期与应用集成的时候另外调整Active Slot、Download Slot和Swap Slot几个区的位置及大小即可。如果目标MCU的memory相较参考平台MCU的memory要小，则必须对缺省的memory布局定义做调整。

    对于SRAM主要是大小定义的修改，SBSFU使用的SRAM通常不会很大，而且多数情况后期会释放给应用使用，一般不需要其他特别的调整。

    内部Flash布局的调整可能涉及两方面：应用占用空间的修改和SecureBoot占用空间的修改。

5. 小结

    X-CUBE-SBSFU是基于STM32 MCU的安全启动和安全更新的参考实现，支持众多STM32系列。 X-CUBE-SBSFU参考实现包含完整的参考代码以及配套的工具，并以源码形式提供给客户，具备非常大的灵活性。用户既可以直接使用该软件包与应用程序进行集成，为其系统快速添加安全启动和安全更新功能；也可以仅以此作为参考，重新编写自己的安全启动和安全更新实现。

    本文着重介绍了如何将SBSFU参考实现从一个STM32硬件平台移植到另一个STM32硬件平台的内容，包括底层硬件驱动和存储空间布局的修改，以及算法库版本的切换等。