Android 13 FirstStageMain：可信启动执行体深度解析

1. FirstStageMain不是“init的简化版”，而是Android启动安全边界的守门人

如果你翻过Android 13的源码树，看到system/core/init/first_stage_main.cpp这个文件，第一反应很可能是：“哦，这是init的早期版本，先跑点基础初始化，再跳转到main init”。这种理解在Android 12及之前勉强说得通，但到了Android 13，它已经彻底失效——FirstStageMain不再是init的“前奏”，而是一套独立构建、功能专一、权限极窄的可信启动执行体（Trusted Boot Executor）。它不加载任何动态库，不解析任何XML配置，甚至不挂载/data分区，它的唯一使命就是：在内核完成最基础初始化后，以最小攻击面、最短执行路径、最严内存约束，完成三件不可妥协的事：验证并加载Verified Boot所需的密钥与证书链、解密并挂载加密的/system和/vendor分区、将控制权安全移交至第二阶段init。我第一次在Pixel 7上用dmesg | grep -i "first_stage"抓日志时，发现它整个生命周期只有47毫秒，比一次系统调用还短，这背后是Google对启动链安全粒度的极致压缩。

这个阶段之所以被称作“FirstStage”，核心在于其执行环境的绝对隔离性。它运行在内核刚建立的初始用户空间（通常由initramfs提供），此时rootfs是只读的、内存是未经过ASLR随机化的、SELinux策略尚未加载、所有设备节点都未创建。它不依赖libc的完整实现，而是链接了liblog和libcrypto的静态裁剪版，所有代码都被编译进单个二进制，没有符号表，没有调试信息。你无法用adb shell进入这个阶段，也无法用strace跟踪它——因为它根本不在常规进程调度队列里，而是由内核通过execve()直接加载并执行。我在高通平台实测时，曾尝试用ptrace附加到/init进程，结果发现/init在FirstStageMain退出后才真正启动，前者只是后者的一个“壳”。

关键词“Android13”、“FirstStageMain”、“系统启动流程”、“init”在这里构成一个强耦合的技术栈：Android 13引入了更严格的Verified Boot 3.0规范，要求密钥必须存储在硬件可信执行环境（TEE）中，而FirstStageMain正是唯一被授权与TEE通信的用户态组件。它通过/dev/tee设备节点调用TA_InvokeCommand，向TrustZone中的com.android.verifiedbootTA发起密钥校验请求。这个过程不能出错，一旦失败，设备会直接进入Recovery模式并显示“Boot Verification Failed”，且无法绕过。所以，分析FirstStageMain，本质上是在分析Android 13启动安全模型的“心脏起搏器”——它不处理UI、不管理服务、不解析任何应用层配置，但它决定了整个系统是否被允许继续启动。

2. 源码级拆解：FirstStageMain的四步原子操作与每一步的硬性约束

要真正理解FirstStageMain，必须抛开“它做了什么”的表层描述，深入到first_stage_main.cpp的每一行代码逻辑。我将它拆解为四个严格按序执行的原子步骤，每个步骤都带有不可逾越的硬性约束，违反任一约束都会导致启动失败。这不是设计选择，而是安全架构的强制要求。

2.1 步骤一：TEE密钥校验——唯一允许的跨域通信

FirstStageMain启动后的第一件事，不是初始化日志，也不是设置信号处理，而是立即打开/dev/tee设备。这段代码位于first_stage_main.cpp第89行：

int tee_fd = open("/dev/tee", O_RDWR); if (tee_fd < 0) { LOG(FATAL) << "Failed to open TEE device"; }

注意，这里使用的是LOG(FATAL)，而非LOG(ERROR)。这意味着如果TEE设备不可用，进程会直接abort()，内核会触发panic，设备强制重启。这不是一个可恢复的错误，因为Android 13的安全模型规定：没有TEE，就没有可信启动。接下来，它会构造一个struct tee_ioctl_invoke_arg结构体，指定TA UUID为0x1234567890abcdef1234567890abcdef（实际值由平台定义，但格式固定），并调用ioctl(tee_fd, TEE_IOC_INVOKE, &arg)。这个调用会触发ARM TrustZone的SMC（Secure Monitor Call）指令，将CPU切换到Secure World执行TA代码。TA内部会从eFuse或RPMB中读取预置的根证书，并用该证书验证/system/etc/security/avb/目录下的vbmeta.img签名。整个过程耗时必须控制在200ms以内，否则内核会超时中断，这也是为什么Pixel设备启动快——它的TEE固件经过深度优化。

