客戶使用 STM32G070RBT6 給海外用戶開發(fā)產(chǎn)品，由于當(dāng)?shù)匦滦枨?，產(chǎn)品需要增加安全啟動的功能。但是由于 X-Cube-SBSFU 包提供的示例中，只有基于 STM32G071 的示例?？蛻粢虼嗽儐栐撛趺匆浦?。本文將講解這個移植過程。

在正式講解之前，我們首先來看一看 STM32G070 和 STM32G071 的 SBSFU 實現(xiàn)差異。

STM32G070 是一個 value line 產(chǎn)品，首先，我們要意識到，有一些安全特性，相比于STM32G071，它是沒有的，比如：PCROP，BOOT_LOCK 和 Secure User Memory。那么，缺少了這些安全特性的 STM32G070，是否還能實現(xiàn)安全啟動的功能呢 ? 答案是肯定的。我們先來看 PCROP，BOOT_LOCK，以及 Secure User Memory 在 STM32G071 上的 SBSFU 實現(xiàn)中所扮演的角色是什么?

圖1.STM32G0 的 SBSFU 安全實現(xiàn)

如上圖，在 STM32G071 中，在安全啟動的實現(xiàn)中，BOOT_LOCK 用來參與實現(xiàn)唯一啟動入口，Secure User Memory 則用來參與實現(xiàn)信任根。PCROP 在安全固件升級實現(xiàn)中用來與MPU 配合實現(xiàn)密鑰的安全存儲，同時在安全升級過程中涉及到一些密鑰的加解密操作，借助于Secure User Memory 和 MPU 的功能， 將 App 與 SBSFU 本身實現(xiàn)完美隔離。

圖2.STM32G0 內(nèi)存安全映射(運(yùn)行 SBSFU 時)

回到當(dāng)前問題，一旦 BOOT_LOCK，PCROP，以及 Secure User Memory 缺少的情況下，這些功能還能實現(xiàn)嗎?

我們再來看下對于安全啟動而言， 它需要實現(xiàn)哪些基本功能?

1> 不可更改不可繞過的一段啟動代碼

2> 每次復(fù)位必先執(zhí)行安全啟動代碼

3> 驗證系統(tǒng)配置的完整性

? 時鐘配置

? 寄存器配置

? 存儲器保護(hù)設(shè)置， ….

4> 啟動信任根服務(wù)

? 通過密碼學(xué)算法與密鑰，校驗 App 的完整性與合法性（來源可信，未經(jīng)篡改）

這里需要注意地是，上面提到的某一項安全屬性也只是參與實現(xiàn)某一項功能，比如BOOT_LOCK，它只是”參與”實現(xiàn)了唯一啟動入口這個功能。從圖 1 可知， 除了BOOT_LOCK，還有 RDP，那么在缺少 BOOT_LOCK 的情況下，RDP 是否也可以實現(xiàn)唯一入口啟動的功能。很明顯，在 RDP2 時，MCU 的入口是唯一的。也就是說，沒有 BOOT_LOCK的參與下，RDP2 一樣可以實現(xiàn)安全啟動對唯一入口啟動的需求。RDP2+WRP 就可以實現(xiàn)安全啟動的前兩條基本要求。而第三條基本要求，完全是 SBSFU 內(nèi)的純軟件實現(xiàn)。第四條要求，通過 RDP2+WRP+MPU 也可以實現(xiàn)。其實， 在缺少了 PCROP，BOOT_LOCK 和Secure User Memory 后，STM32G070 的安全特性其實跟 STM32F4 差不多，我們不妨來看下STM32F4 是如何來實現(xiàn) SBSFU 功能的。

圖3.STM32F4 的 SBSFU 安全實現(xiàn)

如上圖所示，在 STM32F4 中，借助于 RDPL2，WRP，MPU 就實現(xiàn)了 SBSFU 的全部功能。

圖4.STM32F4 的 SBSFU 內(nèi)存映射

到這里，我們完全可以確信，在缺少了 BOOT_LOCK，PCROP 和 Secure User Memory這些安全特性之后，STM32G070 完全可以按照 STM32F4 實現(xiàn) SBSFU 的方式來進(jìn)行!

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

第一步 : 確保原始工程運(yùn)行正常

