關(guān)鍵詞:SBSFU,移植
目錄預(yù)覽
1、前言
2、基于STM32G070和STM32G071的SBSFU 實(shí)現(xiàn)差異
3、開始移植
4、測試安全保護(hù)特性
5、后述
01
前言
客戶使用 STM32G070RBT6 給海外用戶開發(fā)產(chǎn)品,由于當(dāng)?shù)匦滦枨螅a(chǎn)品需要增加安全啟動(dòng)的功能。但是由于 X-Cube-SBSFU 包提供的示例中,只有基于 STM32G071 的示例??蛻粢虼嗽儐栐撛趺匆浦?。本文將講解這個(gè)移植過程。
02
基于STM32G070和STM32G071的SBSFU 實(shí)現(xiàn)差異
在正式講解之前,我們首先來看一看 STM32G070 和 STM32G071 的 SBSFU 實(shí)現(xiàn)差異。
STM32G070 是一個(gè) value line 產(chǎn)品,首先,我們要意識到,有一些安全特性,相比于STM32G071,它是沒有的,比如:PCROP,BOOT_LOCK 和 Secure User Memory。那么,缺少了這些安全特性的 STM32G070,是否還能實(shí)現(xiàn)安全啟動(dòng)的功能呢 ? 答案是肯定的。我們先來看 PCROP,BOOT_LOCK,以及 Secure User Memory 在 STM32G071 上的 SBSFU 實(shí)現(xiàn)中所扮演的角色是什么?
圖1.STM32G0 的 SBSFU 安全實(shí)現(xiàn)
如上圖,在 STM32G071 中,在安全啟動(dòng)的實(shí)現(xiàn)中,BOOT_LOCK 用來參與實(shí)現(xiàn)唯一啟動(dòng)入口,Secure User Memory 則用來參與實(shí)現(xiàn)信任根。PCROP 在安全固件升級實(shí)現(xiàn)中用來與MPU 配合實(shí)現(xiàn)密鑰的安全存儲(chǔ),同時(shí)在安全升級過程中涉及到一些密鑰的加解密操作,借助于Secure User Memory 和 MPU 的功能, 將 App 與 SBSFU 本身實(shí)現(xiàn)完美隔離。
圖2.STM32G0 內(nèi)存安全映射(運(yùn)行 SBSFU 時(shí))
回到當(dāng)前問題,一旦 BOOT_LOCK,PCROP,以及 Secure User Memory 缺少的情況下,這些功能還能實(shí)現(xiàn)嗎?
我們再來看下對于安全啟動(dòng)而言, 它需要實(shí)現(xiàn)哪些基本功能?
1> 不可更改不可繞過的一段啟動(dòng)代碼
2> 每次復(fù)位必先執(zhí)行安全啟動(dòng)代碼
3> 驗(yàn)證系統(tǒng)配置的完整性
? 時(shí)鐘配置
? 寄存器配置
? 存儲(chǔ)器保護(hù)設(shè)置, ….
4> 啟動(dòng)信任根服務(wù)
? 通過密碼學(xué)算法與密鑰,校驗(yàn) App 的完整性與合法性(來源可信,未經(jīng)篡改)
這里需要注意地是,上面提到的某一項(xiàng)安全屬性也只是參與實(shí)現(xiàn)某一項(xiàng)功能,比如BOOT_LOCK,它只是”參與”實(shí)現(xiàn)了唯一啟動(dòng)入口這個(gè)功能。從圖 1 可知, 除了BOOT_LOCK,還有 RDP,那么在缺少 BOOT_LOCK 的情況下,RDP 是否也可以實(shí)現(xiàn)唯一入口啟動(dòng)的功能。很明顯,在 RDP2 時(shí),MCU 的入口是唯一的。也就是說,沒有 BOOT_LOCK的參與下,RDP2 一樣可以實(shí)現(xiàn)安全啟動(dòng)對唯一入口啟動(dòng)的需求。RDP2+WRP 就可以實(shí)現(xiàn)安全啟動(dòng)的前兩條基本要求。而第三條基本要求,完全是 SBSFU 內(nèi)的純軟件實(shí)現(xiàn)。第四條要求,通過 RDP2+WRP+MPU 也可以實(shí)現(xiàn)。其實(shí), 在缺少了 PCROP,BOOT_LOCK 和Secure User Memory 后,STM32G070 的安全特性其實(shí)跟 STM32F4 差不多,我們不妨來看下STM32F4 是如何來實(shí)現(xiàn) SBSFU 功能的。
圖3.STM32F4 的 SBSFU 安全實(shí)現(xiàn)
如上圖所示,在 STM32F4 中,借助于 RDPL2,WRP,MPU 就實(shí)現(xiàn)了 SBSFU 的全部功能。
圖4.STM32F4 的 SBSFU 內(nèi)存映射
到這里,我們完全可以確信,在缺少了 BOOT_LOCK,PCROP 和 Secure User Memory這些安全特性之后,STM32G070 完全可以按照 STM32F4 實(shí)現(xiàn) SBSFU 的方式來進(jìn)行!
在確立了大方向后, 我們接下來看具體如何實(shí)現(xiàn)。
03
開始移植
第一步 : 確保原始工程運(yùn)行正常
從 ST 官網(wǎng)上下載最新了 SBSFU 包(v2.6.1),打開STM32CubeExpansion_SBSFU_V2.6.1ProjectsNUCLEO-G071RBApplications2_Images目錄,其下有三個(gè)工程,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)閉下面三個(gè)宏 :
重新依次編譯 SBCoreBin,SBSFU,UserApp 三個(gè)工程,并重新測試通過。
至此, NUCLEO-G071RB 板上運(yùn)行的是移除了 BOOT_LOCK, PCROP,Secure User Memory 三個(gè)安全特性后的 SBSFU 程序,這個(gè)原理上與 STM32G070 上原則上是一致的。接下來就是要移植到 NUCLEO-G070RB 板上了,剩下的就只有 STM32G070 與 STM32G071 的非安全特性方面的差異了。
第三步 : 移植到 STM32G070RB
首先得準(zhǔn)備下一塊 NUCLEO-G070RB 板。接著將三個(gè)工程 SBCoreBin,SBSFU,UserApp 的 device 修改成目標(biāo) MCU STM32G070RB,然后將三個(gè)工程的 C++預(yù)定義宏STM32G071xx 修改成 STM32G070xx。
以 Keil 為例 :
圖5.device 選擇 STM32G070RBTx
圖6.C++編譯宏修改
STM32CubeIDE 工程的 device 配置比較難修改,因?yàn)樗臼腔疑模辉试S修改。但我們使用 UE 打開.cproject 一樣可以強(qiáng)制修改 :
打開對應(yīng)的.cproject 文件,搜索關(guān)鍵字 G071,將以下幾處替換成 G070(修改兩處) :
圖7.STM32CubeIDE 下的 device 修改
修改完后,打開 STM32CubeIDE 工程,在其 MCU 和 Board 的配置也會(huì)有相應(yīng)的變化:
圖8.STM32CubeIDE 的 MCU 配置
由此可見,在 STM32CubeIDE 工程的 MCU 配置也可以做相應(yīng)的修改了。這是一個(gè)小技巧。
至此,三個(gè)工程的工程配置都做完了相應(yīng)修改。接下來的就是代碼方面的修改了。
首先 STM32G070 的時(shí)鐘樹是沒有 PLLQ 輸出的,因此,在 SBSFU 和 UserApp 這兩個(gè)工程內(nèi)找到 SystemClock_Config()函數(shù),注釋掉 PLLQ 的設(shè)置,如下所示 :
原先 STM32G071 的工程中的打印信息是通過 LPUART1 對應(yīng)的 PA2,PA3 打印的,換成NUCLEO-G070RB 板后,其引腳雖仍然是 PA2,PA3 引腳用來串口打印,但是 STM32G070中是沒有 LPUART1 這個(gè)外設(shè)的,需要換成 USART2,因此,其對應(yīng)的代碼修改如下 :
在 SBSFU 工程中, 打開 sfu_low_level.h 頭文件 , 和 UserApp 工程的 com.h 頭文件中:
如上紅色部分即為修改處。
至此,代碼部分全部修改完成。重新按順序依次編譯 SBCoreBin,SBSFU,UserApp 三個(gè)工程,將 SBSFU 工程首先燒錄到 NUCLEO-G070RB 板,然后通過串口終端,按提示,用 YModern 協(xié)議將 UserApp 對應(yīng)的.sfu 文件燒錄進(jìn)去。整個(gè)流程都可以正常運(yùn)行的。這說明軟件框架基本已經(jīng) OK。接下來運(yùn)行下 APP 中各種安全測試。
04
測試安全保護(hù)特性
當(dāng)程序跳入到 APP 后,顯示如下界面
圖9.測試主界面
當(dāng)選擇 2 Test Protection :Secure User Memory 時(shí),結(jié)果會(huì)出錯(cuò) :
圖10.測試保護(hù)
很明顯,這里需要修改下,因?yàn)?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 實(shí)現(xiàn),將此函數(shù)換成 TEST_PROTECTIONS_RunSE_CODE()函數(shù):
同樣的嘗試讀取密鑰:
圖11.UserApp 嘗試讀取密鑰
測試結(jié)果可想而知, 肯定是可以讀取的。于是得查看下為什么可以。
仔細(xì)查看圖 2 的 STM32G071 的 SBSFU 原來實(shí)現(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)行時(shí)的 flash 和 RAM 狀態(tài)
從上圖可以看出,原本 Secure User Memory 保護(hù)的區(qū)域,我們得使用 MPU 來替代實(shí)現(xiàn)相應(yīng)功能,包含 SBSFU 整個(gè)代碼和 Slot#1 內(nèi)的 header 信息。這也就是在代碼跳轉(zhuǎn)到 UserApp之前需要做的事情。而黃色對應(yīng)的 SRAM 區(qū)別已經(jīng)擦除,當(dāng)程序跳轉(zhuǎn)到 UserApp 后其實(shí)已經(jīng)沒必要再保護(hù)。
于是在跳轉(zhuǎn)到 UserApp 的內(nèi)存函數(shù)中配置 MPU:
注意這里是一個(gè)內(nèi)存函數(shù),它所調(diào)用的所有子函數(shù)也都是內(nèi)存函數(shù)。在這個(gè)函數(shù)中我們將SBSFU 所在的 64K Flash,再加上 2K 的 Active Slot 的 header 信息保護(hù)起來。內(nèi)存 RAM 我們并沒有配置保護(hù),因?yàn)樘D(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)會(huì)一直卡住, 這說明 MPU 對整個(gè) SBSFU 64K 區(qū)域的保護(hù)已經(jīng)生效。同樣的,選擇’3’測試 header 所在區(qū)域:
圖14.測試 Header 對應(yīng)的 2K 區(qū)域
發(fā)現(xiàn)程序讀取 0x0801 0000 地址時(shí)會(huì)一直卡住,這說明 MPU 對 header 的保護(hù)也已經(jīng)生效。然后再測試了下其它選項(xiàng),包含下載新固件,還有其它默認(rèn)的一些安全特性,基本都是OK 的。這說明整個(gè)程序基本已經(jīng) OK。
最后再恢復(fù)之前注釋掉的除 MPU 之后的保護(hù)。
05
后述
本文旨在通過一個(gè)相對容易的移植, 讓讀者對 SBSFU 的移植過程有一個(gè)大概了解以起到參考和示范作用。
原文標(biāo)題:實(shí)戰(zhàn)經(jīng)驗(yàn) | 移植 SBSFU 到 STM32G070 的過程
文章出處:【微信公眾號:STM32單片機(jī)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
-
單片機(jī)
+關(guān)注
關(guān)注
6023文章
44376瀏覽量
628407 -
STM32
+關(guān)注
關(guān)注
2258文章
10828瀏覽量
352493
原文標(biāo)題:實(shí)戰(zhàn)經(jīng)驗(yàn) | 移植 SBSFU 到 STM32G070 的過程
文章出處:【微信號:STM32_STM8_MCU,微信公眾號:STM32單片機(jī)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論