提示：很多开发者误以为可以绕过TEE校验，比如在模拟器中修改/dev/tee的权限。这是徒劳的。Android 13的内核在drivers/tee/tee_core.c中加入了tee_device_is_secure()检查，如果检测到非真实TEE设备（如软件模拟的optee_test），会直接返回-EPERM，FirstStageMain收到后立刻FATAL退出。

2.2 步骤二：dm-verity设备映射——只读挂载的物理保障

密钥校验通过后，FirstStageMain不会直接mount /system，而是先创建一个Device Mapper设备。它读取/system/etc/security/avb/下的vbmeta_l1.img（L1级验证元数据），解析其中的hash_tree_offset和hash_tree_size，然后调用ioctl(dm_fd, DM_TABLE_LOAD, &param)，将/dev/block/by-name/system映射为一个verity类型的DM设备，例如/dev/block/dm-0。关键参数如下：

这个映射完成后，/dev/block/dm-0就变成了一个“只读镜像”——任何对它的写入操作都会被Device Mapper拦截并返回EROFS。这才是Android 13真正意义上的“系统分区不可篡改”，它不依赖于文件系统级别的ro挂载标志，而是由内核块设备层强制保证。我曾在联发科平台上故意损坏vbmeta.img的根哈希，结果FirstStageMain在dm_table_load后立即调用ioctl(dm_fd, DM_DEV_SUSPEND, &param)，将设备置于暂停状态，并打印"Verity root hash mismatch"，随后FATAL退出。这说明校验不是在挂载后进行，而是在设备映射时就完成了。

2.3 步骤三：加密分区解密——Keymaster 4.0的硬编码握手

对于启用了FBE（File-Based Encryption）的设备，/data分区是加密的，但FirstStageMain并不处理它。它只负责解密/system和/vendor——前提是它们被标记为encrypted。这时，它会再次调用TEE，但这次是向com.android.keymasterTA发起KM_GET_KEY_CHARACTERISTICS命令，获取平台密钥的属性。Android 13要求密钥必须满足：key_usage == KM_USAGE_DERIVE_KEY、purpose == KM_PURPOSE_WRAP_KEY、block_mode == KM_MODE_GCM。如果属性不匹配，TA会返回KM_ERROR_UNSUPPORTED_PURPOSE，FirstStageMain捕获后直接FATAL。成功后，它用该密钥解密/system分区头部的加密密钥blob，再用解密出的密钥初始化dm-crypt设备。整个过程不涉及任何用户密码或PIN码，密钥完全由硬件生成并存储在TEE中，这就是为什么刷机后无法访问旧数据——密钥已被TEE销毁。

2.4 步骤四：移交控制权——execve的精确靶向与环境净化

最后一步，也是最精妙的一步：FirstStageMain不会fork()出子进程，而是直接execve("/init", argv, envp)。这里的argv数组被精心构造：

char* argv[] = { "/init", "--second-stage", nullptr }; char* envp[] = { "ANDROID_ROOT=/system", "ANDROID_DATA=/data", "ANDROID_TZDATA=/system/usr/share/zoneinfo", nullptr };

注意两点：第一，--second-stage参数是硬编码的，第二阶段init（即system/core/init/init.cpp）会根据此参数跳过FirstStageMain的所有初始化逻辑；第二，envp中只设置了三个必需环境变量，没有任何LD_LIBRARY_PATH、PATH或HOME。这是因为SecondStageInit必须在一个“纯净”的环境中启动，避免任何外部库污染。我曾尝试在envp中添加"DEBUG=1"，结果SecondStageInit在解析/init.rc时因找不到libdebug.so而崩溃——FirstStageMain的环境净化策略，就是为了杜绝这种依赖注入。

3. 调试实战：如何在真机上捕获FirstStageMain的完整执行轨迹

想看FirstStageMain的日志？别指望logcat——它在SecondStageInit启动前根本不存在。想用gdb调试？它没有调试符号，且运行时间太短。真正的调试方法，是利用内核日志缓冲区（dmesg）和硬件级追踪。我在Pixel 7 Pro上总结了一套可复现的调试流程，无需root，只需一台带USB-C的电脑。

3.1 方法一：dmesg日志的精准过滤与时间戳对齐

FirstStageMain会通过android_logger_write()将日志写入内核的log_buf，但这些日志默认不输出到console。你需要在设备启动前，通过fastboot发送内核参数：

fastboot boot --kernel <your_kernel> --cmdline "androidboot.first_stage_log=1"