從 ST 官網(wǎng)上下載最新了 SBSFU 包(v2.6.1)，打開STM32CubeExpansion_SBSFU_V2.6.1ProjectsNUCLEO-G071RBApplications2_Images目錄，其下有三個工程，2_Images_SECoreBin(后續(xù)簡稱 SECoreBin 工程)，2_Images_SBSFU(后續(xù)簡稱 SBSFU 工程)，2_Images_UserApp(后續(xù)簡稱 UserApp 工程)。使用對應(yīng) IDE 按順序依次編譯， 然后將 SBSFU 工程生成的 bin 文件燒錄到 NUCLEO-G071RB板內(nèi)，打開 Tera Term 串口終端， 通過 Tera Term 燒錄 APP 進(jìn)去。目的是首先確認(rèn)原始工程一切運(yùn)行正常。接下來就開始修改了。

第二步 : 將與 BOOT_LOCK， PCROP， Secure User Memory 相關(guān)的宏全部關(guān)閉

打開 SBSFU 工程的 app_sfu.h 頭文件，找到并關(guān)閉下面三個宏 :

重新依次編譯 SBCoreBin，SBSFU，UserApp 三個工程，并重新測試通過。

至此， NUCLEO-G071RB 板上運(yùn)行的是移除了 BOOT_LOCK， PCROP，Secure User Memory 三個安全特性后的 SBSFU 程序，這個原理上與 STM32G070 上原則上是一致的。接下來就是要移植到 NUCLEO-G070RB 板上了，剩下的就只有 STM32G070 與 STM32G071 的非安全特性方面的差異了。

第三步 : 移植到 STM32G070RB

首先得準(zhǔn)備下一塊 NUCLEO-G070RB 板。接著將三個工程 SBCoreBin，SBSFU，UserApp 的 device 修改成目標(biāo) MCU STM32G070RB，然后將三個工程的 C++預(yù)定義宏STM32G071xx 修改成 STM32G070xx。

以 Keil 為例 :

圖5.device 選擇 STM32G070RBTx

圖6.C++編譯宏修改

STM32CubeIDE 工程的 device 配置比較難修改，因為它原本是灰色的，不允許修改。但我們使用 UE 打開.cproject 一樣可以強(qiáng)制修改 :

打開對應(yīng)的.cproject 文件，搜索關(guān)鍵字 G071，將以下幾處替換成 G070(修改兩處) :

圖7.STM32CubeIDE 下的 device 修改

修改完后，打開 STM32CubeIDE 工程，在其 MCU 和 Board 的配置也會有相應(yīng)的變化:

圖8.STM32CubeIDE 的 MCU 配置

由此可見，在 STM32CubeIDE 工程的 MCU 配置也可以做相應(yīng)的修改了。這是一個小技巧。

至此，三個工程的工程配置都做完了相應(yīng)修改。接下來的就是代碼方面的修改了。

首先 STM32G070 的時鐘樹是沒有 PLLQ 輸出的，因此，在 SBSFU 和 UserApp 這兩個工程內(nèi)找到 SystemClock_Config()函數(shù)，注釋掉 PLLQ 的設(shè)置，如下所示 ：

原先 STM32G071 的工程中的打印信息是通過 LPUART1 對應(yīng)的 PA2，PA3 打印的，換成NUCLEO-G070RB 板后，其引腳雖仍然是 PA2，PA3 引腳用來串口打印，但是 STM32G070中是沒有 LPUART1 這個外設(shè)的，需要換成 USART2，因此，其對應(yīng)的代碼修改如下 :

在 SBSFU 工程中， 打開 sfu_low_level.h 頭文件 ， 和 UserApp 工程的 com.h 頭文件中:

如上紅色部分即為修改處。

至此，代碼部分全部修改完成。重新按順序依次編譯 SBCoreBin，SBSFU，UserApp 三個工程，將 SBSFU 工程首先燒錄到 NUCLEO-G070RB 板，然后通過串口終端，按提示，用 YModern 協(xié)議將 UserApp 對應(yīng)的.sfu 文件燒錄進(jìn)去。整個流程都可以正常運(yùn)行的。這說明軟件框架基本已經(jīng) OK。接下來運(yùn)行下 APP 中各種安全測試。

當(dāng)程序跳入到 APP 后，顯示如下界面

圖9.測試主界面

當(dāng)選擇 2 Test Protection :Secure User Memory 時，結(jié)果會出錯 :

圖10.測試保護(hù)

很明顯，這里需要修改下，因為 STM32G070 是沒有 Secure User Memory 的。查看其對應(yīng)代碼：

原來 UserApp 是測試直接讀取保存在 SECoreBin 內(nèi)的密鑰數(shù)據(jù)， 測試是否能讀出。結(jié)果發(fā)現(xiàn)是可以的，因此，保護(hù)效果是出問題了。

