做系统启动分析的人都知道Android设备的安全边界很大程度由 TEE可信执行环境决定。Trusty TEE 启动分析是移植、调试和优化 Android 安全子系统时绕不开的一步。这篇文章围绕 Trusty TEE 的完整启动链路展开从板子复位后的第一段代码讲起一直讲到 Linux 侧驱动握手内容放在真实 BSP 环境里也基本套得上。适合做系统移植、安全启动验证、驱动开发的朋友参考想深入 TEE 调试的读者也能在里面找到抓手。我会把启动链路里最关键的选择、镜像布局、日志获取方法以及我实际见过的高频问题都拆开说。1. 为什么要把 Trusty TEE 启动单独拿出来分析1.1 TEE 在 Android 里的职责边界Trusty TEE 是运行在 ARM TrustZone 安全世界里的“迷你系统”。它有自己的内核、运行库和用户态 TATrusted Application不依赖 Android 内核和用户态服务。这意味着它要做密钥管理、安全存储、DRM、支付认证、设备认证这类敏感工作并且必须在主系统REERich Execution Environment不可信的前提下保证安全性。我在项目里常把它类比成“大楼里的独立安保中心”。Android 主系统是开放办公区谁都可以进出系统和应用都能申请到这里来办公但真正有价值的保险柜、印章、门禁记录都放在安保中心。Trusty TEE 要做的就是确保安保中心自己的门禁机制从通电那一刻开始就是可靠的。这是 Trusty 启动分析显得特殊的原因普通 Linux 启动出问题可以挂 ftrace、加打印、甚至进 shell 去到处翻但 TEE 启动阶段没有 shell没有网络没有调试器只有 Secure Monitor、极简 Bootloader、串口和共享内存里的日志。一旦启动失败表现往往是外围设备诡异异常、TA 调用直接失败或者设备开机后功能阉割问题极难直接定位。1.2 启动顺序决定安全能力的上限很多人以为 Trusty 只要 ROM 里烧好固件就行开机后 Android 自然会调用它。真实情况是Trusty 必须在 Android 内核跑起来之前先完成初始化。原因很简单Android 内核实现在 SMCSecure Monitor Call调用时需要 Secure World 已经具备完整的异常处理能力。如果 Secure World 里的 TEE 内核还没起来SMC 要么卡死要么直接报错。安全启动链更是如此。BootROM 验证 BootloaderBootloader 验证 TEE 镜像和 Android Boot 镜像TEE 再验证自己的 TA 和配置。信任链上的每一环都有明确顺序前一环必须在后一环启动前完成签名校验和哈希校验。顺序一旦颠倒某个镜像就可以被静态替换安全启动直接失效。所以“启动分析”不是只看 TEE 内核 main() 函数跑通没跑通而是要看整条链上每一步校验发生在哪个阶段、校验结果如何传递、失败后进入什么错误处理流程。这也是文章后面会反复强调信任链的原因。1.3 分析启动需要的基础概念如果要完整分析 Trusty 启动最先要熟悉两套概念。第一套是 Arm 的异常启动模型。从低到高大致有 EL0、EL1、EL2、EL3Secure World 的 TEE 内核通常运行在 S-EL1TA 运行在 S-EL0Arm Trusted FirmwareATF运行在 EL3。EL3 是最高特权级负责切换 Normal World 和 Secure World。很多人第一次看 Trusty 启动被绕晕就是因为分不清 BL2、BL31、BL32、BL33 这些术语。按我的理解BL31 是 EL3 Runtime FirmwareBL32 是 Secure World 里的 TEE 镜像对应 TrustyBL33 是下一级 Normal World Bootloader常见是 UEFI 或 Android Bootloader。第二套是 Trusty 自身的组件划分。Trusty 不只是“一个固件”它由 TEE 内核、App Loader、各类 TA、共享内存驱动、IPC 框架、REE 侧内核驱动、用户态库组成。启动分析习惯上会把 Trusty 拆成 Bootloader 加载阶段、TEE 内核初始化阶段、TA 与服务注册阶段、REE 侧驱动握手阶段四个部分。熟练掌握这套划分后续看日志和抓问题会清晰很多。2. 启动链路设计思路拆解2.1 从 BootROM 到 EL3信任根如何传递Trusty 启动的第一步并不是 Trusty 自己的代码而是 SoC 内置的 BootROM。BootROM 是一段固化在芯片里的 ROM 代码通电后由 CPU 直接执行。它处于最高信任级别负责从 eMMC/UFS/Flash 中加载下一级引导代码并校验其签名和哈希。如果校验失败BootROM 会停止启动或进入救援模式。目前主流 ARM 平台都会在 BootROM 之后引入完整的 ATF 启动流程。简单说BL1通常由 BootROM 充当或与 BootROM 联动加载 BL2BL2 再加载 BL31。BL31 建立 EL3 异常模型并准备好 SMC 路由能力。然后 BL2 还会加载 BL32Trusty TEE和 BL33Normal World Bootloader。信任根传递的关键在于每个加载者都必须验证下一个镜像的身份。BL2 会解析 FIP 镜像包从里面读取 BL31、BL32、BL33 各个镜像的元数据和签名证书计算哈希后与公钥解析出的期望值比对。通过后才把控制权交给 BL31。也就是说Trusty 镜像本身就处于一条“被签名保护的加载链”里。很多安全评审关注的正是这一步BL2 是否强制验证 BL32而不是顺手放行。这里有一个很容易被忽略的细节Trusty 镜像并不是由 Android Bootloader 加载的。常常有人误以为 ABL/U-Boot 启动 Android 内核前会顺手加载 Trusty。实际上在标准的 ATF 流程里BL2 会把 BL32 放到安全内存里并启动 BL31BL31 完成 Trusty 启动后才会把控制权交给 BL33。BL33 只是 Normal World 的引导程序它无法回退再去启动 TEE。这个顺序保证了 Secure World 先于 Normal World 初始化避免 Android 内核在 TEE 缺失的情况下运行任何敏感操作。2.2 BL32 与 BL33 的双世界启动顺序双世界启动顺序可以用一个简单的文本流程表达芯片上电BootROM 执行。BootROM 加载并验证 BL2Trusted Boot Firmware。BL2 解析 FIP验证 BL31、BL32Trusty、BL33。BL2 启动 BL31EL3。BL31 初始化 Secure runtime将 BL32Trusty唤醒。Trusty 完成 TEE 内核、TA、Secure Monitor 回调注册。BL31 将 BL33U-Boot/ABL运行在 Normal World。BL33 加载 Android Kernel Ramdisk。Android Kernel 跟踪 Trusty 驱动建立 IPC 通信。真实 SoC 上执行顺序可能有些变体比如某些平台用自定义 SPL 代替 BL2有些平台的 BL32 在 BL31 之后才加载但总体思想是一致的Secure World 必须先行Normal World 必须在 TEE 就绪后才可见。我调过的一个平台上BL31 启动后会在串口打印“BL31: BL32 加载地址 0xE1000000”然后打印“BL31: BL33 跳转地址 0x9F000000”。看到这两行说明双世界交接完成。当时为了确认 Trusty 是否真的初始化完我们会提前在 Trusty 串口输出里找“trusty_init_done”之类的标志再来对照 BL31 日志。这个顺序带来的工程影响是TEE 的可用内存必须在早期就被保留。BL2 解析设备树或硬件配置时就要把一段安全内存标记为“仅 Secure World 可访问”防止 Normal World 的 Linux 初始化时把这段内存当作普通内存覆盖。很多移植问题出在设备树里没有预留足够 TEE 内存导致 Trusty 启动时分配内存失败或 Linux 在 buddy 分配器里污染了 TEE 内存。2.3 与 Android 内核启动的交接点TEE 启动完成后Android 内核并不需要主动去“拉起”Trusty而是通过 SMC 与 Secure World 通信。Linux 侧驱动加载时会发生一次“握手”但这次握手主要是确认 TEE 驱动的版本兼容性和通信通道是否正常。交接点主要体现在三个地方第一个是设备树中的 reserved-memory。TEE 使用的安全内存会在设备树中标成no-map防止 Linux 建立页表映射。这个节点必须在内核启动早期生效否则内核可能在设备初始化阶段访问到安全内存区域。第二个是 Trusty 驱动的 probe 流程。Linux 驱动框架会匹配设备树节点然后调用trusty_driver_init建立与 TEE 的 virtio 通信通道。如果 TEE 内核尚未就绪probe 会超时或返回错误。这个时间点通常在 late_initcall 阶段已经晚于 ATF 早期初始化。第三个是 TA 服务的注册。Android 用户空间启动后keymaster、gatekeeper、DRM 等 HAL 服务会通过/dev/trusty设备与 TA 通信。TEE 内核里如果服务尚未注册HAL 可能表现为“TA not found”或“transaction failed”。对启动分析来说关注交接点非常值钱很多系统真正的问题不是 Trusty 没起来而是起来之后 Linux 侧没用上比如设备树 compatible 字段不匹配、驱动 probe 顺序偏晚、virtio 队列初始化失败。只看 Trusty 内部日志发现不了这些问题必须两端日志一起看。3. Trusty 固件内部的启动节奏3.1 入口代码究竟做了什么Trusty 的内核基于精简内核的思路设计和完整 Linux 内核不同它没有复杂的设备模型和分层的子系统。它的入口代码功能很集中关中断、设置栈指针、清零 BSS、建立内存映射、启动 MMU然后进入 C 语言的 main()。很多初次看 Trusty 启动的人会惊讶它的启动代码只要几十行就切到了 C 环境不像 Linux 那样需要经过长时间汇编阶段。这并不代表简单而是因为 Trusty 的运行环境收到严格约束。所有设备映射在编译期或启动早期就确定不需要热插拔也不需要页表动态管理等复杂机制。初始化流程大体可以归纳为这些步骤设置异常向量表使能中断。初始化 MMU 和安全内存区域。初始化堆内存分配器。初始化时钟和定时器。初始化 IPC 框架。注册 Secure Monitor 回调接口。加载并启动系统级 TA。进入主循环等待 SMC 或中断请求。每一步都有顺序依赖。比如定时器必须在线程切换之前初始化否则调度就会乱IPC 框架必须在 TA 启动前初始化否则 TA 无法注册服务。调试中如果日志停在“init_trusty_ipc”之后没有任何输出基本不是卡死而是 IPC 注册阶段出现了死锁或循环等待。3.2 内存布局与镜像格式Trusty 镜像通常不是一个 ELF 直接烧到 Flash 里而是会经过工具处理在头部加上版本信息、镜像类型、加载地址和签名数据。Bootloader 从 FIP 中读出 BL32 镜像后会根据头部信息计算加载地址再做哈希校验。头部和实际内容分离的设计是为了让 bootloader 可以在不改动可执行代码的情况下方便地覆盖签名和版本。实际分析时我会把 Trusty 镜像的内存布局拆成三段区域作用典型地址Trusty 内核代码段TEE OS 主体运行在 S-EL1安全内存起始地址动态内存区堆、栈、TA 加载区、共享内存安全内存中后段日志缓冲区通过共享内存或设备映射暴露给 REE 读取固定预留地址这个布局直接影响 Linux 侧 reserved-memory 的配置。如果 Trusty 内核实际使用地址是 0x10000000 开始、大小 4MB那么设备树里必须设置同样的起始地址和大小。很多启动失败案例就是设备树里只留了 4MB但 Trusty 构建时实际上要 8MB初始化后期内存分配失败出现安静死机。镜像格式分析还有一个容易被坑的地方同一份 Trusty 源码调试版和发布版的地址布局可能不一样。调试版会把日志级别调到最高启用更多断言发布版往往会去掉符号、压缩数据段、关掉部分调试接口。版本不匹配时Linux 侧驱动和 TEE 内核通信可能完全正常但功能却不可用。实质上就是镜像中包含了不同的配置选项。3.3 TA 加载和服务注册流程TEE 内核启动到大半时会开始加载系统级 TA。这个过程和 Linux 用户态加载动态库不太一样TA 不是被“exec”出来的而是由 TEE 内核的 TA Loader 从镜像区读取、验证、映射到安全世界用户态并运行的。企业安全设计里TA 镜像通常也要签名。TA 的 manifest 中包含 UUID、版本、入口点、栈大小和堆大小等信息。加载器会验证 TA 头、签名和哈希校验通过后才创建对应的执行环境。这里有一个经常遇到的问题堆大小。TA 运行时的堆由 manifest 指定。如果镜像里的堆大小太小运行时会遇到内存分配失败如果太大又可能挤占其他 TA 的资源。我在某次调试 keymaster 功能时看到 TA 日志里反复出现“alloc failed”后来发现是 manifest 中堆大小被裁剪到 8KB而正常使用需要 32KB。这种问题无法靠调 Linux 侧解决只能改 TA 的配置并重新签名。服务注册顺序也需要重点关注。比如 storage TA 必须先注册然后 keymaster TA 才能依赖它做安全存储如果注册顺序颠倒虽然系统不会立即崩溃但 keymaster 调用底层存储 TA 时会收到“服务不存在”的应答。Trusty 的启动分析里看到 TA 启动日志时要养成记录“哪个 TA 在哪个 TA 之前加载”的习惯。4. 实操抓取和解读 Trusty 启动日志4.1 硬件串口阶段看 Trusty 启动最直接的手段是硬件串口。尤其在 BL31 和 Trusty 初始化早期Linux 还没起来只能靠串口输出。常见串口输出格式会混着 ATF、Bootloader、TEE、Linux 四类日志。要分清它们最有效的方法是在日志里搜索关键字。ATF 日志一般包含BL31、bl31_initBootloader 日志一般包含U-Boot、AndroidBootloaderTrusty 日志一般包含Trusty、trusty_init、TEELinux 日志包含Booting Linux。实际操作中要注意串口权限和转码问题。部分平台把 Trusty 日志放到独立串口需要硬件侧接两路串口共用一路串口时Secure World 和 Normal World 的日志会交错必须依赖时间戳和关键字过滤。最早期的 BootROM 日志通常没有时间戳只能靠先后顺序推断。建议配置内核earlycon让 Linux 早期日志尽早出现在串口方便和 Bootloader 日志对齐。抓日志时一定要在设备树里确认串口的时钟和 pinmux 是否正确。很多板子在移植最初阶段串口不通原因是 pinmux 被华为网关之类的东西搞混乱了。如果串口完全没有输出可以先量硬件电平再确认 bootloader 阶段的流控配置。全套步骤跑通之后再用 minicom/picocom 连续记录不要只抓最后几百行。4.2 Linux 侧通过 dmesg 与 debugfs 检查状态没有硬件串口或者设备已完全启动时可以在 Linux 侧检查 Trusty 状态。常见的方法有四类第一类是 dmesg 搜索 Trusty 相关日志dmesg | grep -i trusty dmesg | grep -i tee正常情况下能看到 trusty 驱动的 probe 成功日志以及 virtio 设备注册信息。如果没有任何输出先确认内核配置里是否包含了 Trusty 驱动比如CONFIG_TRUSTY。有些发行内核默认关闭这个选项就算 TEE 正常在跑Linux 侧也没法通信。第二类是查看设备节点ls -l /dev/trusty* /dev/teec*Trusty 常用设备节点包括/dev/trusty、/dev/trusty-log、/dev/trusty-ipc设备。如果节点缺失很可能是驱动 probe 失败或 udev 规则没有配置。第三类是通过 debugfs 读取 TEE 状态。某些内核配置会创建/sys/kernel/debug/trusty目录里面能看到版本、内存映射、IRQ 统计等信息。cat /sys/kernel/debug/trusty/version cat /sys/kernel/debug/trusty/log第四类是运行带 TEE 的测试服务。比如运行 keymaster 测试用例看能否正常生成密钥。这只是功能验证不能替代完整的启动链检查但如果功能通过至少说明 TEE 和 Linux 侧驱动已经处于可协同的初始状态。4.3 一张日志关键词速查表我自己调试时习惯做一张关键词速查表贴在终端旁边。下面这张表基本覆盖了 Trusty 启动的各个阶段阶段关键词含义加载loading BL32BL2 正在加载 TEE 镜像加载BL32: 0x...Trusty 镜像加载地址确认Trusty初始化trusty_initTEE 内核初始化入口Trusty初始化init_mmu内存管理单元初始化Trusty初始化init_ipcIPC 框架初始化TA加载Loading TA开始加载某 TATA加载TA startTA 入口执行握手trusty_probeLinux 驱动探测握手virtio: registeredvirtio 设备注册日志trusty_logTEE 日志通道建立这张表可以帮助快速定位“卡在哪一步”。如果日志停在init_mmu优先怀疑安全内存布局如果停在Loading TA则优先检查 TA 镜像签名或加载器配置。日志里出现panic、abort、assert的直接 aborted。解析日志时我强烈建议不要只用 grep 过滤error。Trusty 启动过程的错误有很多是“软错误”比如某 TA 加载失败后系统继续启动、某个驱动注册失败但主循环仍然运行这类错误不会以 error 形式明显出现只会在日志中留下Failed to load TA: UUID xxx。所以抓日志时首先确保保存完整镜像再通过时间线划出异常点。5. 高频问题与排查思路5.1 TEE 未启动导致 teec 调用失败用户态程序调用teec_initialize()或TEEC_OpenSession()失败是非常常见的一类问题。很多开发者第一反应是“TA 的问题”但实际上更常见的是 TEE 压根没有启动或者 Linux 侧驱动没有完成 probe。遇到这种失败第一步不是看 TA 代码而是按下面顺序排查确认 dmesg 里有没有 Trusty 驱动 probe 成功日志。确认/dev/trusty设备节点是否存在。直接读 TEE 日志看 TEE 内核有没有跑起来。确认设备树里的 reserved-memory 是否与 TEE 加载地址重叠。确认 ATF 是否加载了 BL32而不是只跳过了 TEE。我曾在一个移植项目里遇到 Vice 场景TEE 日志已经显示初始化完成但 Linux 侧teec_initialize还是失败。后来查下来是 Linux 内核配置里没有启用 Trusty 用户空间访问权限需要设置 SELinux 策略允许某个 HAL 进程访问/dev/trusty。所以这种问题不要只盯着 Secure WorldREE 侧的权限策略同样是排查对象。5.2 Trusty 内核 panic 定位Trusty 内核自身出现 panic 时日志往往很简短就一条程序计数器PC和一个调用栈。由于 Secure World 无法轻易崩溃到 Linux一旦 panic多半表现为设备挂死或重启。定位 panic 要从几个方向入手拿到完整 Trusty 日志。有些内核默认输出最多 64KB 或者限制行数需要在构建时开启完整日志。确认 panic 地址落在哪个模块。如果地址在 TEE 内核代码段内可能是指针错误、越界访问如果在 TA 代码段内更有可能是 TA 自身 bug。检查内存保护配置。Trusty 对 TA 地址空间通常有权限保护如果 TA 访问非法地址会产生 Secure World 数据异常。检查是不是栈溢出。TA 栈太小是常见问题尤其是在处理大块数据时。定位调用的关键工具是符号表。发布版 Trusty 镜像可能不包含符号需要把编译时产生的 map 文件或 ELF 文件对应起来。建议在源码树里找到 vmlinux/trusty 二进制然后使用addr2line将 PC 地址翻译成源代码位置。5.3 启动耗时优化切入点设备开机速度优化时Trusty 启动耗时经常被忽略因为 TEE 初始化在 BL33 之前对 Linux 侧 boottime 的影响看起来不大。但如果你真正测过从电源键到 Android 桌面的完整时间会发现 Trusty 的加密校验、TA 加载、IPC 初始化会占用几百毫秒到一秒不等。优化 Trusty 启动耗时可以从这几个地方动手减少启动时必须加载的 TA 数量。很多 TA 不是开机就要用可以延迟到服务真正调用时才加载。缩短 FIP 中 BL32 镜像的副本大小。镜像越小Flash 读取和哈希校验时间越短。启用硬件加速引擎来完成签名和哈希校验。如果平台支持 crypto engine就别用纯软件 AES/RSA。合理调整串口输出级别。正式发布版本可以采用高日志级别但要知道每行串口打印在早期可能耗掉几十毫秒。时间测量可以通过 ATF 和 Linux 日志的时间戳完成。在 BL31 打印“BL32 loaded”和“BL33 jump”这两条日志之间取差值就是 Trusty 启动的大致耗时。拿到数字后再逐段优化效果更明显。5.4 版本不匹配与升级坑Trusty TEE 镜像和 Linux 驱动之间并不是完全解耦的。IPC 协议、virtio 队列布局、TA 接口版本可能随版本调整。如果升级了 TEE 镜像却不同步升级 Linux 驱动会出现启动正常但 TA 功能偶发异常的情况。典型的症状是dmesg里 trusty 驱动加载成功但调用某个特定 TA 时返回NOT_FOUND或OUT_OF_MEMORY。常见原因包括 UUID 变更、扩展接口号定义不匹配、共享内存大小结构体不一致。升级维护建议是把 Trusty 镜像版本号和 Linux 驱动版本号都固化到构建产物里并在 TEE 与 REE 握手时互相校验版本。不要在设备树里写死某个 magic 字节也不要只用 Git 提交号来区分提交号在发布裁剪后的代码树里经常对不上。刷机升级时还有一个常见坑刷写工具只刷了 Android boot 分区没有更新 FIP 里的 BL32导致 BL2 校验 BL32 时发现哈希与上次不同直接进入错误状态。这时必须使用完整的 firmware 包升级而不是只刷 boot.img。若板子刚好支持 fastboot可用如下命令刷新 FIP 后重启检查日志fastboot flash fip fip.bin fastboot reboot重启后如果看到BL2: BL32 mismatch之类日志说明 FIP 内的镜像没有被正确刷新需要重新检查分区表。6. 验证一个 TEE 启动是否合格6.1 用自测 TA 做连通性验证判断 Trusty 是否真的可用光看日志还不够要跑一个能产生具体输出的自测 TA。我通常会在 TEE 里放一个简单 TA只暴露两个操作一个生成随机数一个做哈希计算。Linux 侧写一个小工具调用它验证数据和预期一致。示例工具伪代码如下TEEC_Result invoke_random( TEEC_Context *ctx ) { TEEC_Session session; TEEC_Operation op; uint32_t random[8]; TEEC_OpenSession(ctx, session, TA_UUID, ...); op.paramTypes TEEC_PARAM_TYPES(TEEC_MEMREF_TEMP_OUTPUT, TEEC_NONE, TEEC_NONE, TEEC_NONE); op.params[0].memref.buffer random; op.params[0].memref.size sizeof(random); TEEC_InvokeCommand(session, TA_CMD_GET_RANDOM, op, NULL); TEEC_CloseSession(session); }如果随机数每次不同哈希结果正确说明从用户态到 TEE 的完整链路是通的。这个验证应在每次改动 TEE 镜像或 Linux 驱动后进行跑完再进其他安全功能测试。6.2 安全启动和回滚保护验证连通性验证只是起点安全启动验证要检查的是攻击面。具体包括BL2 是否强制校验 BL32 签名。BL32 是否强制校验 TA 签名。是否支持回滚保护。刷入旧版本 TEE 镜像时会被拒绝。是否有 JTAG/SWD 调试接口被关闭。一个常见做法是想办法构造一个“伪造”的 BL32 镜像比如修改 FIP 中的 BL32 字节后重新签名。如果启动链正确设备应该在 BL2 阶段拒绝启动并打印签名验证失败日志。如果设备反而启动了说明信任链存在严重缺陷。回滚保护测试则相对简单把先前保存的旧版 TEE 镜像刷入设备正常启动。如果系统能识别版本低于当前底线并拒绝加载说明回滚保护已生效如果直接启动说明版本比较逻辑没生效。这项测试不要跳过很多设备在量产一段时间后才暴露回滚漏洞。6.3 异常注入测试最后说一说异常注入。很多团队把异常注入想得很复杂其实在启动分析阶段只需要关注三类输入第一类是内存映射错误。故意把设备树里的 reserved-memory 地址写错观察 Trusty 是 panic 还是安全退出。一个健壮的启动流程应该能检测到异常内存并报告明确错误。第二类是中断风暴。在 TEE 启动早期向 Trusty 发送重复 SMC 或触发大量中断观察系统是否有死锁和数据竞争。这类测试跑在实验室里比较方便可配合脚本持续加压。第三类是 TA 异常输入。把超过 TA 预期的长参数传递进去观察 Secure World 是否出现越界访问。如果 TA 直接崩溃说明内存检查不足如果返回错误码但系统没有复位则说明基础防护是有效的。异常注入做完后要记录清楚设备状态、日志文件、复现条件。不要只看一次通过就放行我见过有些异常是概率性触发必须用固定脚本连续跑 24 小时以上才稳定复现。把异常注入放进自动化启动测试里每次合代码前跑一遍比等签发放行后再补救要省太多时间。最后分享一个我自己的小习惯每块新板子第一次跑 Trusty 启动前我都会先做一个最小镜像只启动 TEE 内核和一个最简单的空 TA。确认这条路通了再往上加服务、加功能。少一次“引入新 TA 导致启动挂死”的排查就少一次在串口面前盯到凌晨的体验。Trusty 启动不像普通 Linux 启动那样能随手拉个 ftrace 解决它能依赖的只有日志和信任链把这两个东西捋顺大部分问题都跑不掉。