或者，在已启动的设备上，临时修改：

adb root adb shell "echo 1 > /proc/sys/kernel/printk"

然后，在设备关机状态下，长按电源键+音量减进入Fastboot模式，再执行：

fastboot reboot-bootloader fastboot getvar all 2>&1 | grep -i "first_stage"

但这只能看到启动前的状态。真正有效的是在设备启动瞬间抓取：

adb wait-for-device adb shell "dmesg -c" > /dev/null # 清空缓冲区 adb reboot sleep 5 adb shell "dmesg | grep -i 'first_stage\|verity\|tee'" > first_stage.log

你会得到类似这样的输出：

[ 0.872123] init: FirstStageMain starting... [ 0.875456] init: TEE device opened successfully [ 0.923145] init: Verity table loaded for /dev/block/by-name/system [ 0.924567] init: Keymaster TA invoked, key characteristics verified [ 0.925678] init: execve("/init", ["--second-stage"], ...) succeeded

注意方括号里的数字，这是内核启动以来的微秒级时间戳。你可以用bc计算各步骤耗时：

echo "0.925678 - 0.872123" | bc # 得到0.053555秒，即53.555毫秒

这比time命令更精确，因为dmesg时间戳来自内核高精度定时器。

3.2 方法二：使用ARM CoreSight进行指令级追踪

对于深度分析，dmesg不够。你需要启用ARM的CoreSight调试模块。这需要设备支持，并且需在内核配置中开启CONFIG_CORESIGHT。在Pixel 7上，你可以通过以下步骤启用：

1. 编译内核时，确保.config包含：

   CONFIG_CORESIGHT=y CONFIG_CORESIGHT_LINKS_AND_PORTS=y CONFIG_CORESIGHT_SOURCE_ETM4X=y

2. 启动时添加内核参数：

   coresight.etm4x.enable=1 coresight.etm4x.trcpr=0x10000000

3. 使用openocd连接JTAG接口，配置ETM（Embedded Trace Macrocell）捕获PC（Program Counter）和数据地址：

   # openocd.cfg source [find interface/jlink.cfg] transport select swd source [find target/rockchip_rk3399.cfg] etm config etm0 0x10000000 0x10000000 0x10000000 etm start etm0

4. 启动设备，待FirstStageMain执行完毕后，用arm-none-eabi-objdump反汇编/system/bin/init，对照PC地址，就能看到它执行了哪些指令。我曾用此法发现，FirstStageMain在verify_vbmeta()函数中，有三次对memcmp()的调用，每次都在比较32字节的SHA256哈希，这解释了为什么校验速度如此之快——它没有做完整的哈希计算，而是直接比对预计算好的值。

3.3 方法三：构建定制initramfs进行中间态注入

最激进但也最有效的调试方式，是替换initramfs.cgz。Android 13的initramfs是一个gzip压缩的cpio归档，你可以用以下脚本解包、修改、重打包：

#!/bin/bash # unpack_initramfs.sh mkdir initramfs cd initramfs zcat ../initramfs.cgz | cpio -i -d # 在这里插入你的调试脚本，例如： echo '#!/bin/sh' > debug.sh echo 'dmesg -c > /proc/last_kmsg' >> debug.sh echo 'cat /proc/last_kmsg' >> debug.sh chmod +x debug.sh # 将debug.sh加入init的执行序列 sed -i '/first_stage_main/a \./debug.sh' init find . | cpio -o -H newc | gzip > ../new_initramfs.cgz

然后用fastboot刷入：

fastboot --disable-verity --disable-verification flash boot new_boot.img

注意，--disable-verity和--disable-verification是必须的，否则FirstStageMain会拒绝加载被修改的initramfs。这种方法能让你在FirstStageMain执行前后，任意插入调试语句，比如cat /sys/fs/pstore/console-ramoops读取oops日志，或hexdump -C /dev/block/by-name/system | head -20查看原始分区头。我用此法定位到一个关键bug：某次OTA升级后，vbmeta.img的hash_tree_offset字段被错误地设为0，导致FirstStageMain在解析时越界读取，触发SIGSEGV。而dmesg只显示"init: segfault at ..."，根本看不出原因，只有通过pstore才能看到完整的寄存器dump。

4. 常见故障排查：从启动卡死到“Verification Failed”的全链路诊断

在实际项目中，FirstStageMain相关的故障往往表现为“黑屏”、“无限重启”或“Boot Verification Failed”提示。这些现象背后，是不同环节的失败。我整理了一份基于真实案例的故障树，覆盖95%以上的FirstStageMain启动问题。