首先我們修改下此函數(shù)，由于 STM32G070 中 Secure User Memory 是不存在的， 此函數(shù)叫 TEST_PROTECTIONS_RunSecUserMem_CODE()已經(jīng)不再合適， 依照 STM32F4 的SBSFU 實現(xiàn)，將此函數(shù)換成 TEST_PROTECTIONS_RunSE_CODE()函數(shù):

同樣的嘗試讀取密鑰：

圖11.UserApp 嘗試讀取密鑰

測試結(jié)果可想而知， 肯定是可以讀取的。于是得查看下為什么可以。

仔細(xì)查看圖 2 的 STM32G071 的 SBSFU 原來實現(xiàn)中，SE Key 是通過 PCROP+Secure User Memory 來保護(hù)的，現(xiàn)在換成 STM32G070，原本 Secure User Memory 用來作隔離機(jī)制， 現(xiàn)在換成了 MPU， 而原本保護(hù) SE Key 的 PCROP 在 G070 中壓根就不存在，于是 SE Key 只剩下 MPU 來保護(hù)，因此，我們接下來得著重分析 MPU 對 SE Key 的保護(hù)。

為了方便調(diào)試，我們首先得將除 MPU 以外的所有保護(hù)通通關(guān)閉，只剩下 MPU 保護(hù)。于是在 SBSFU 工程中，在 app_sfu.h 頭文件中，將以下宏通通注釋掉:

然后開始調(diào)試。在調(diào)試過程中，發(fā)現(xiàn)程序在從 SBSFU 跳轉(zhuǎn)到 UserApp 之前，在代碼中特意將 MPU 關(guān)閉：

如在 sfu_low_level_security.c 源文件中的內(nèi)存函數(shù) SFU_LL_SECU_ActivateSecUser()中有這么一行代碼：

這就是為什么 UserApp 中仍然可以直接讀取密鑰的原因了。很明顯，接下來我們需要將 SEKey 用 MPU 保護(hù)起來。但在這之前，我們得首先弄清楚，當(dāng)程序跳轉(zhuǎn)到 UserApp 后，F(xiàn)lash 和Ram 該如何設(shè)置 MPU 保護(hù)?

在 UM2262 中， 有提到當(dāng)程序跳轉(zhuǎn)到 UserApp 后 flash 和 RAM 的狀態(tài)：

圖12.UserApp 運(yùn)行時的 flash 和 RAM 狀態(tài)

從上圖可以看出，原本 Secure User Memory 保護(hù)的區(qū)域，我們得使用 MPU 來替代實現(xiàn)相應(yīng)功能，包含 SBSFU 整個代碼和 Slot#1 內(nèi)的 header 信息。這也就是在代碼跳轉(zhuǎn)到 UserApp之前需要做的事情。而黃色對應(yīng)的 SRAM 區(qū)別已經(jīng)擦除，當(dāng)程序跳轉(zhuǎn)到 UserApp 后其實已經(jīng)沒必要再保護(hù)。

于是在跳轉(zhuǎn)到 UserApp 的內(nèi)存函數(shù)中配置 MPU：

注意這里是一個內(nèi)存函數(shù)，它所調(diào)用的所有子函數(shù)也都是內(nèi)存函數(shù)。在這個函數(shù)中我們將SBSFU 所在的 64K Flash，再加上 2K 的 Active Slot 的 header 信息保護(hù)起來。內(nèi)存 RAM 我們并沒有配置保護(hù)，因為跳轉(zhuǎn)到 UserApp 后它就完全開放，且內(nèi)容已經(jīng)清空。

對應(yīng)的， 我們在 UserApp 中增加對 Header 的測試函數(shù) ：

重新燒錄程序，當(dāng)程序運(yùn)行后，選擇 2 進(jìn)行 protection 測試，然后再選擇 2，測試訪問SBSFU 所有的 64K 區(qū)域：

圖13.測試 SBSFU 的 64K 代碼區(qū)

發(fā)現(xiàn)會一直卡住， 這說明 MPU 對整個 SBSFU 64K 區(qū)域的保護(hù)已經(jīng)生效。同樣的，選擇’3’測試 header 所在區(qū)域：

圖14.測試 Header 對應(yīng)的 2K 區(qū)域

發(fā)現(xiàn)程序讀取 0x0801 0000 地址時會一直卡住，這說明 MPU 對 header 的保護(hù)也已經(jīng)生效。然后再測試了下其它選項，包含下載新固件，還有其它默認(rèn)的一些安全特性，基本都是OK 的。這說明整個程序基本已經(jīng) OK。

最后再恢復(fù)之前注釋掉的除 MPU 之后的保護(hù)。

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