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