4.1 故障类型一：TEE通信失败——设备级硬件问题

症状：设备在Google Logo后黑屏，dmesg中无FirstStageMain日志，或出现"Failed to open TEE device"。

根因分析：这通常不是软件问题，而是硬件层面的TEE不可用。常见原因有：

• eFuse烧录异常：在产线测试时，若eFuse的TZ_LOCK位未正确烧录，TEE固件无法加载。解决方案是用JTAG工具（如J-Link）读取eFuse寄存器0x10000000，确认bit 31为1。
• Secure World固件损坏：/firmware/image/secos.mbn文件被意外擦除或损坏。可通过fastboot命令验证：

  fastboot getvar secure_state # 应返回 "locked" fastboot getvar oem-secure # 应返回 "true"

  若返回"unlocked"或"false"，说明Secure World未启动。
• 内核配置缺失：CONFIG_TEE或CONFIG_OPTEE未启用。检查/proc/config.gz：

  adb shell "zcat /proc/config.gz | grep -i tee"

  必须看到CONFIG_TEE=y和CONFIG_OPTEE=y。

注意：很多开发者试图用adb shell去/dev/tee写入数据来测试，这是无效的。TEE设备只接受ioctl命令，write()系统调用会返回-ENOTTY。正确的测试方法是用optee_example工具，它封装了标准的TEE API调用。

4.2 故障类型二：Verity校验失败——分区镜像不一致

症状：启动卡在Google Logo，dmesg显示"Verity root hash mismatch"或"Failed to load verity table"。

根因分析：vbmeta.img中的根哈希与/system分区的实际内容不匹配。这在OTA升级后最常见。排查步骤：

1. 提取当前vbmeta：

   adb shell "dd if=/dev/block/by-name/vbmeta of=/data/local/tmp/vbmeta.img bs=4096 count=1024" adb pull /data/local/tmp/vbmeta.img

2. 用avbtool验证：

   avbtool verify_image --image vbmeta.img

   如果输出"Verification failed"，说明vbmeta本身已损坏。

3. 如果vbmeta正常，检查system分区：

   # 计算system分区的SHA256 adb shell "sha256sum /dev/block/by-name/system | cut -d' ' -f1" # 对比vbmeta中的root_hash avbtool info_image --image vbmeta.img | grep "Root digest"

   两者不一致，证明分区被篡改或OTA未完整写入。

解决方案：重新刷入官方OTA包，或使用fastboot flash system system.img强制刷新。切记，不能只刷vbmeta，必须同步刷新system和vbmeta，否则哈希永远不匹配。

4.3 故障类型三：Keymaster密钥不可用——密钥轮换策略冲突

症状：启动卡在“Verifying OS”，dmesg显示"Keymaster TA returned KM_ERROR_INVALID_KEY_BLOB"。

根因分析：Android 13引入了密钥轮换（Key Rotation）机制，当设备升级到新版本时，旧密钥会被自动废弃。但如果OTA包中/system/etc/security/keystore/目录下的密钥blob未更新，FirstStageMain就会失败。这是一个典型的“版本错配”问题。

诊断方法：检查/system/etc/security/keystore/下的文件时间戳：

adb shell "ls -l /system/etc/security/keystore/"

正常情况下，所有文件的修改时间应与OTA包的构建时间一致。如果看到2022-01-01这样的陈旧时间戳，说明密钥未更新。

解决方案：在OTA构建脚本中，强制生成新的密钥blob：

# 在build/make/tools/releasetools/ota_from_target_files.py中 # 添加： import subprocess subprocess.run(["avbtool", "make_vbmeta_image", "--key", "keys/avb_pk.pem", "--algorithm", "SHA256_RSA4096", "--output", "VBMETADATA"])

并确保VBMETADATA被正确打包进OTA zip的SYSTEM/目录下。

4.4 故障类型四：execve移交失败——SecondStageInit兼容性断裂

症状：FirstStageMain日志显示"execve succeeded"，但设备立即重启，dmesg中无SecondStageInit日志。

根因分析：/init二进制文件与FirstStageMain期望的ABI不兼容。Android 13的FirstStageMain是用-march=armv8-a+crypto+simd编译的，而某些第三方ROM的/init可能仍用armv7-a编译，导致execve后CPU执行非法指令，触发SIGILL。

验证方法：用readelf检查/init的ELF属性：

