3、高通ABL详解：ABL启动流程、ABL与XBL的交互、ABL中的安全策略
好，咱们接着往下聊。上一章我们把XBL（Boot ROM + PBL + SBL）的启动链路捋了一遍，说白了就是硬件初始化、DDR训练、加载镜像这些脏活累活。那XBL干完活之后，谁来接棒？就是今天的主角——ABL（Application Boot Loader）。
我个人习惯把ABL看作是整个启动链路上的“大管家”。它不直接操作寄存器，也不管DDR时序，它管的是策略、是安全、是系统镜像的校验和加载。你想想看，XBL把硬件环境搭好了，ABL就要决定：到底该启动哪个系统？是正常的Android？还是Recovery？还是Fastboot？
3.1 ABL启动流程：从XBL手里接过指挥棒
ABL的入口其实很简单。XBL在完成所有硬件初始化后，会从指定的存储分区（通常是boot分区或者abl分区）把ABL镜像加载到DDR中，然后跳转过去。ABL拿到控制权后，第一件事就是初始化自己的运行环境。
ABL启动的核心步骤，我总结为以下几步：
- 自检与重定位：ABL会先检查自己是不是在正确的位置上运行。如果不是，它会把自己搬到预定的内存地址去。这一步很关键，因为后续的代码都依赖固定的地址映射。
- UEFI环境初始化：ABL是基于UEFI（统一可扩展固件接口）框架的。它会初始化UEFI的运行时服务、启动服务，以及各种Protocol（协议）。说白了，就是搭好一个“软件生态”，让后续的驱动和App能跑起来。
- 设备树（Device Tree）加载与处理：高通平台严重依赖设备树来描述硬件信息。ABL会从存储中加载DTB（设备树二进制），然后根据当前硬件版本（比如是8155还是8195）进行裁剪和修补。我在项目中遇到过，如果DTB里某个GPIO的配置写错了，系统直接起不来，连log都看不到。
- 分区表解析：ABL会读取GPT（GUID分区表），搞清楚每个分区的位置、大小和类型。这一步是为了后续能找到boot.img、vendor_boot.img这些镜像。
- 启动目标选择：ABL会检查用户按键（比如音量减+电源进入Fastboot）、启动计数器（BCR）、以及系统状态（比如是否要进入Recovery）。然后决定启动哪个slot（A/B分区）或者哪个模式。
- 镜像加载与校验：这是ABL最核心的安全职责。它会根据选定的启动目标，加载对应的内核、ramdisk、dtb等镜像，并进行严格的签名校验。
- 最终跳转：一切就绪后，ABL会调用UEFI的ExitBootServices()，把控制权交给Linux内核。从此，ABL的任务就结束了。
重点提醒：ABL的启动流程中，镜像校验和启动目标选择是两个最容易出问题的环节。前者涉及安全策略，后者涉及用户体验。很多刷机变砖的情况，都是因为ABL在校验阶段发现签名不对，直接拒绝启动。
3.2 ABL与XBL的交互：一场精心设计的接力赛
ABL和XBL之间不是简单的“你干完我干”，它们之间有明确的数据传递和状态同步机制。我把它比作一场接力赛，XBL是跑第一棒的，ABL是第二棒，交接棒的时候必须对齐节奏。
交互的核心载体是“共享内存”和“UEFI变量”。
XBL在跳转到ABL之前，会在约定的内存地址（通常是某个固定的物理地址）写入一个结构体，里面包含了：
- 硬件配置信息：比如DDR的容量和频率、PMIC的版本、时钟配置等。
- 启动状态：比如是否是从紧急下载模式（EDL）过来的，还是正常冷启动。
- 安全状态：比如Secure Boot是否已经使能，JTAG是否被熔断。
- 日志缓冲区指针：XBL会把它的log放在一个环形缓冲区里，ABL可以读取并追加自己的log。
ABL启动后，第一件事就是去读这个共享内存。如果读不到，或者数据格式不对，ABL会认为发生了严重错误，直接进入死循环或者重启。嗯，这里要注意，我曾经调试过一个板子，ABL死活起不来，最后发现是XBL写共享内存的时候地址算错了，差了4个字节。这种问题最难查，因为两边都觉得自己没错。
除了共享内存，UEFI变量也是交互的重要手段。
XBL会在UEFI变量空间中写入一些全局配置，比如：
gQcomTokenSpaceGuid下的BootConfig：告诉ABL当前是哪种启动模式。gQcomTokenSpaceGuid下的SecureBootState：指示安全启动的等级。
ABL可以读取这些变量，也可以修改它们。比如，当ABL检测到用户按下了Fastboot组合键，它会修改一个UEFI变量，告诉后续的Fastboot App：“嘿，现在进入Fastboot模式了。”
个人经验：如果你在调试ABL和XBL的交互问题，建议在两边都加上log打印共享内存的原始数据。我曾经用这种方法抓到一个bug：XBL写入的DDR频率值是十六进制，但ABL读出来当十进制用了，结果内存频率配置直接翻了好几倍，系统当然跑不起来。
3.3 ABL中的安全策略：不止是校验签名那么简单
说到安全，很多人第一反应就是“校验签名”。没错，签名校验是ABL安全策略的核心，但远不止于此。ABL的安全策略是一个层层递进的体系，我把它拆成三个层次来讲。
3.3.1 第一层：镜像完整性校验（Secure Boot）
这是最基础的一层。ABL在加载任何镜像之前（包括boot.img、vendor_boot.img、dtb等），都会先验证其数字签名。签名的公钥是固化在硬件中的（QFPROM或者OTP），无法被篡改。
校验流程大致如下：
- ABL读取镜像的头部，获取签名信息和哈希值。
- ABL用硬件公钥解密签名，得到原始哈希值。
- ABL重新计算镜像的哈希值。
- 对比两个哈希值。如果一致，通过；否则，拒绝启动。
你可能会问：“如果镜像被修改了，但签名没变，会怎样？” 答案是：不可能。因为签名是对整个镜像（包括哈希值）的加密，只要镜像有一个bit变了，重新计算的哈希值就和签名里的哈希值对不上。这就是非对称加密的魅力。
避坑指南：我曾经遇到过一个案例，客户自己编译了内核，但忘了给boot.img签名，结果ABL直接卡在“Loading boot image”这一步，没有任何错误提示。后来我建议他们在ABL代码里加一个debug开关，打印签名校验的详细结果，才定位到问题。所以，如果你在做开发，建议保留一个未使能Secure Boot的版本，方便调试。
3.3.2 第二层：启动链信任（Chain of Trust）
ABL本身也是被校验的。谁校验它？XBL。XBL在加载ABL镜像时，会验证ABL的签名。ABL再验证后续的镜像。这样就形成了一条完整的信任链：
PBL → XBL → ABL → boot.img → 内核 → 系统
这条链上的每一个环节，都必须通过上一级的校验。只要有一个环节断了，整个启动过程就会终止。说白了，这就是一个“你信任我，我信任他”的机制。
我个人觉得，这种设计最巧妙的地方在于：它把安全责任分散了。PBL只需要信任XBL，XBL只需要信任ABL，ABL只需要信任boot.img。每一级只需要做一件事，简单且可靠。
3.3.3 第三层：运行时安全策略（UEFI Secure Boot & 其他）
除了启动时的校验，ABL在运行过程中还会实施一系列安全策略：
- 禁止加载未签名的UEFI驱动：ABL的UEFI环境只允许加载经过签名的驱动和App。这防止了恶意代码在启动阶段注入。
- 内存保护：ABL会设置MMU（内存管理单元），把关键的内存区域（比如共享内存、UEFI变量区）标记为只读或不可执行。防止缓冲区溢出攻击。
- 启动计数器（Boot Counter）：ABL会维护一个启动计数器，记录系统尝试启动的次数。如果连续多次启动失败，ABL会切换到另一个slot（A/B分区），或者进入恢复模式。这个机制在OTA升级失败时特别有用。
- 回滚保护（Rollback Protection）：ABL会检查镜像的版本号。如果检测到有人试图刷入一个旧版本的镜像（降级攻击），ABL会拒绝启动。这个策略防止了攻击者利用旧版本的安全漏洞。
总结一下：ABL的安全策略，说白了就是三件事——校验你是谁（签名）、确保你没有被替换（信任链）、防止你在运行时搞破坏（内存保护、回滚保护）。这三层缺一不可。我在做安全审计时，经常发现有些厂商只做了第一层，忽略了第二层和第三层，结果被攻击者通过刷入一个未签名的UEFI驱动绕过了整个安全体系。
好了，关于ABL的启动流程、与XBL的交互、以及安全策略，我就讲到这里。下一章我们会深入ABL的代码层面，看看这些策略具体是怎么实现的。到时候我会带大家读一段ABL的源码，嗯，那才是真正有意思的地方。