B站博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydevTrust 在 Rockchip 与 Jetson 平台中的角色与实现从 BL31/BL32 到系统安全服务关键词ARM TrustZone、BL31/BL32、Secure Monitor、SMC/SMCCC、PSCI、OP-TEE、ATF、Rockchip Trust、Jetson Trust本文以 Rockchip 官方《Trust 指南》V1.1.1为主线围绕“Trust 在系统架构里的位置、在启动链路里的作用、在运行期提供的关键能力”展开讲解并在对 Rockchip 机制讲清楚的基础上进一步梳理 Jetson以 Orin 系列为代表在EL3/安全世界上的对应设计从而形成一份“可对照、可落地、可调试”的结构化笔记。0. 先把结论说清楚Trust 到底是什么在工程语境里“Trust”往往不是一个单独的软件项目而是安全世界固件集合的统称。从 ARM 架构视角TrustZone 将系统划分为Normal World与Secure World。安全世界负责关键安全服务与安全资源管控普通世界运行 Linux/Android/Hypervisor 等。从启动阶段视角ATF 术语典型链路用 BL1/BL2/BL31/BL32/BL33 表示。BL31 运行在 EL3提供 Secure Monitor 与运行期服务BL32 常用于 TEE如 OP-TEE等安全世界载荷BL33 通常是 U-Boot/UEFI 等非安全引导程序。从 Rockchip SDK 视角文档定义Rockchip 的 Trust 可以理解为ARM Trusted Firmware偏 BL31 OP-TEE OSBL32的组合64 位平台并以“trust.img”形式交付。因此Trust 让 CPU 具备“世界切换”和“安全世界服务”的那组固件核心是 EL3 Secure-EL1。这也解释了很多现象Linux 内核里调用 PSCI、SMCCC最终会通过 SMC 指令进入 EL3BL31执行Android/Linux 的 TEE ClientCA要调用 TA/PTA仍要通过 SMC 进入安全世界BL31/BL32Trust 出问题时常见现象不是“应用崩了”而是早期启动卡死、CPU 上电/休眠异常、SMC 调用失败、甚至 EL3 panic。1. TrustZone 的“世界划分”与“执行级别”1.1 世界划分安全世界为什么能管住普通世界TrustZone 的核心不是“软件自觉”而是硬件对资源打标总线、内存控制器、外设控制器可将访问请求区分为 Secure / Non-secure安全世界可访问两边资源普通世界只允许访问 non-secure 资源普通世界越界访问 secure 资源往往会触发硬件总线错误或异常。换句话说安全隔离的底座是硬件访问控制而不是软件约束。1.2 执行级别EL3、Secure-EL1 分别负责什么在 AArch6464 位下常见执行级别为EL0用户态EL1内核态Linux kernelEL2HypervisorEL3Secure Monitor安全监控层世界切换入口再叠加世界属性Normal EL0/EL1/EL2普通世界Secure EL0/EL1安全世界TEE/Trusted OSEL3严格意义上属于安全监控层负责世界切换与关键运行期服务Rockchip 文档给出一句非常关键的定位Rockchip 的 Trust 可以理解为 EL3 安全 EL1 的功能集合。这句话可直接映射到工程角色BL31EL3世界切换、SMCCC/PSCI 运行期服务、异常与中断相关的安全处理、平台安全配置入口BL32Secure-EL1TEE OS如 OP-TEE负责密钥派生/安全存储/TA 执行等2. 用一张图把启动链路固定下来BL1/BL2/BL31/BL32/BL33为了后续的对照分析先把“阶段编号”和“工程固件”对应关系写成表ATF 阶段典型职责AArch64 执行态Rockchip 对应文档映射常见产物BL1BootROM加载下一阶段EL3/ROMMaskrom固化在芯片BL2二级引导完成初始化并加载 BL31/BL32/BL33EL3/安全环境Loaderminiloader/loader.bin 等BL31EL3 Runtime FirmwareSecure Monitor/PSCI/SMCCCEL3Trust含 BL31ATF BL31 binaryBL32Secure-EL1 payloadTEE OSSecure-EL1Trust含 BL32OP-TEE OS binaryBL33Non-trusted firmwareU-Boot/UEFINormal EL2/EL1U-Bootu-boot.itb/uboot.imgRockchip 文档给出 Android 启动顺序Maskrom → Loader → Trust → U-Boot → kernel → Android上面这条链路就是你在调试“安全启动/TEE/PSCI”时应该首先对齐的系统时序。3. Rockchip 平台的 Trust架构、固件组织与运行期职责3.1 Rockchip 的实现机制64 位与 32 位的差异文档明确区分64 位 SoC采用ARM Trusted Firmware OP-TEE OS的组合32 位 SoC采用OP-TEE OS文档用语是“32 位平台上使用 OP-TEE OS”工程含义是在 64 位平台上EL3 的 Secure Monitor 与运行期服务由 ATF 提供BL31OP-TEE 负责 Secure-EL1BL32在 32 位平台上历史上存在更多“把安全世界固件打包为一个整体”的交付方式工程上更依赖厂商实现与平台集成方式。本文为了讲清楚逻辑以64 位平台为主。3.2 Trust 固件如何交付trust.img 从哪里来Rockchip 文档强调对外发布通常只提供binary不提供完整源码编译某个平台的 uboot.img 时对应平台的trust.img会被同时打包生成trust.img 的打包通过ini 文件索引完成也可下载独立 rkbin 仓库获取各平台 bin。从使用者视角这里容易踩的坑是你以为“只换 u-boot 就行”但 trust.img 与 u-boot 往往要同版本协同你以为“trust 是一个目录”实际交付常常只有一个 trust.img内部再封装 BL31/BL32 等。建议的工程习惯记录每次烧录的 trust.img 版本来源对应 SDK commit 或 rkbin 版本。通过串口 log 解析 BL31/OP-TEE 的版本号形成“运行态版本证据链”。3.3 Trust 的运行内存布局与生命周期文档给出两个非常硬的数值ARM Trusted Firmware运行在 DRAM 起始偏移 0M~2M入口地址0x1000064KBOP-TEE OS运行在 DRAM 起始偏移 132M~148M各平台略有差异入口地址0x08400000132M并明确Trust 自上电初始化之后始终常驻于内存。工程意义这不是“启动完就走人”的固件而是运行期一直提供服务内存规划冲突会很致命例如 DDR layout、reserved-memory、CMA、IOMMU 映射都可能间接影响 Trust 稳定性当你遇到“休眠/唤醒、CPU hotplug、系统复位异常”时不要只看 kernel往往需要回到 PSCI/BL31 的路径。3.4 Security 边界哪些阶段属于安全世界文档给出清晰划分Loader、Trust运行在安全世界U-Boot、kernel、Android运行在非安全世界安全 driver、APP 除外这能帮助你快速判断“一个功能应该归谁管”早期安全配置TZPC/TZASC/安全 ID 等通常在 Loader/Trust 完成Linux/Android 侧的安全能力如 TEE Client、Keymaster、DRM 框架通常是“普通世界调用入口”真正敏感操作落在 BL32/安全世界。4. Rockchip Trust 的核心功能PSCI、Secure Monitor、平台安全配置4.1 PSCI为什么 CPU 电源管理要放到固件里文档解释 PSCI 的工程动机不同 SoC 的 CPU 电源/时钟/复位设计差异巨大内核不希望维持碎片化实现通过 PSCI内核把“策略”留在内核把“与硬件强相关的执行细节”交给固件。在 Linux 里这体现为CPU 上电/下电、系统 suspend、system reset/off 等都会走 PSCI 接口PSCI 的调用本质是SMC陷入到 TrustEL3由 BL31 执行。你可以把 PSCI 理解为Linux 与 EL3 固件之间的“电源管理 RPC 接口”。4.2 Secure Monitor世界切换的桥Secure Monitor 是 TrustZone 的“交通警察”。普通世界要进入安全世界执行 SMC 指令 → 进入 EL3 → Secure Monitor 切换世界属性 → 跳转到安全世界服务安全世界回普通世界同理经由 EL3 完成切换如果 Secure Monitor 出问题常见症状包括Linux 执行 PSCI/SMCCC 调用卡死TEE Client 调 TA 卡死或直接返回错误早期启动在 “Initializing BL32” 或 “Preparing for EL3 exit” 前后停住4.3 安全信息配置与安全数据保护Trust 的“平台侧责任”文档指出 Trust 还承担TrustZone 相关 IP 的安全信息配置安全数据的保护安全支付、DRM、企业服务等这里的关键理解是BL31 更偏“平台安全配置 运行期服务”BL32OP-TEE更偏“安全应用执行 密钥/安全存储 TA 生态”很多平台把“安全存储”落地为 RPMB、secure partition、或 TrustZone 保护的存储区域这些往往由 BL32 统一管理普通世界只能通过受控接口请求。5. 让 Linux 正确用上 TrustDTS 里把 PSCI 接上Rockchip 文档用较大篇幅强调DTS 使能 PSCI。5.1 内核 4.4 的典型写法推荐对齐关键点只有两个增加 psci 节点声明版本与方法在每个 CPU 节点添加 enable-method “psci”示意按文档给出的范式整理cpus { #address-cells 2; #size-cells 0; cpu0 { device_type cpu; compatible arm,cortex-a53, arm,armv8; reg 0x0 0x0; enable-method psci; }; cpu1 { /* ... 同理 ... */ }; }; psci { compatible arm,psci-1.0; method smc; };5.2 为什么 DTS 这一步很关键因为 Linux 并不会“猜测你有 PSCI”。没有 psci 节点内核可能用不了 PSCI 路径CPU hotplug/idle/suspend 相关能力会异常没有 enable-method即使 psci 节点存在CPU 节点也可能不走 PSCI你在调试“多核上下电、深度休眠、系统复位”时DTS 是第一张清单。6. 现场问题怎么定位开机日志、版本号与 Panic 识别Rockchip 文档给了非常实用的“故障定位入口”。6.1 日志中如何识别 BL31 与 OP-TEE 的输出典型输出风格文档给出的示例非逐字复刻BL31ATFNOTICE/INFO 开头常见行含 “BL31:”OP-TEEINF/ERR 开头含 “TEE-CORE” 等模块名理解建议你在串口里看到 NOTICE: BL31 → 表示 EL3 固件已经开始执行你看到 “Initializing BL32” 或 OP-TEE 的 init 输出 → 表示 BL32 已被加载并开始启动你看到 “Preparing for EL3 exit to normal world” → 表示即将跳转 BL33U-Boot6.2 固件版本号怎么提取文档给出一种直接方法BL31 版本号日志中会出现一个短 hash示例中形如 4c793daOP-TEE 版本号日志中会出现 gxxxxxxxx 形式忽略 g 前缀即可工程意义不要只看文件时间戳运行期日志才是最终证据一旦出现“同一个 trust.img 在不同板子表现不一致”第一步就是对齐 BL31/OP-TEE 版本号6.3 Panic 识别EL3 Panic vs OP-TEE PanicEL3 PanicATF往往会打印 EL3 异常寄存器、x0-x30 等上下文信息OP-TEE Panic常见 “Unexpected page fault” 之类的异常随后 PANIC建议记录完整串口 log含上电到崩溃全部内容。如果平台支持结合 JTAG 更接近根因。优先确认是否 DDR layout、reserved-memory、或 trust.img 与 u-boot/loader 版本不匹配。7. Jetson 的 Trust把“Rockchip 术语”映射过去你已经掌握了 Rockchip 的 Trust 语义现在把 Jetson以 Orin 为代表的体系做一次“同构映射”理解会更快。7.1 Jetson 启动链路的常见分层概念版Jetson 的引导链路名词更多MB1/MB2/UEFI 等并且有多处理器协同如 BPMP。本文采用“对照理解”的方式给出一个与 BLx 模型对应的抽象BootROM ↓ MB1 (平台早期初始化/安全配置常在安全控制处理器上执行) ↓ MB2 (加载并准备后续镜像) ↓ EL3 Runtime (ATF/secure monitor 语义层) ↓ TEE (OP-TEE 或平台 Trusted OS) ↓ UEFI / CBoot (非安全引导程序) ↓ Linux kernel / Android上面这张“概念图”不追求每个镜像的官方命名完全一致而是强调Jetson 同样需要EL3 层来承载 Secure Monitor/SMCCC/PSCI 等职责Jetson 同样会有Secure-EL1 的 Trusted OS/TEE是否启用、以何种形态启用取决于平台配置与发行版Jetson 的早期引导更强调“硬件安全控制器参与初始化”与 Rockchip 的 Maskrom/Loader 模型不同7.2 Jetson 的“Trust”到底指哪一段在 Jetson 语境里“Trust”通常不是一个文件名而是以下能力集合的交集安全启动链Secure Boot chain从 BootROM 开始到引导程序与内核镜像的签名验证密钥材料与硬件熔丝eFUSE设备身份、Root of Trust、公钥 hash、密钥派生基安全世界运行期EL3 TEE世界切换、PSCI/SMCCC、TEE 服务安全存储、派生密钥、TA如果用 Rockchip 的语义映射Rockchip 的 trust.img 更像“把 BL31/BL32 打包后交付”的载体Jetson 的“trust 相关固件”更分散EL3/TEE/安全初始化镜像通常由平台工具链与 flash 流程组合下发并受 fuse 与签名策略约束7.3 Jetson 与 Rockchip 的关键差异对照表维度Rockchip文档主线Jetson以 Orin 代表抽象对照交付形态trust.img封装 BL31/BL32 uboot.img 等多镜像协同MB1/MB2/UEFI/ATF/TEE 等通过 flash 流程组合早期引导命名Maskrom/LoaderBootROM/MB1/MB2平台名词EL3 承载BL31ATF同样需要 EL3 运行期固件secure monitor 语义层TEE 承载BL32OP-TEE常见为 OP-TEE/平台 TOS是否启用与版本相关Linux 侧对接DTS PSCI SMCCCTEE Client同样依赖 PSCI/SMCCCTEE Client 与安全存储策略更与平台发行版绑定调试入口串口日志识别 BL31/OP-TEE 版本panic 分类亦可通过启动日志、签名验证日志、TEE log 排查同时要关注 fuse/签名策略7.4 “同一个概念”的对齐方式用接口而不是文件名最稳妥的对齐方法是看Linux 调用什么接口PSCI/SMCCC/TEE Client看这些接口在硬件上最终落到哪一层SMC → EL3 →必要时跳转到 Secure-EL1也就是说不要陷入“Rockchip 叫 trust.imgJetson 叫 xxx.img”的名词泥潭。接口路径一致工程本质就一致。8. 面向实战的“排查清单”当你怀疑 Trust 有问题下面给出一份跨平台通用的检查顺序由外到内8.1 第一层现象归类先别急着改代码开机停在早期怀疑 Loader/Trust/签名验证链多核异常、CPU 热插拔失败、休眠唤醒异常优先怀疑 PSCI/EL3TEE 调用失败、TA 无法加载、安全存储异常优先怀疑 BL32/TEE 与其存储后端8.2 第二层证据链把版本与日志固定串口 log截取从上电到进入 U-Boot 或 kernel 的完整日志识别并记录BL31 版本、OP-TEE 版本对照当前烧录的 trust.img或 Jetson 的镜像组合来源与版本8.3 第三层配置链DTS/内存布局/启动参数DTSpsci 节点、cpu enable-method、reserved-memory内存OP-TEE 预留区是否被覆盖、CMA/内存碎片化对预留区影响启动参数是否错误设置导致早期内存布局变化8.4 第四层接口链PSCI/SMCCC/SMC内核 dmesg是否有 psci/firmware/rockchip_sip 等相关输出触发点CPU on/off、suspend、system reset 时是否立即异常深入必要时用 tracepoint、ftrace、kprobe 跟踪 psci 调用路径9. 常见误区澄清误区 1Trust Secure BootTrust 与 Secure Boot 强相关但不是同义词。Trust 更偏运行期EL3/TEE与安全世界服务Secure Boot 更偏启动链路的“签名验证/反回滚/熔丝策略”现实项目里两者通常会同时出现因此容易混用。误区 2只要有 OP-TEE 就够了没有 EL3 的 Secure MonitorBL31世界切换与 SMCCC/PSCI 等机制无法完整工作。在 64 位平台里BL31 是基础设施BL32 才是安全应用运行环境。误区 3PSCI 只是内核功能PSCI 的设计目的就是把“硬件强绑定的执行逻辑”放到固件里。内核调用 PSCI仅是发起请求真正让电源状态变化的执行常在 EL3/固件侧完成。10. 总结用“层次模型”掌握 Trust跨平台迁移才不会乱本文围绕 Rockchip《Trust 指南》的主线建立了一个可迁移的层次模型架构层TrustZone 世界划分 EL0/1/2/3 执行级别启动层BL1/BL2/BL31/BL32/BL33 阶段模型Rockchip 映射为 Maskrom/Loader/Trust/U-Boot运行层BL31EL3提供 Secure Monitor/PSCI/SMCCCBL32Secure-EL1提供 TEE 服务对接层Linux 通过 DTS 使能 PSCI通过 SMC 调用进入 EL3再进入安全世界服务调试层串口日志识别版本号、区分 EL3 panic 与 OP-TEE panic建立版本证据链迁移层Jetson 名词体系不同但“接口路径一致、层次职责一致”用映射表可快速对齐如果你正在做“安全启动 TEE 磁盘加密/安全存储 OTA”的完整方案这篇文章可以作为 Trust 章节的骨架先用 BL31/BL32 明确边界再用 PSCI/SMCCC/TEE Client 把普通世界与安全世界的接口闭环最后用日志与版本号把问题定位流程标准化关键问答用于巩固Q1Rockchip 文档里为什么说“Trust 可以理解为 EL3 安全 EL1 的功能集合”**A1**因为在 64 位平台上Trust 的关键职责正落在BL31EL3与BL32Secure-EL1两层前者负责世界切换与 PSCI/SMCCC 等运行期服务后者通常承载 TEE OSOP-TEE执行 TA 与安全存储等能力。两层合在一起才构成平台意义上的“Trust”。Q2为什么必须在 DTS 中写 psci 节点与 enable-method“psci”**A2**因为 Linux 需要通过设备树显式获知“平台的 CPU 电源管理由 PSCI 提供调用方式为 SMC”。缺失 psci 节点或 enable-method内核可能不会走 PSCI 路径从而导致 CPU 上下电、idle、suspend、system reset 等行为异常或不可用。B站博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydev