M-CRPS服务器安全驱动与升级：X-Cube-SBSFU 使用技巧（之二）——与应用集成

1. 引言

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

    为了方便客户在其嵌入式设备的设计中更加容易地集成安全启动和安全更新功能，STM32 提供了相关的参考实现并支持众多STM32 MCU 系列。其中X-CUBE-SBSFU 是针对Cortex V6/V7M 内核的STM32 MCU 产品的参考方案，软件包下载地址：https://www.st.com/x-cube-sbsfu。
    在X-CUBE-SBSFU 使用技巧的第一篇，我们对软件包及其软件架构等进行了介绍，读者对这个软件包有了初步认识。在这一篇我们将介绍SBSFU 和用户应用程序集成相关的内容。

2. 应用程序链接文件

2.1. Flash
    通常一个不带有安全启动或者bootloader 的应用程序会以内部Flash 的基地址作为该应用程序对应vector table 的起始地址，并可以运行于整个内部Flash 空间。当在应用中集成SBSFU 参考实现的时候，需要调整应用程序在Flash 中的占位。
    在X-CUBE-SBSFU 使用技巧的第一篇中我们介绍了以X-CUBE-SBSFU 为框架的安全启动方案的存储器地址空间布局，单镜像模式、双镜像模式、内部+外部Flash 模式等等，可能会有不尽相同的空间布局。但是对于应用程序来说，只需要关注其中的ActiveSlot 部分，应用程序在Flash 中的放置位置由Memory Map 中的Active Slot 区域决定，如图1 所示。

    Active Slot的地址在SBSFU参考实现的Linker_Common目录下的mapping_fwimg.x文件中有定义。那么修改应用Linker file的方式有两种，一种方式是根据mapping_fw.x中的Active slot定义直接在应用程序中hard code相关地址。另一种是在应用的Linker file中引用mapping_fw.x文件，并使用其中的定义来指定vector table、ROM区域的起止地址等，这种方式的好处是，应用程序与SBSFU引用相同的linker 定义文件，当需要做地址空间调整的时候只需要统一修改，以避免地址定义不一致的问题。

2.2. SRAM

    通常情况下，安全启动只在运行期间使用SRAM，跳转到应用程序之后，SRAM会被释放给应用程序使用，因此应用程序可以使用所有的SRAM空间。但是在某些平台的SBSFU参考实现中，部分SRAM会保留给安全启动代码使用，主要涉及带有Firewall硬件的L4/L0系列，以及SBSFU中包含KMS功能，启动后SecureEngine依旧可能给应用程序提供密钥管理服务的情况。这时候应用程序的linker file中指定 的SRAM的空间应该从SE_region_RAM_end地址之后开始，如图2所示：

3. 固件升级功能的集成

    如果用户选择了双镜像模式集成X-Cube-SBSFU中实现的安全启动和安全更新方案，那么应用程序可以根据其自身需要实现带安全启动的固件升级。新版本固件的下载过程可以在应用程序中完成，而完整的升级过程还需要SecureBoot代码的参与，因为对新版本应用程序固件的校验、解密等操作都在SecureBoot代码中完成。升级大致过程如图3所示。

    这里有两点需要注意，一个是从应用下载新版本时，下载内容放置的位置，另一个是升级后新版本固件可能需要额外操作使自己生效。

4. 小结

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

    本文总结了一些有关如何将SBSFU参考实现与客户自己的应用程序进行集成的技巧和注意事项，包括Flash和RAM的布局，应用链接文件的修改，如何生成用户自己的密钥，如何使用脚本工具对应用固件进行加密、签名和打包处理，如何在应用程序中集成固件升级以及其它一些注意事项等 。

    在使用技巧的第三篇，我们将继续讨论有关X-CUBE-SBSFU从一个STM32硬件平台移植到另一个STM32硬件平台的话题。