一塊開發(fā)板卡死在U-Boot的“Starting kernel”之前日志全是空白這種問題在ARM平臺(tái)底層其實(shí)很常見而且八成不是內(nèi)核的問題而是EL3固件沒起來。我第一次接觸Arm Trusted FirmwareATF時(shí)光搞清楚BL1、BL2、BL31、BL32、BL33這條啟動(dòng)鏈就花了不少時(shí)間后來又把源碼從頭到尾翻了一遍在FVP虛擬平臺(tái)上完整走了一次平臺(tái)移植才算真正理解這套安全固件到底在設(shè)計(jì)什么。這篇文章就是那次過程的全記錄適合做平臺(tái)Bring-up的底層工程師、做固件安全審查的同事以及想系統(tǒng)搞懂ATF的嵌入式方向?qū)W生來讀。我會(huì)直接從“ATF在上電鏈路里到底站在哪”“源碼目錄如何按信任邊界組織”“安全審計(jì)要看哪幾個(gè)關(guān)鍵點(diǎn)”“從零移植一份platform port需要碰哪些接口”這幾個(gè)角度來寫盡量把工程上容易出問題的地方一次說清。1. ATF到底管哪一段從上電到U-Boot的“接力棒”劃分很多新人容易把ATF和U-Boot混在一起覺得都是“引導(dǎo)程序”。實(shí)際上在AArch64架構(gòu)里ATF并不是一個(gè)單一固件而是一整套由多個(gè)BLBoot Loader階段組成的引導(dǎo)鏈條它的工作范圍從上電那一刻一直延伸到操作系統(tǒng)接管之前并且其中一部分會(huì)在操作系統(tǒng)運(yùn)行期間常駐EL3隨時(shí)響應(yīng)安全服務(wù)請(qǐng)求。1.1 為什么要單獨(dú)做EL3這一層普通固件的“權(quán)限天花板”ARMv8-A定義了EL0到EL3四個(gè)異常級(jí)別。操作系統(tǒng)內(nèi)核跑在EL1虛擬化場(chǎng)景下Hypervisor跑在EL2用戶態(tài)跑在EL0而EL3是Secure Monitor所在的最高特權(quán)層。U-Boot可以跑在EL1或者EL2但它本身沒有能力管理Secure World也無法直接控制系統(tǒng)級(jí)電源操作。ATF的核心價(jià)值就是把這層EL3能力補(bǔ)上。這種分層不是ARM拍腦袋設(shè)計(jì)的。你想想如果沒有EL3常駐的安全監(jiān)控器普通世界Normal World想關(guān)個(gè)CPU、做深度睡眠、觸發(fā)熱重啟就只能通過某些非標(biāo)準(zhǔn)機(jī)制繞過安全邊界會(huì)被打穿。有了EL3之后所有敏感操作都被收攏到一個(gè)受控入口這個(gè)入口就是后面要重點(diǎn)講的SMC異常。它在設(shè)計(jì)上很像一個(gè)“門房”——外部世界只能通過門鈴SMC指令提出申請(qǐng)真正進(jìn)入房間的權(quán)力始終掌握在EL3手里。1.2 一個(gè)啟動(dòng)序列的真實(shí)畫面一次完整的ATF引導(dǎo)大致是這樣上電后SoC執(zhí)行片內(nèi)ROM里的BL1BL1完成基礎(chǔ)時(shí)鐘、串口等最小初始化并驗(yàn)證BL2鏡像后將其加載到SRAM。BL2在SRAM中運(yùn)行負(fù)責(zé)初始化DDR控制器等內(nèi)存系統(tǒng)加載BL31、BL32可選TEE以及BL33U-Boot或EDK2加載完成后跳入BL31。BL31在EL3完成運(yùn)行時(shí)環(huán)境初始化包括中斷控制器、系統(tǒng)寄存器、PSCI服務(wù)注冊(cè)然后降級(jí)跳到BL33。BL33U-Boot接管平臺(tái)加載內(nèi)核內(nèi)核運(yùn)行期間通過SMC指令請(qǐng)求BL31提供的PSCI電源管理等運(yùn)行時(shí)服務(wù)。我用FVP平臺(tái)模擬器跑了一遍Debug版日志大致長(zhǎng)這樣NOTICE: BL1: v2.8(debug):v2.8 NOTICE: BL1: Built : ... INFO: BL1: RAM 0x0 - 0x1000 NOTICE: BL1: Booting BL2 INFO: BL2: Loading image id 3 NOTICE: BL31: v2.8(debug):v2.8 NOTICE: BL31: Initializing runtime services INFO: BL31: Preparing for BL33 entryU-Boot跑起來之后ATF并沒有退出舞臺(tái)。BL31依然在內(nèi)存里負(fù)責(zé)響應(yīng)系統(tǒng)運(yùn)行過程中的電源管理請(qǐng)求。為了直觀理解各階段的職責(zé)我整理了這么一張表階段存儲(chǔ)位置主要職責(zé)生命周期BL1SoC片內(nèi)ROM信任根、加載BL2啟動(dòng)完成后不再參與BL2SRAM初始化DDR、加載后續(xù)鏡像啟動(dòng)完成后可被覆蓋BL31DDR/SRAMEL3運(yùn)行時(shí)、PSCI/SMC服務(wù)、安全中斷常駐BL32DDRTEE OS如OP-TEE常駐BL33DDRU-Boot/EDK2最終被內(nèi)核接管這個(gè)表格基本就是你理解ATF源碼地圖的起點(diǎn)。每個(gè)階段的代碼在倉(cāng)庫(kù)里對(duì)應(yīng)一個(gè)獨(dú)立目錄邊界非常清晰。2. 源碼結(jié)構(gòu)解剖按信任邊界而非功能模塊組織代碼ATF在GitHub上的官方倉(cāng)庫(kù)是ARM-software/arm-trusted-firmware現(xiàn)在一般叫TF-A。我建議clone下來之后不要急著看某個(gè)文件先把頂層目錄掃一遍。這個(gè)倉(cāng)庫(kù)的組織方式很有意思它不完全按“功能模塊”來劃分而是按“信任邊界和業(yè)務(wù)邊界”來劃分理解了這一點(diǎn)讀代碼會(huì)順暢很多。2.1 目錄與四個(gè)關(guān)鍵模塊頂層目錄里幾個(gè)重點(diǎn)bl1/BL1源碼ROM階段代碼必須盡量精簡(jiǎn)。bl2/BL2源碼負(fù)責(zé)鏡像加載與驗(yàn)證。bl31/BL31運(yùn)行時(shí)源碼包含入口、主流程、上下文管理。bl32/BL32相關(guān)的SPDSecure Payload Dispatcher代碼路徑常見的是opteed。services/BL31暴露給上層調(diào)用的運(yùn)行時(shí)服務(wù)最關(guān)鍵的是std_svc下的PSCI實(shí)現(xiàn)還有spmd這類可選服務(wù)。plat/平臺(tái)移植代碼所有廠商和開發(fā)板支持都在這里。lib/通用庫(kù)包括el3_runtime、psci、extensions比如v8.x特性支持、xlat_tables等。drivers/各類外設(shè)驅(qū)動(dòng)包括ARM GIC、PL011串口等。fdts/設(shè)備樹源文件主要用于FVP等平臺(tái)。bl31目錄下有一個(gè)bl31_main.c里面是BL31啟動(dòng)后的主流程從入口匯編到C語言的交接點(diǎn)就在這里。services/目錄下的std_svc是PSCI標(biāo)準(zhǔn)服務(wù)所在的目錄往下能看到psci/的實(shí)現(xiàn)里面全是CPU開機(jī)、關(guān)核、休眠、重置、關(guān)機(jī)這些系統(tǒng)級(jí)操作的實(shí)際邏輯。2.2 PSCI是什么SMC到底是怎么被路由的PSCI是電源狀態(tài)協(xié)調(diào)接口。操作系統(tǒng)在實(shí)現(xiàn)CPU hotplug、idle、系統(tǒng)restart時(shí)雖然邏輯在kernel里但真實(shí)的硬件操作是通過SMC指令交給EL3完成的。每個(gè)SMC調(diào)用都有一個(gè)function id也就是EBTException Based Trap之后的調(diào)用號(hào)。SMC調(diào)用號(hào)的格式是這樣的32位調(diào)用號(hào)里高16位包含OENOwner Entity Number等屬性字段比如PSCI服務(wù)的OEN是0SIP服務(wù)的OEN是2低16位定義具體調(diào)用號(hào)比如CPU_ON、CPU_OFF、SYSTEM_RESET這些。在BL31中每一個(gè)運(yùn)行時(shí)服務(wù)都通過宏DECLARE_RT_SVC聲明到特殊的鏈接段里。BL31啟動(dòng)時(shí)會(huì)在rt_svc_descs段里掃描這些服務(wù)描述符構(gòu)建一張服務(wù)路由表。當(dāng)EL1的代碼執(zhí)行smc #0指令后硬件自動(dòng)陷入EL3異常向量把控制權(quán)交給BL31的handle_smc再根據(jù)OEN字段找到對(duì)應(yīng)服務(wù)最后分發(fā)到具體的handler函數(shù)。這個(gè)過程相當(dāng)于一個(gè)內(nèi)部電話總機(jī)。調(diào)用方說“我要找PSCI的CPU_ON”總機(jī)查表轉(zhuǎn)到對(duì)應(yīng)分機(jī)?；鶖?shù)和轉(zhuǎn)換邏輯不復(fù)雜難的是對(duì)各個(gè)平臺(tái)的適配。2.3 編譯產(chǎn)物bl1.bin、fip.bin與燒錄布局編譯ATF最基本的命令是這樣make PLATfvp DEBUG1編譯成功后在build/fvp/debug/目錄下能看到bl1.bin、bl2.bin、bl31.bin還有一個(gè)fip.bin。FIPFirmware Image Package是把多個(gè)鏡像打包進(jìn)一個(gè)文件的固件包可以用倉(cāng)庫(kù)里的fiptool工具查看和拆包。實(shí)際產(chǎn)品燒錄時(shí)通常把bl1.bin放到ROM對(duì)應(yīng)位置把fip.bin放到SPI Flash或其他啟動(dòng)介質(zhì)中BL2會(huì)根據(jù)FIP的TOCTable of Contents加載后續(xù)鏡像。很多初學(xué)者一開始會(huì)疑惑為什么BL2和BL31不分別燒寫非要打包成FIP。主要原因是生產(chǎn)時(shí)方便統(tǒng)一簽名、統(tǒng)一管理也方便用fiptool做差分升級(jí)。對(duì)于一個(gè)平臺(tái)可能只需要升級(jí)某個(gè)組件重新打包一次FIP即可不用單獨(dú)擦除Flash上的獨(dú)立分區(qū)。3. 安全固件工程審計(jì)從威脅模型看ATF的關(guān)鍵防護(hù)設(shè)計(jì)說到“安全審計(jì)”很多人第一反應(yīng)是找漏洞、看CWE清單。實(shí)際做固件工程審計(jì)更重要的先想清楚威脅模型攻擊者能碰哪里他有多少能力我們防的是什么。對(duì)ATF這種EL3固件攻擊者通常能控制的是Normal World的整個(gè)軟件棧甚至可以跑自己的內(nèi)核。他能發(fā)起SMC請(qǐng)求、能訪問DDR內(nèi)存、也可能嘗試?yán)抿?qū)動(dòng)漏洞改寫DDR內(nèi)容。ATF要保證的是這套已經(jīng)被“攻破”的Normal World依然無法突破EL3的保護(hù)無法讀取Secure World數(shù)據(jù)無法非法控制系統(tǒng)電源操作無法篡改啟動(dòng)流程。所有關(guān)鍵機(jī)制都圍繞這個(gè)目標(biāo)展開。3.1 ROM Code、SRAM、DDR三層存儲(chǔ)的信任邊界ATF的安全模型首先要看代碼放在哪。BL1在芯片出廠ROM里物理上不可寫是信任根。BL2在SRAM里SRAM通常不被DMA控制器隨意訪問安全等級(jí)也比較高。但BL31和BL33在DDR里運(yùn)行DDR是開放的攻擊者有機(jī)會(huì)接觸。所以ATF不能假設(shè)BL31運(yùn)行的環(huán)境完全可信它必須通過硬件隔離機(jī)制TrustZone把CPU和總線上的訪問控制住。TrustZone地址空間控制器TZASC可以把DDR物理區(qū)域劃分成Secure區(qū)域和Normal區(qū)域只有Secure側(cè)EL3或Secure World才能訪問Secure區(qū)域。即便攻擊者在Normal World跑任何代碼總線層面過不了TZASC拿不到Secure Region內(nèi)容。審計(jì)時(shí)要重點(diǎn)檢查平臺(tái)代碼里TZASC區(qū)域的配置是否過于寬松。有些開發(fā)板為了調(diào)試方便把所有DDR都配成Non-Secure這在開發(fā)階段問題不大但量產(chǎn)固件這樣配就形同虛設(shè)。審核plat/*/plat_security.c這類配置時(shí)第一件事就是看內(nèi)存區(qū)域切割表。3.2 世界切換與SMC返回時(shí)的狀態(tài)保存每次Normal World調(diào)用SMC進(jìn)入EL3都要保存Normal World的寄存器狀態(tài)再?gòu)腟ecure上下文或EL3自己的上下文恢復(fù)現(xiàn)場(chǎng)。這個(gè)保存恢復(fù)的代碼在lib/el3_runtime/aarch64/context_mgmt.c里。審計(jì)時(shí)要特別留意的點(diǎn)是scr_el3寄存器的設(shè)置尤其NS位。如果異常返回時(shí)NS位配錯(cuò)處理器會(huì)錯(cuò)誤地進(jìn)入Secure World導(dǎo)致權(quán)限錯(cuò)亂。在實(shí)際攻擊面里SMC返回值的處理同樣關(guān)鍵。Secure Monitor在結(jié)束時(shí)做eret回到Normal World之前會(huì)檢查返回上下文里的PSTATE和PC是否合法。ATF的通用代碼整體做得比較嚴(yán)問題往往出在平臺(tái)自定義的handler里。例如平臺(tái)自己實(shí)現(xiàn)了一個(gè)SMC查詢接口返回了一個(gè)指向Secure內(nèi)存的指針但沒做地址范圍檢查Normal World拿到后就能直接訪問Secure信息。這就是工程審計(jì)里需要重點(diǎn)追的問題模式。3.3 輸入校驗(yàn)SMC請(qǐng)求參數(shù)不能直接信BL31接收到SMC請(qǐng)求所有參數(shù)都來自低權(quán)限層不能直接當(dāng)成可信數(shù)據(jù)使用。以PSCI的CPU_ON為例調(diào)用者需要傳入目標(biāo)核心的mpidr。BL31要先通過plat_core_pos_by_mpidr()把這個(gè)物理ID映射到平臺(tái)核心編號(hào)的索引范圍并檢查是否越界然后才能操作核心。曾有人專門審計(jì)ATF歷史CVE很多問題都出在跨平臺(tái)代碼和平臺(tái)回調(diào)之間的信任邊界沒掐好。舉個(gè)例子如果平臺(tái)的plat_core_pos_by_mpidr實(shí)現(xiàn)沒有對(duì)未知MPIDR做統(tǒng)一錯(cuò)誤碼返回而是直接返回0那上層的循環(huán)就可能把0號(hào)核重復(fù)操作造成系統(tǒng)狀態(tài)錯(cuò)亂。審計(jì)這份代碼時(shí)不要去讀PSCI核心邏輯直接把所有plat_開頭的回調(diào)函數(shù)全部拉出來逐個(gè)核對(duì)返回值檢查是否完備這個(gè)思路效率高得多。3.4 安全啟動(dòng)與簽名證書鏈ATF的Trusted Board BootTBB功能是安全審計(jì)繞不開的主題。啟用TRUSTED_BOARD_BOOT1后BL2會(huì)驗(yàn)證BL31、BL32、BL33的證書鏈每個(gè)鏡像都帶一個(gè)X.509證書證書由平臺(tái)信任的密鑰簽發(fā)。密鑰管理的根在哪兒信任鏈就從哪兒開始。典型的TBBR流程是BL1在ROM里信任“根公鑰”這個(gè)公鑰通常被燒在fuse或OTP里BL1驗(yàn)證BL2的證書BL2再驗(yàn)證后續(xù)所有鏡像。這樣即便攻擊者能改寫Flash上的BL31/BL33沒有私鑰也無法通過簽名驗(yàn)證。但是反過來如果fuse配置時(shí)把調(diào)試密鑰development key或RSA公鑰hash留空就會(huì)導(dǎo)致驗(yàn)證被跳過。審計(jì)安全啟動(dòng)時(shí)第一件事就是確認(rèn)構(gòu)建和燒錄階段用的是生產(chǎn)密鑰還是調(diào)試密鑰。3.5 一個(gè)可直接用的審計(jì)清單審計(jì)維度關(guān)鍵檢查點(diǎn)常見問題接口層SMC handler是否校驗(yàn)所有入?yún)?、返回地址是否在合法范圍參?shù)未校驗(yàn)、返回SMC功能號(hào)錯(cuò)誤數(shù)據(jù)層全局緩沖區(qū)是否有邊界檢查、是否有越界寫數(shù)組越界、整型溢出導(dǎo)致繞過存儲(chǔ)層TZASC區(qū)域劃分、Secure DDR是否過大或過小全部DDR配成Non-Secure啟動(dòng)鏈證書鏈?zhǔn)欠駨?qiáng)制啟用、密鑰來源是否可控調(diào)試密鑰帶入量產(chǎn)運(yùn)行時(shí)異常向量表是否完整、SDEI中斷是否可被惡意觸發(fā)異常向量未初始化、中斷搶占異常這個(gè)清單不是讓你一條條機(jī)械打鉤而是用來建立“威脅模型→代碼位置→檢查方法”的對(duì)應(yīng)關(guān)系。拿到一份新平臺(tái)固件時(shí)沿著這個(gè)表過一遍基本能把高風(fēng)險(xiǎn)點(diǎn)篩出來。4. 平臺(tái)移植落地從零讓ATF跑在一塊新板上ATF源碼本身支持很多參考平臺(tái)比如ARM官方FVP、Juno以及眾多廠商的SoC平臺(tái)。但新板子的Bring-up終歸要自己動(dòng)手做platform port。這一節(jié)我按實(shí)際移植順序整理一套可執(zhí)行步驟。4.1 先找“母板”復(fù)制一份最小平臺(tái)框架移植第一步不是寫代碼而是選參考平臺(tái)。如果你的新芯片是某廠商SoC的迭代版本盡量用該廠商已支持的最新平臺(tái)代碼作為底子復(fù)制一份改。如果完全從零起步用FVP平臺(tái)代碼做模板是最穩(wěn)的它結(jié)構(gòu)清晰、不依賴具體外設(shè)。在plat/下面創(chuàng)建自己的目錄結(jié)構(gòu)比如plat/acme/board/alpha/。這個(gè)目錄里需要包含platform.mk定義平臺(tái)源文件、編譯選項(xiàng)、內(nèi)存基址。plat_setup.c實(shí)現(xiàn)平臺(tái)啟動(dòng)早期初始化和運(yùn)行時(shí)初始化。plat_pm.c實(shí)現(xiàn)PSCI的電源控制回調(diào)。plat_sip.c實(shí)現(xiàn)平臺(tái)自定義的SIP SMC服務(wù)可選。include/platform_def.h定義平臺(tái)相關(guān)的所有宏。platform.mk里最核心的幾行大概長(zhǎng)這樣PLAT_BL31_BASE : 0x40100000 $(eval $(call add_define,PLAT_BL31_BASE)) BL31_SOURCES \ plat/acme/board/alpha/plat_setup.c \ plat/acme/board/alpha/plat_pm.c對(duì)新手來說先記住一個(gè)原則BL31_BASE必須指向一塊在BL31運(yùn)行期間不會(huì)被覆蓋的DDR區(qū)域。很多人一開始直接把BL31放到0x40000000而U-Boot又把自己放在同一個(gè)地址結(jié)果BL31被U-Boot加載后覆蓋系統(tǒng)莫名其妙的掛掉。4.2 四個(gè)繞不開的核心接口在BL31的啟動(dòng)流程里平臺(tái)需要實(shí)現(xiàn)幾個(gè)關(guān)鍵回調(diào)。若任何一個(gè)沒實(shí)現(xiàn)或?qū)崿F(xiàn)不完整系統(tǒng)都會(huì)卡死或者提前進(jìn)入異常。第一個(gè)是bl31_plat_arch_setup()它的任務(wù)是配置MMU和內(nèi)存映射。BL31剛接手時(shí)MMU通常是關(guān)閉的需要在這里借助ATF的xlat_tables庫(kù)建立頁(yè)表。要特別注意的是串口地址的映射必須在這步之前或這步過程中配好否則你后面所有printf都會(huì)變成黑暗中的吶喊什么都沒有。void bl31_plat_arch_setup(void) { /* 配置MMU映射包含UART、GIC、以及BL31自身所在內(nèi)存 */ enable_mmu_el3(0); }第二個(gè)是bl31_platform_setup()它負(fù)責(zé)初始化串口、GIC等基本外設(shè)。GIC初始化的時(shí)機(jī)很敏感太早會(huì)導(dǎo)致中斷配置不完全太晚又會(huì)丟了需要EL3響應(yīng)的中斷。第三個(gè)是plat_get_next_bl_params()它負(fù)責(zé)構(gòu)造下一個(gè)階段鏡像的啟動(dòng)參數(shù)。ATF內(nèi)部用bl_params鏈表記錄BL33等信息BL31在跳轉(zhuǎn)前會(huì)從這個(gè)結(jié)構(gòu)里取入口地址和參數(shù)。這里也是要把設(shè)備樹地址傳遞給U-Boot的地方。void bl31_plat_get_next_bl_params(struct bl_params *params) { bl_params_node_t *node params-head; struct entry_point_info *bl33_ep node-ep_info; /* 設(shè)置BL33入口的x0為設(shè)備樹地址 */ bl33_ep-args.arg0 PLAT_DTB_ADDR; }第四個(gè)是PSCI電源管理相關(guān)回調(diào)。你至少要實(shí)現(xiàn)CPU上電、CPU下電、系統(tǒng)重啟、系統(tǒng)關(guān)機(jī)的回調(diào)。代碼通常在plat_pm.c里實(shí)現(xiàn)然后通過plat_setup_psci_ops()注冊(cè)到PSCI框架中。接口實(shí)現(xiàn)有一個(gè)通用的調(diào)試順序先把串口和GIC跑通再調(diào)試MMU最后再接手PSCI。不要一次把全部代碼寫滿再統(tǒng)一調(diào)試那樣出問題時(shí)你會(huì)完全找不到切入點(diǎn)。4.3 和U-Boot怎么對(duì)接BL33入口和設(shè)備樹傳遞很多人卡在“ATF啟動(dòng)后怎么跳到U-Boot”這個(gè)問題上。其實(shí)ATF到U-Boot的跳轉(zhuǎn)就是一個(gè)普通的eret但在跳轉(zhuǎn)前要做幾件事從bl_params鏈表里取出BL33的入口地址。在x0寄存器里放入設(shè)備樹地址AArch64上約定參數(shù)放x0。設(shè)置好SP、ELR、SPSR這些異常返回寄存器。執(zhí)行el3_exit完成異常返回到Normal World。U-Boot啟動(dòng)后如果能看到設(shè)備樹地址參數(shù)說明BL31到BL33的這一棒交接成功。如果U-Boot啟動(dòng)后沒有任何設(shè)備樹信息大概率是plat_get_next_bl_params沒有正確設(shè)置args或者BL2傳給BL31的bl_params鏈表本身就不包含BL33。對(duì)很多ARMv8平臺(tái)U-Boot本身也可以作為BL33運(yùn)行在EL2而內(nèi)核則進(jìn)一步降到EL1。這一層層降級(jí)都依賴ATF在EL3側(cè)做好的上下文切換。4.4 交叉編譯工具鏈的選型問題ATF官方構(gòu)建默認(rèn)使用GCC或者Clang命令大致是make PLATmyboard DEBUG1 CROSS_COMPILEaarch64-linux-gnu-有些初學(xué)者看到網(wǎng)上的ARM Compiler 5.06下載教程以為編ATF也得用AC5/AC6。AC5/AC6主要是ARM自家為Cortex-M等裸機(jī)場(chǎng)景提供的商業(yè)編譯器一般用于keil這類IDE開發(fā)STM32工程與ATF完全是兩條線。ATF的鏈接腳本、內(nèi)聯(lián)匯編、編譯選項(xiàng)都面向GCC/Clang風(fēng)格所以老老實(shí)實(shí)用GNU工具鏈就好。主機(jī)是x86時(shí)裝上gcc-aarch64-linux-gnu交叉編譯工具鏈就夠了在ARM服務(wù)器上原生編譯也可以只是編譯速度通常不如x86。5. 移植過程中的真實(shí)調(diào)試經(jīng)歷與常見坑最后這一部分我把這幾年來在ATF移植過程中實(shí)際踩過、見過的問題整理一下。這些問題在官方文檔里基本不會(huì)太細(xì)提但碰到的概率高得令人發(fā)指。5.1 卡在BL31開頭串口連一個(gè)字符都不出這是一半以上板子Bring-up會(huì)遇到的第一個(gè)問題。串口不出日志不代表系統(tǒng)完全沒跑很可能是串口還沒初始化就開始調(diào)printf了。Debug版里BL31的NOTICE打印發(fā)生在bl31_early_platform_setup階段如果這一步?jīng)]有正確初始化UART時(shí)鐘和引腳后面全白搭。排查思路是這樣先確認(rèn)UART硬件本身有沒有問題可以在U-Boot里把BL31所在區(qū)域擦掉讓U-Boot直接接管串口看能不能輸出。在bl31_plat_arch_setup里加最簡(jiǎn)單的裸寄存器操作往UART發(fā)送寄存器寫一個(gè)字節(jié)繞過ATF的串口驅(qū)動(dòng)直接驗(yàn)證。檢查MMU映射如果UART地址沒有映射成Device類型內(nèi)存訪問會(huì)觸發(fā)同步異常系統(tǒng)會(huì)直接死掉。以我的經(jīng)驗(yàn)80%的“沒有任何輸出”到最后都是MMU映射沒配好而不是串口驅(qū)動(dòng)代碼寫錯(cuò)了。5.2 SMC調(diào)用返回錯(cuò)誤值或hang死如果你已經(jīng)在U-Boot或內(nèi)核里通過smc指令調(diào)用了ATF的功能但返回的值不對(duì)第一步先不要懷疑固件邏輯查一下調(diào)用號(hào)對(duì)不對(duì)。SMC function id的OEN字段和調(diào)用編號(hào)必須和實(shí)際注冊(cè)的服務(wù)匹配。比如平臺(tái)SIP服務(wù)一般在plat_sip.c里用宏注冊(cè)O(shè)EN是2。如果你在內(nèi)核里發(fā)的調(diào)用號(hào)OEN寫成了0就會(huì)走到PSCI handler自然返回不認(rèn)識(shí)。再看一種更隱蔽的情況handler返回了但x0的值不是預(yù)期值。這種問題多半出在上下文保存環(huán)節(jié)。BL31在SMC入口把異常現(xiàn)場(chǎng)保存在cpu_context中handler的返回值最終寫回x0。如果handler內(nèi)部不小心用了同一個(gè)寄存器保存臨時(shí)值返回現(xiàn)場(chǎng)恢復(fù)后期望值就會(huì)被覆蓋。調(diào)試這類問題用gdb連上目標(biāo)板或QEMU在handle_smc入口和el3_exit處打斷點(diǎn)對(duì)比x0的變化是最直接的。5.3 在QEMU上把整套鏈跑起來沒有真實(shí)開發(fā)板時(shí)QEMU是最靠譜的調(diào)試環(huán)境。ATF源碼直接支持make PLATqemu編出來的鏡像可以配合QEMU運(yùn)行。一個(gè)常見做法是單獨(dú)構(gòu)建QEMU平臺(tái)ATF然后用QEMU的-bios參數(shù)加載BL1或者直接用-kernel加載FIP。對(duì)于調(diào)試BL31流程我建議加上-S -gdb tcp::1234參數(shù)讓QEMU在啟動(dòng)時(shí)掛起再用aarch64-none-elf-gdb連接上去直接在bl31_main下斷點(diǎn)單步看每一步寄存器和內(nèi)存的變化。這種方式比串口日志有效得多因?yàn)槟苤苯涌吹組MU是否開啟、頁(yè)表內(nèi)容是否正確、異常向量是否指向預(yù)期地址。5.4 熱詞里的常見困惑從“編譯后沒有arm文件夾”到“找不到用戶態(tài)ATF接口”我注意到最近社區(qū)里有些帖子提到“編譯后沒有arm文件夾”這類問題。出現(xiàn)的原因一般是編譯命令里沒有正確指定PLAT參數(shù)ATF默認(rèn)可能在當(dāng)前目錄找不到平臺(tái)目錄于是構(gòu)建系統(tǒng)就報(bào)錯(cuò)或者只生成了一部分中間文件。解決方式很簡(jiǎn)單編譯前先make distclean清理緩存再重新用完整的make PLATmyboard DEBUG1 CROSS_COMPILEaarch64-linux-gnu-命令編譯。還有一個(gè)困擾不少人的點(diǎn)是ATF作為EL3固件用戶態(tài)程序和內(nèi)核態(tài)驅(qū)動(dòng)并不能直接“調(diào)用”它只能通過smc指令陷入EL3。內(nèi)核里一般用smc調(diào)用的helper或者在驅(qū)動(dòng)里直接內(nèi)聯(lián)匯編實(shí)現(xiàn)。用系統(tǒng)調(diào)用去調(diào)ATF是個(gè)繞遠(yuǎn)路思路實(shí)際上ATF對(duì)外暴露的接口主要是面向內(nèi)核的用戶態(tài)基本不會(huì)直接接觸除非你在設(shè)計(jì)某種特殊的安全服務(wù)框架。最后再說一點(diǎn)關(guān)于工具鏈的小建議。有些人在x86的Ubuntu上交叉編譯ATF總喜歡把網(wǎng)上找來的“ARM Compiler 5.06”裝上其實(shí)沒什么必要。用發(fā)行版自帶的crossbuild-essential-arm64或者直接從ARM官網(wǎng)下載aarch64-none-elf工具鏈編ATF都很順暢。至于Clang新版本ATF也支持make CCclang但GCC是最不容易出錯(cuò)的路線。第二點(diǎn)經(jīng)驗(yàn)是調(diào)試期間一定要把DEBUG1加上它會(huì)額外輸出很多INFO級(jí)別的日志雖然慢一些但能極大節(jié)省定位問題的時(shí)間。這套ATF的源碼和平臺(tái)代碼說實(shí)話看一遍不會(huì)全記住但它背后的設(shè)計(jì)邏輯——信任邊界、服務(wù)路由、上下文切換、平臺(tái)抽象——是底層固件通用的一套語言。把這條鏈路走通后再去看其他廠商的EL3實(shí)現(xiàn)基本都能快速對(duì)齊概念。希望這篇帶點(diǎn)“審計(jì)視角”的盤點(diǎn)能幫你少走點(diǎn)彎路。