客戶使用 STM32G070RBT6 給海外用戶開發產品，由于當地新需求，產品需要增加安全啟動的功能。但是由于 X-Cube-SBSFU 包提供的示例中，只有基于 STM32G071 的示例。客戶因此詢問該怎么移植。本文將講解這個移植過程。

在正式講解之前，我們首先來看一看 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 的方式來進行!

在確立了大方向后， 我們接下來看具體如何實現。

第一步 : 確保原始工程運行正常

從 ST 官網上下載最新了 SBSFU 包(v2.6.1)，打開STM32CubeExpansion_SBSFU_V2.6.1ProjectsNUCLEO-G071RBApplications2_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 中各種安全測試。

當程序跳入到 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 之后的保護。

本文旨在通過一個相對容易的移植， 讓讀者對 SBSFU 的移植過程有一個大概了解以起到參考和示范作用。