聊ATFArm Trusted Firmware現(xiàn)在更多叫 TF-A之前我先說個事。最近在幫客戶做新平臺 bring-up一位做內(nèi)核的老手問我我們的 U-Boot 都從存儲介質(zhì)里跑起來了為什么還非要先跑一段什么 BL31這個問題我太熟悉了。很多人能把 U-Boot 和 Linux 玩得飛起但 U-Boot 之前那幾百 KB 安全固件在干什么卻很少有人真正關(guān)心。直到業(yè)務(wù)要做安全啟動、要上 TEE、要過運營商或行業(yè)認證才回過頭來啃 Arm Trusted Firmware。這篇東西我打算直接從源碼層把 ATF 的架構(gòu)拆一遍把安全固件工程審計要看的點梳理一遍再把平臺移植落地這條主線走一遍。相當(dāng)于一份“源碼測評 工程審計 移植實戰(zhàn)”的三合一記錄。對剛接觸 ATF 的人可以當(dāng)成一份少走彎路的路線圖對已經(jīng)在做固件和 BSP 的人也可以對照檢查自己平臺實現(xiàn)里有沒有埋坑。1. 為什么需要 ATFARM 安全固件的底層邏輯1.1 沒有 ATFTrustZone 只是一句口號ARM 的 TrustZone 技術(shù)大家應(yīng)該都聽過把一個物理核分成安全世界Secure World和非安全世界Normal World通過 SCR_EL3 等系統(tǒng)寄存器的 NS 位來切換上下文。問題是上電之后誰來初始化這個安全環(huán)境非安全世界的代碼可不可以直接訪問安全內(nèi)存Secure Monitor CallSMC指令觸發(fā)之后又是誰來分發(fā)處理這些活兒總得有人干。不搞 ATF當(dāng)然也可以很多老平臺就是自研一段 Monitor 代碼放在 EL3專門做 SMC 分發(fā)和世界切換。但這帶來的問題很實際每個芯片廠各寫一套接口五花八門OP-TEE 不知道該怎么對接U-Boot 想調(diào) PSCI 接口也得適配不同固件。這就是 ATF 存在的意義——它是 ARM 官方提供的、跑在 EL3 的開源安全固件參考實現(xiàn)定義了從 BL1 到 BL31 的標準啟動流程同時規(guī)定了 PSCI、SMC、TBBR 這些標準接口。有了它TEE 廠商、OS 廠商、芯片廠商才不用互相遷就對方私有協(xié)議。1.2 ATF 在整個 ARM 生態(tài)中的位置在 arm64 平臺正常啟動鏈里順序一般是BootROM - ATF BL1 - ATF BL2 - ATF BL31 OP-TEEBL32 U-Boot/UEFIBL33- Kernel。BL31 常駐 EL3充當(dāng)整個世界切換的“守門員”。你可以把 BL31 理解成一座大樓的門禁系統(tǒng)非安全世界的 App 想進安全世界辦點事得先把 SMC 請求遞給門禁門禁查驗身份、轉(zhuǎn)發(fā)給對應(yīng)服務(wù)再把結(jié)果帶出來?，F(xiàn)在主流 ARMv8 / ARMv9 的高速 SoC從手機芯片到服務(wù)器芯片幾乎都在用 ATF 作為 EL3 固件底座。即使芯片廠商有自研的 secmonitor多半也會在 SIPSilicon Provider接口上兼容 ATF 的調(diào)用風(fēng)格因為生態(tài)已經(jīng)綁定了。這就是為什么做底層開發(fā)和整機安全的工程師沒法繞開它。2. ATF 源碼架構(gòu)全景從 BL1 到 BL312.1 啟動分區(qū)BL1/BL2/BL31/BL32/BL33 各憑本事ATF 把固件拆成多個啟動階段每一級都有明確職責(zé)。BL1Boot ROM通常固化在芯片 ROM 或 OTP 區(qū)上電最先執(zhí)行。它做最基本的 CPU 初始化、設(shè)定 EL3 異常向量、加載 BL2 并做安全校驗。BL2Trusted Boot Firmware運行在 EL1 Secure 狀態(tài)負責(zé)初始化 DDR、加載 BL31、BL32、BL33并校驗鏡像簽名。U-Boot 和 OP-TEE 的鏡像都由它搬到內(nèi)存里。BL31EL3 Runtime Firmware運行在 EL3是常駐的監(jiān)控器。負責(zé) SMC 分發(fā)、PSCI 電源管理、Secure-EL1 插樁、安全中斷處理等。kernel 和 U-Boot 調(diào) PSCI 指令實際執(zhí)行方就是 BL31。BL32Optional TEE OS例如 OP-TEE、Trusty、QSEE跑在 Secure EL1。BL31 負責(zé)完成安全世界上下文切換讓 TEE 可以執(zhí)行安全服務(wù)。BL33Normal World Bootloader就是 U-Boot、UEFI 等最終引導(dǎo) Linux/Windows/RTOS。每次世界切換不只是把 PC 指過去還要搞定寄存器上下文、中斷、MMU 頁表、內(nèi)存權(quán)限。ATF 在lib/el3_runtime/aarch64/context_mgmt.c里維護了一套cpu_context結(jié)構(gòu)把通用寄存器、系統(tǒng)寄存器、安全狀態(tài)、中斷路由等全部打包管理。這也是我最推薦的閱讀起點看懂 context 管理ATF 的一半就通了。2.2 源碼目錄與關(guān)鍵文件把工程地圖畫出來直接用克隆下來的源碼說事。ATF 倉庫根目錄下有這些一級目錄最值得關(guān)注的是bl1/、bl2/、bl31/各啟動階段主體代碼。plat/平臺相關(guān)代碼芯片廠商新平臺基本都從這里的參考板 copy。plat/arm/board/下有 FVP、Juno 等 ARM 官方板。plat/qemu/是 QEMU virt 平臺支持非常方便學(xué)習(xí)。plat/rockchip/、plat/mediatek/、plat/nxp/等是社區(qū)維護的實際 SoC。lib/el3_runtime/EL3 運行時核心SMC 分發(fā)、上下文管理都在這里。lib/psci/PSCI 標準實現(xiàn)。lib/xlat_tables/、lib/xlat_tables_v2/MMU 頁表與內(nèi)存翻譯表安全隔離的關(guān)鍵。drivers/arm/ARM 官方外設(shè)驅(qū)動比如 GIC、TZC400、DMC500、CCI/CCN。services/SMC 服務(wù)登記與實現(xiàn)std_svc、arm_arch_svc、spm 等。tools/cert_create/生成證書鏈的工具。tools/fiptool打包 FIP 鏡像的工具。我一般拿到一個新平臺源碼先看plat/vendor/board/platform_def.h。這個文件基本把這塊板子的 SRAM 大小、BL31 加載地址、外設(shè)基址、GIC 布局全定義了相當(dāng)于一個“平臺身份證”。然后看plat_setup.c、bl31_plat_setup.c這類入口初始化文件再去看 GIC 和串口驅(qū)動接入方式比悶頭從 BL1 入口讀快得多。git clone https://github.com/ARM-software/arm-trusted-firmware.git cd arm-trusted-firmware # 以QEMU虛擬平臺為例先看幾個關(guān)鍵文件 ls plat/qemu/ cat plat/qemu/platform_def.h實戰(zhàn)經(jīng)驗是ATF 閱讀不建議按啟動順序從頭讀到尾。BL1 是 ROM 代碼與 SoC 內(nèi)部 BootROM 強相關(guān)通用部分不多BL2 只是個“搬運工校驗器”邏輯相對直白真正的重頭戲在 BL31。把 BL31 的初始化流程、SMC 分發(fā)、PSCI 實現(xiàn)看明白工作中 90% 的問題都能定位到方向。2.3 關(guān)鍵服務(wù)PSCI、SMC 分發(fā)、TBBR 信任鏈PSCIPower State Coordination Interface是 ATF 對外最核心的服務(wù)。U-Boot 和 Linux 在非安全世界不能像裸機那樣隨便關(guān)核、開核、操作電源管理而是通過 SMC 指令把請求交給 BL31 處理。PSCI 在lib/psci/下實現(xiàn)提供 CPU_ON、CPU_OFF、CPU_SUSPEND、SYSTEM_OFF、SYSTEM_RESET 等標準調(diào)用。以 CPU0 啟動 CPU1 為例流程大致是Normal World 執(zhí)行SMC #0攜帶PSCI_CPU_ON_AARCH64參數(shù)。CPU 陷入 EL3ATF 的 SMC 分發(fā)器根據(jù) Function ID 找到 PSCI 服務(wù)。PSCI 內(nèi)部調(diào)用平臺提供的pwr_domain_on操作。在目標 CPU 上被喚醒后進入 BL31 的入口完成上下文初始化再將 PC 設(shè)置成 Normal World 指定的 entry point。在實際調(diào)試中我見過太多“CPU1 起不來”“suspend 后喚醒崩潰”的問題最后都落在 PSCI 平臺操作上。ATF 本身提供了 for 循環(huán)、spinlock、cache 維護等通用邏輯但具體到每個核的 power domain 怎么開、GIC 的 SGIs 怎么路由、鎖 cache 的地址在哪每個芯片差異非常大。SMC 分發(fā)機制是 ATF 作為 Monitor 的“總前臺”。SMC 指令以 32 位 Function ID 區(qū)分服務(wù)。ATF 用DECLARE_RT_SVC()宏注冊 runtime service這些服務(wù)描述符會放在一個指定的鏈接段里運行時根據(jù) Function ID 范圍RT_SVC_DESC逐一比對。寫一個自定義的安全 monitor 調(diào)用本質(zhì)上就是注冊一個服務(wù)在smc_handler里判斷參數(shù)然后返回結(jié)果。代碼位置主要在bl31/bl31_main.c和lib/el3_runtime/aarch64/runtime_exceptions.S。TBBRTrusted Board Boot是 ATF 提供的安全啟動參考實現(xiàn)。它定義了一套證書鏈每個鏡像都有一張證書證書里包含鏡像 HASH 或公鑰上一級證書用私鑰簽名最底層信任根存在 SoC eFuse 或 OTP 中。tools/cert_create生成證書tools/fiptool打包 FIP 鏡像。啟用安全啟動需要同時打開TRUSTED_BOARD_BOOT1和GENERATE_COT1并在 BL1/BL2 中實現(xiàn) ROTPK 讀取。這部分是所有安全認證如 PSA、行業(yè)安全評估的硬指標我對它的定義是沒有 TBBR安全固件審計就缺少第一塊基石。3. 安全固件工程審計代碼層面到底查什么3.1 啟動信任鏈證書與鏡像校驗如何串成一條線安全固件審計的第一件事就是驗證“信任鏈是否閉環(huán)”。ATF 的 TBBR 設(shè)計的是層級認證BL1 被認為是 BootROM 固化邏輯自帶信任根BL1 驗證 BL2 的證書與鏡像BL2 驗證 BL31、BL32、BL33。審計時重點看三處ROTPK 的存放與讀取是否真的綁定到 eFuse/OTP還是編譯期間寫死在代碼里。證書格式和 signature 算法是否支持 SHA256/RSA2048 及以上安全強度。很多老方案還在用 ECC 192 或 RSA 1024放到今天已經(jīng)不適合過安全評估。失敗處理路徑。鏡像校驗失敗后是死機、進入恢復(fù)模式還是直接跳過去后一種是致命的。我審計過一個平臺BL2 校驗 BL31 用的公鑰是從 FIP 包里讀的而不是從 TrustAnchor 里取的。這意味著攻擊者如果篡改 FIP 的同時替換掉公鑰和簽名BL2 依然能通過校驗。這種問題在代碼 review 時很容易被漏掉因為它不是崩潰、不是死循環(huán)而是“校驗邏輯寫得像模像樣但信任根被架空了”。3.2 內(nèi)存與權(quán)限隔離xlat_tables 和 TZC 的配合ATF 里的“安全內(nèi)存”不是說說而已它有兩層防護。第一層是 CPU 內(nèi)部 MMU 頁表的權(quán)限管理第二層是總線層面的 TrustZone Address Space ControllerTZASC/TZC對物理內(nèi)存區(qū)域的訪問控制。lib/xlat_tables_v2負責(zé)構(gòu)建 BL31 的頁表。每個區(qū)域的屬性都會標上MT_SECURE/MT_NS、MT_RO/MT_RW、MT_EXECUTE_NEVER等。審計時要一塊塊地圖對照BL31 自己的.text段必須是 Secure RO棧和設(shè)備寄存器是 Secure RWNormal World 能訪問的區(qū)域絕對不能帶 Secure 屬性也不應(yīng)該有執(zhí)行權(quán)限。很多漏洞來自mmap_add_region時權(quán)限寫寬了比如把某個非安全外設(shè)的地址誤標成 Secure或者把 Secure 內(nèi)存標成了可執(zhí)行?？偩€層面的 TZC 是最后一道閘門。它按地址區(qū)間設(shè)置訪問權(quán)限非法訪問會被硬件攔截。我在新平臺 bring-up 時就吃過虧BL31 已經(jīng)起來了但 OP-TEE 的共享內(nèi)存一訪問就 panic查半天發(fā)現(xiàn)是 TZC 配置里非安全世界根本沒有放行那塊 shared memory。這類問題沒有捷徑只能把platform_def.h里的內(nèi)存布局和 TZC 配置逐一對照核驗。審計要點表我通常做成下面這種速查表帶在項目里審計項檢查內(nèi)容常見問題ROTPK / TrustAnchor公鑰來源是否為硬件信任根公鑰從 FIP 讀取、可被替換BL2 鏡像校驗算法是否 SHA256/RSA2048 以上算法強度不足或未比較完整哈希FIP 包完整性證書、鏡像嵌套結(jié)構(gòu)是否有冗余校驗失敗后仍繼續(xù)啟動xlat 頁表權(quán)限Secure/NS、RO/RW、XN 標記權(quán)限標寬、可執(zhí)行內(nèi)存暴露TZC 地址區(qū)間NS 世界能訪問的物理內(nèi)存范圍共享內(nèi)存配置錯誤導(dǎo)致 panicGIC 安全配置Secure 中斷組與路由安全中斷被路由到 Normal WorldBL31 入口異常向量未定義指令、SError 處理處理函數(shù)棧溢出或死循環(huán)PSCI 返回碼電源操作失敗是否返回錯誤靜默失敗導(dǎo)致內(nèi)核 hang3.3 常見審計點清單代碼 review 時必須盯的洞除了信任鏈和內(nèi)存權(quán)限實際工程里還有幾個點很容易翻車。GIC 安全配置。ARM GIC 把中斷分成 Group0Secure和 Group1。ATF 里通過plat_arm_gic_driver_init、gicv3_driver_init初始化 GIC審計時要確認安全中斷比如 TEE 的 SGI、GT 定時器中斷配置到了 Group0而且中斷路由沒被異常改寫。如果 Group0 中斷被誤配到非安全世界等于開了一個通道讓 Normal World 能觸發(fā)安全中斷后果可想而知。異常向量與棧保護。BL31 的異常向量表在bl31/aarch64/bl31_entrypoint.S中每個異常入口都要有足夠大小的棧。低端平臺 SRAM 緊張時棧大小會被壓縮得很極限審計時要算一算嵌套異常的最大棧深度。我見過一個平臺安全中斷出現(xiàn)時 BL31 棧溢出直接踩壞了相鄰的.bss導(dǎo)致系統(tǒng)隔幾個小時隨機重啟一次查了很久才定位到。信息泄露。BL31 的錯誤日志和 panic 打印不要過度暴露內(nèi)存地址。生產(chǎn)固件一般會關(guān)掉 DEBUG 構(gòu)建用NOTICE/ERROR控制打印級別。如果審計時看到printf把 buffer 原始內(nèi)容打出來就要警惕敏感數(shù)據(jù)泄露風(fēng)險。4. 平臺移植落地從零把 ATF 跑起來4.1 選參考平臺與目錄組織移植 ATF 第一步不是寫代碼而是“抄作業(yè)”——從現(xiàn)有平臺里找最接近的參考實現(xiàn)。如果你在調(diào) QEMU 虛擬環(huán)境直接用plat/qemu。如果是自研 SoC找相同內(nèi)存控制器、類似 GIC 版本、相近啟動介質(zhì)的設(shè)計參照。比如新平臺 GIC 是 GICv3就重點參考plat/arm/board/fvp的實現(xiàn)。如果底層方案和樹莓派類似可以看plat/rpi。目錄組織一般是plat/vendor/ board/ platform_def.h # 平臺地址、大小、外設(shè)基址 platform.mk # 編譯選項、額外源文件 plat_setup.c # 平臺初始化 aarch64/ plat_helpers.S # CPU 操作、互斥、cache 等匯編 bl31_entrypoint.S # BL31 入口鉤子如需自定義最省事的做法是直接cp -r plat/arm/board/fvp plat/xx/yy然后把平臺名、地址、GIC 配置全部改掉。ATF 的make系統(tǒng)支持PLATplatform選擇平臺目錄你可以完全復(fù)用一個參考板再剪裁。4.2 平臺配置與 make 參數(shù)ATF 頂層目錄有一個Makefile會讀取plat/vendor/board/platform.mk。平臺移植時最常調(diào)整的宏包括宏/變量含義PLAT_MAKEFILE平臺 Makefile 路徑CRASH_REPORTING崩潰時是否打印寄存器現(xiàn)場BL31_BASE/BL31_SIZEBL31 加載地址和大小TRUSTED_BOARD_BOOT啟用 TBBR 安全啟動GENERATE_COT編譯時生成證書鏈ARM_ARCH_MAJOR/MINOR架構(gòu)版本例如 8.2HW_ASSISTED_COHERENCY是否依賴硬件緩存一致性USE_COHERENT_MEM是否使用 coherent memory 區(qū)域交叉編譯的基本命令是make CROSS_COMPILEaarch64-none-elf- PLATqemu DEBUG1 bl31如果想生成 FIP 鏡像需要指定BL33指向你的 U-Boot 鏡像make CROSS_COMPILEaarch64-none-elf- PLATqemu BL33../u-boot/u-boot.bin fip注意DEBUG1會加大鏡像體積、降低優(yōu)化等級只用于調(diào)試量產(chǎn)固件不要用。4.3 移植時最容易被卡住的四個點第一BL31 起點和鏈接布局。如果 BL31 被加載到錯誤地址開機會立刻崩。要仔細核對platform_def.h里的BL31_BASE和 SoC BootROM 實際加載地址以及 BL2 傳給 BL31 的入口參數(shù)是否一致。第二串口驅(qū)動。調(diào)試初期最需要串口可它往往是最早依賴平臺寄存器配置的模塊。ATF 常見的串口有console_16550、console_pl011、console_cadence等。如果 SoC 用的不是標準 IP就得在plat_setup.c里自建 console 接口。沒有串口輸出時一切問題都像黑匣子所以先把串口點亮是最優(yōu)先任務(wù)。第三GIC 初始化。BL31 跑起來后,GIC 要在 EL3 配好中斷路由。新的 GICv3 還涉及GICRredistributor 初始化每個核有自己的 redistributor 寄存器漏配會導(dǎo)致中斷根本無法送達。初始化順序錯了會看到中斷風(fēng)暴或者 CPU 被 Security 中斷反復(fù)打斷動不動就 hang。第四PSCI 的電源操作。這一塊最芯片相關(guān)。plat_setup_psci_ops要提供cpu_standby、pwr_domain_on、pwr_domain_off、system_reset、system_off等回調(diào)。每個回調(diào)都要處理好 cache、MMU、GIC、以及核間喚醒邏輯。我建議第一次移植只實現(xiàn)pwr_domain_on和system_off先把系統(tǒng)和多核跑起來再去碰 suspend/resume 這些高級狀態(tài)。4.4 以 QEMU 為例跑通最小系統(tǒng)沒有真實開發(fā)板時QEMU 是最低成本的驗證手段。ATF 源碼里已經(jīng)帶了plat/qemu理論上直接編譯就能跑。步驟如下下載 U-Boot 并編譯出u-boot.bin。編譯 ATF生成bl1.bin、bl2.bin、bl31.bin和fip.bin。用 QEMU 啟動wget https://releases.linaro.org/components/kernel/uefi-linaro/latest/release/qemu/aarch64/QEMU_EFI.fd # 可選 make CROSS_COMPILEaarch64-linux-gnu- PLATqemu BL33/path/to/u-boot.bin fip qemu-system-aarch64 -machine virt,secureon -cpu cortex-a57 -nographic \ -bios bl1.bin -m 1024這里-machine virt,secureon是關(guān)鍵的它讓 QEMU 模擬出 EL3 和 TrustZone 環(huán)境。如果看到 ATF 的啟動打印再從 BL31 跳到 U-Boot那你的 ATF 最小系統(tǒng)就算通了。真機移植時會比 QEMU 多很多坑比如 BootROM 加載 BL1 的限制、DDR 初始化時序、eFuse 安全位、內(nèi)部 SRAM 大小不足等。但核心思路一致先把串口點亮再把啟動鏈走通接著做地址和權(quán)限二次確認最后再做安全啟動。5. 實操作戰(zhàn)我的“問題與排查”記錄5.1 編譯與鏈接階段的坑ATF 編譯報錯里最高頻的是CROSS_COMPILE沒設(shè)置或工具鏈不匹配。ATF 要求 GCC 工具鏈支持 aarch64并建議使用 GNU 工具鏈。經(jīng)常有人問為什么make之后報一堆匯編錯誤檢查后發(fā)現(xiàn)用的還是 x86 的gcc。這個錯誤在make階段就會暴露換個aarch64-none-elf-或aarch64-linux-gnu-即可。第二個典型問題是BL31 鏡像超出 SRAM 大小。鏈接時報region overflow比如bl31.elf超出BL31_SIZE。解決辦法不是盲目加大BL31_SIZE而是先確認編譯選項是不是 DEBUG 全開、是否有冗余驅(qū)動被編進來再調(diào)整內(nèi)存布局。第三個問題是鏈接腳本里的 section 對齊問題。有些平臺修改platform_def.h后.text或.bss的起始地址沒有對齊到頁表粒度導(dǎo)致 MMU 建頁表時異常。ATF 啟用了PAGE_SIZE一般 4KB對齊檢查如果地址不對齊早期會給出Translation fault。移植時改BL31_BASE一定要保證 4KB 對齊。5.2 運行時異常與 PSCI 調(diào)試驗證運行時遇到Synchronous Exception是最常見的情況。先打開CRASH_REPORTING1編譯能看到 crash 時異常類型、ELR、SPSR 和 ESR。常見異常原因ESR_ELx.EC 0x25EL3 中發(fā)生了SMC說明調(diào)用參數(shù)可能沒走對服務(wù)。EC 0x20Instruction Abort from current EL或 0x21PC alignment fault多半是跳轉(zhuǎn)地址不對。EC 0x21 也可能是 BL31 跳到 U-Boot 時入口地址錯誤。PSCI 調(diào)用驗證有一個很實用的工具就是直接在內(nèi)核里操作 CPU 熱插拔或 suspend/resume。但這屬于“大動作”一旦失敗整個系統(tǒng)就 hang 住不太適合調(diào)試早期。我習(xí)慣先在 U-Boot 階段用psci命令手動調(diào)一下 CPU_ON看看目標核是否起來、能否打印一段自定義輸出。這樣能快速排除 PSCI 實現(xiàn)的問題。另外調(diào) PSCI 時最好用SET_RUNTIME_SVC自定義一個調(diào)試服務(wù)通過 SMC 直接觸發(fā)某個核的 on/off 操作不用依賴內(nèi)核的 hotplug 框架。這樣查問題更精準。5.3 與 U-Boot / OP-TEE 聯(lián)調(diào)經(jīng)驗ATF 不是孤立的它總是和 BL33U-Boot和 BL32OP-TEE配合。聯(lián)調(diào)時最容易踩的坑是FIP 包順序和參數(shù)傳遞。BL2 在加載完 BL31/BL32/BL33 之后通過plat_get_next_bl_params把各個鏡像的入口地址、上下文信息傳給 BL31。如果 BL33 entrypoint 地址不對U-Boot 根本起不來。尤其注意 U-Boot 編譯時如果啟用了CONFIG_ARMV8_MULTIENTRY或者CONFIG_PSCI_0_2它和 ATF 之間的入口約定必須一致。很多“U-Boot 沒反應(yīng)”的問題其實是 ATF 側(cè)傳給 BL33 的 DTB 地址或 firmware handoff 參數(shù)格式不匹配。OP-TEE 聯(lián)調(diào)時BL31 需要配置SPDopteed編譯開關(guān)表示能通過 OP-TEE Dispatcher 把上下文切到 Secure EL1。此時 BL31 不只做 PSCI還要負責(zé) OP-TEE 的啟動與SMC轉(zhuǎn)發(fā)。OP-TEE 起不來的常見原因安全內(nèi)存區(qū)域的TZC沒配、OP-TEE 加載地址與鏈接地址不一致、SPD 沒編譯進 BL31。在make時加入make ... SPDopteed BL32../optee_os/out/arm/core/tee.bin BL33../u-boot/u-boot.bin fip這樣 FIP 中就會包含 BL32 鏡像。OP-TEE 啟動后通過xtest跑 TEE 用例再回正常世界基本能驗證整個安全世界鏈路。6. 最后一點個人心得與建議做 ATF 移植和審計這幾年我最大的體會是不要只把它當(dāng)成一段“引導(dǎo)代碼”。它其實是整個 ARM 安全架構(gòu)的承重墻。U-Boot 可以隨便換、Kernel 可以朝后兼容但 EL3 固件一旦出了問題輕則多核啟動失敗重則給整個系統(tǒng)留下一個無法用上層補丁修復(fù)的漏洞。如果你剛接觸 ATF我個人建議的路線是先用 QEMU 跑通最小啟動鏈再把 context manage、SMC 分發(fā)和 PSCI 三個核心模塊源碼精讀一遍然后嘗試在 QEMU 里增加一個自定義 SMC 服務(wù)。不要一上來就撲到真機上做移植那會被串口初始化、DDR training、GIC redistributor 一堆硬件問題淹沒。另外想提醒一句安全固件審計這件事最忌諱的就是只看“代碼跑得通”。跑得通只能證明功能正常不代表安全邊界正確。ATF 這類固件審計的每一處內(nèi)存屬性、每一個外設(shè)安全配置都要拿“如果 Normal World 被攻破這扇門會不會被推開”的標準重新審視一遍。畢竟這條 TrustZone 邊界是整臺設(shè)備最后的安全底線。