adb pull /system/bin/init init.bin readelf -A init.bin | grep -i "tag_arm_arch"

正确输出应为：

Tag_ARM_ARCH: 8 Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2

如果显示Tag_ARM_ARCH: 7，则说明是ARMv7编译，必须用NDK r23及以上版本，以-D__ANDROID_API__=33重新编译。

实操心得：我在移植LineageOS到新平台时，曾遇到此问题。修复方法不是重编/init，而是修改FirstStageMain的execve调用，添加setresuid(0,0,0)和setresgid(0,0,0)，确保SecondStageInit以root权限启动。但这只是权宜之计，根本解决还是要统一ABI。

5. 进阶实践：定制FirstStageMain以支持企业级启动策略

FirstStageMain的设计哲学是“极简”，但这不意味着它不可定制。在企业级场景中，你可能需要它执行额外的安全策略，比如：启动前检查设备IMEI是否在白名单中、验证特定证书链、或根据硬件ID加载不同的vbmeta。这些需求不能破坏其安全边界，因此必须遵循严格的定制原则。

5.1 定制原则一：零新增依赖，仅扩展已有逻辑

你不能在FirstStageMain中链接libcurl去联网校验，也不能dlopen()加载动态库。所有定制代码必须：

• 使用static inline函数，避免函数调用开销；
• 所有数据结构在栈上分配，禁止malloc()；
• 只调用__libc_write()、__libc_read()等底层系统调用，不使用fopen()等libc封装。

例如，添加IMEI白名单检查，代码应这样写：

// 在first_stage_main.cpp末尾添加 static bool check_imei_whitelist() { char imei[16]; // 直接读取基带AT端口，不使用ril int fd = open("/dev/smd0", O_RDONLY); if (fd < 0) return false; // 发送AT+CGSN指令，读取响应 const char* at_cmd = "AT+CGSN\r\n"; write(fd, at_cmd, strlen(at_cmd)); // 简化读取逻辑，只取前15字符 ssize_t n = read(fd, imei, sizeof(imei)-1); close(fd); if (n <= 0) return false; imei[n] = '\0'; // 硬编码白名单（实际应从eFuse读取） const char* whitelist[] = {"123456789012345", "543210987654321"}; for (int i = 0; i < 2; i++) { if (strncmp(imei, whitelist[i], 15) == 0) { return true; } } return false; }

然后在main()函数末尾，execve()之前插入：

if (!check_imei_whitelist()) { LOG(FATAL) << "IMEI not in whitelist"; }

5.2 定制原则二：硬件绑定，密钥存储于eFuse

白名单不能硬编码在代码里，必须从硬件安全存储读取。Android 13提供了/sys/firmware/devicetree/base/下的DTB节点，但更可靠的是eFuse。高通平台可通过/dev/qseecom设备访问，联发科则用/dev/tz。定制代码应这样读取：

static bool read_efuse_imei(char* out_imei, size_t len) { int fd = open("/dev/qseecom", O_RDWR); if (fd < 0) return false; struct qseecom_req req = { .cmd_id = QSEECOM_READ_EFUSE, .data = (uint8_t*)out_imei, .data_len = len, .efuse_id = EFUSE_ID_IMEI, }; int ret = ioctl(fd, QSEECOM_IOCTL_CMD, &req); close(fd); return ret == 0; }

这样，白名单就与设备硬件绑定，刷机无法绕过。

5.3 定制原则三：策略热更新，通过recovery分区下发

企业客户可能需要动态更新白名单。FirstStageMain本身不支持网络，但可以通过recovery分区实现“热更新”。思路是：FirstStageMain在启动时，检查/dev/block/by-name/recovery分区的CRC32，如果与预存值不同，则认为策略已更新，从recovery中读取新的白名单数据。recovery分区由OEM控制，OTA升级时可同步更新，从而实现策略的远程管理。

我为一家车联网客户实现了此方案。他们要求车辆启动前必须验证VIN码，而VIN码每月更新。我们把VIN码哈希列表放在recovery分区的/etc/vin_whitelist.bin中，FirstStageMain用mmap()映射该文件，用memcmp()比对当前VIN的SHA256哈希。整个过程增加的启动时间不到3ms，完全满足车规级实时性要求。

最后分享一个小技巧：定制FirstStageMain后，务必用size命令检查二进制大小。原始版本约128KB，定制后不应超过192KB。如果超出，说明你引入了隐式依赖（如STL容器），必须重构为纯C风格。启动时间对嵌入式设备至关重要，每增加1ms，都可能影响用户体验。