BOOT PROCESS: ANDROID vs. LINUX

December 28, 2024

翻译自： https://xdaforums.com/t/info-boot-process-android-vs-linux.3785254/

注意： 我并非开发人员或 Android 专家。此处提供的所有信息均来自不同的互联网来源，并且是尽我所知悉的。对于因使用本文信息而对您或您的设备造成的任何损害，我概不负责。

1. PC 启动过程

在深入了解 Android 的启动过程之前，我们先来看看 Linux PC 的情况。

按下电源按钮
开机自检（POST）：识别存在的设备并报告任何问题
BIOS / UEFI
必要的硬件初始化（键盘、磁盘等）
磁盘（MBR）
DOS 兼容区域代码（可选）
引导加载程序
活动/启动分区（引导扇区）
内核
Initrd / initramfs (init)
服务/守护进程/进程

BIOS / UEFI 是硬编码在主板上的第一个软件代码，在我们按下电源按钮后运行。BIOS 在处理器的实模式（16 位）下运行，因此它无法寻址超过 2^20 字节的 RAM，即例程无法访问超过 1 MiB 的 RAM，这是一个严格的限制和主要的不便之处。

创建分区时，MBR 保存在 LBA0 中，GPT 标头保存在 LBA1 中，主 GPT 保存在 LBA2-33 中，LBA34（第 35 个）是第一个可用的扇区。备份或辅助 GPT 保存在最后 33 个 LBA 中，操作系统最后一个可用的扇区是（总 LBA 数 - 33）。分区软件将 GPT 分区对齐在较大的边界上，例如在 2,048 的倍数的 LBA 上对齐到 1,048,576 字节（512 字节 * 2048 = 1 MiB）的边界。因此，第一个分区的第一个扇区是 LBA 2048，以此类推。

当系统启动时，必须将文件系统的驱动程序加载到 RAM 中才能使用该文件系统，但驱动程序本身是一个文件，位于某个文件系统内部。这就像一个鸡生蛋蛋生鸡的场景。因此，解决方案是始终加载（作为 BIOS/UEFI 标准）可启动存储器上的第一个扇区（在较旧的方案中为 0/0/1 C/H/S，在较新的方案中为 LBA0），它是（传统的或保护性的）MBR。BIOS/UEFI 和存储介质之间的这种通信是通过特定于主机控制器的命令进行的，例如 PC 上具有 SATA/AHCI 接口的设备的 ATA 命令。

主引导记录（MBR）

第一个有效磁盘起始处的第一个 512 字节（1 个扇区）
引导代码（446 字节）+ 分区表（64 字节）
可执行代码：引导加载程序的第一阶段扫描分区表并找到活动分区的第一个扇区（或可能指向中间阶段）
分区表提供有关活动/可启动分区（以及所有其他分区）的信息
64 字节的小尺寸将最大（主）分区数限制为 4 个
由于引导加载程序尚无法理解文件系统（inode 等），因此 MBR 本身是可执行的
最后 2 个字节是引导签名，即立即查找磁盘/驱动器是否可启动，从而切换到下一个

DOS 兼容区域

此阶段特定于传统的 GRUB，GRUB 2（大多数现代 Linux 发行版上的默认引导加载程序）将此阶段分为第 2 阶段和第 3 阶段
MBR 旁边的 31.5 KiB / 63 个扇区，包含文件系统实用程序
仍然由 BIOS 例程加载（或引导加载程序可以使用其自己的驱动程序）
某些硬件需要此阶段，或者如果 "/boot" 分区（包含第 2 阶段的扇区）位于磁盘的 1024 个柱面头之上，或者如果使用 LBA 模式

卷引导记录（VBR）/分区引导记录（PBR）

扇区号 63（第 64 个扇区）及以上可能包含卷引导记录或分区 BR，与 MBR 非常相似
也称为卷引导扇区，它可能是任何分区上的第一个引导扇区
NTFS 将 VBR 保存为元数据文件名称 $Boot（位于第一个簇上），其中还包含文件 $MFT 的簇号。$MFT 描述卷上的所有文件；文件名、时间戳、流名称、数据流所在的簇号列表、索引、安全标识符 (SID) 和文件属性，如“只读”、“压缩”、“加密”等。
如果磁盘未分区，则是磁盘的第一个引导扇区

引导分区（如果存在）

在 MBR 方案中，可以使用标志将分区标记为可启动/活动，通常是磁盘的第一个分区
Windows 第一阶段引导加载程序仅从 MBR 分区表中读取和加载“活动分区”
引导扇区或 VBR/PBR 由第一阶段或 1.5 阶段（GRUB2 上为 2 或 3）引导加载程序读取，该引导加载程序加载第二阶段（GRUB2 上为 4）或实际的引导加载程序
MBR / VBR 包含：
- 跳转指令（前 3 个字节），即“goto 引导代码”命令
- 文件系统标头
- 可执行引导代码，通常包含用于跳转到包含第二阶段引导加载程序的下一个相邻扇区的跳转指令
- 扇区末尾（类似于引导签名）
第一阶段或 1.5 阶段（或 GRUB2 上的 3）引导加载程序读取分区上的文件系统表（如 MFT / FAT），并将实际引导加载程序加载为常规文件

引导加载程序（实际）

由前一个引导加载程序从同一分区的文件系统中加载
加载所有必要的文件系统驱动程序（如果还需要）
配置是从数据库中读取的，例如 Linux 上的 /boot/grub/ (GRUB) 和 Windows 上的 <“系统保留”分区>/Boot/BCD (BOOTMGR)
Windows:
- BCD 是二进制文件，可以使用命令行工具 bcdedit.exe 或 GUI 工具 EasyBCD 读取和修改
- XP 上的 NTLDR 只是将 C:\ 用作活动分区，读取 C:\Boot.ini
Linux：
- GRUB 利用模块为复杂的启动过程提供额外的功能
- 如果需要或配置，它可以向用户显示引导菜单，例如用于多重启动或在安全/恢复模式下启动或从 USB/网络启动等
- 在 RAM 中定位并加载所需操作系统的内核和 ramdisk
- 如果 GRUB 无法处理 Windows 等操作系统的内核，可以将其配置为链式加载，即读取并执行包含 Windows 引导加载程序的分区的引导扇区
- 'os-prober' 通过读取该分区中的引导加载程序配置来帮助 'grub-install' 和 'grub-update' 查找 Windows 引导分区（系统保留）
- 内核
- 引导加载程序以读取模式将同一分区 (/boot) 中的内核的第一个 MB 加载到 RAM 中，然后切换到保护模式 (32 位)，并将 1MB 前移清除第一个 MB
- 然后切换回实模式，并对 initrd 执行相同的操作（如果它与内核分开）
- 内核包含 ramfs 驱动程序，以从 initrd 读取 rootfs 并进行挂载

Initramfs

包含访问真实 rootfs（硬盘驱动器、NFS 等）所需的最小文件系统和模块（内核未携带的所需驱动程序）
udev 或特定的脚本加载所需的模块
<ramdisk>/init 通常是一个脚本，它加载必要的驱动程序并挂载真实的 rootfs
最后，init switch_root 到真实的 rootfs 并执行 /sbin/init；sysV（传统的）、upstart（Ubuntu 的倡议）或 systemD（最新被广泛接受的）

init > getty（在虚拟终端上）> login（程序）> motd > 登录 shell > bashrc / bash_profile

阅读更多关于LINUX 控制台和虚拟终端 的信息

UEFI

与 BIOS 相反，UEFI 可以理解文件系统，因此不受 MBR 代码（446 字节）的限制
需要一个 EFI 系统分区 (ESP)，最好至少 550MB
ESP 分区格式化为 FAT32，但可以理解其他文件系统，如 FAT12（软盘）、FAT16、ISO9660（CD/DVD）、UDF 等
EFI 固件直接读取 <ESP_Partition>/EFI/<vendor>/<boot_programs>，如引导管理器中配置的那样（哪个磁盘、哪个分区、哪个程序）
引导程序使用 EFI 固件或 EFI shell 或 GUI 引导管理器加载内核
如果引导程序只是磁盘（没有配置分区和程序），则执行后备程序 <disk>/<ESP partition>/BOOT/BOOTX64.EFI
安全启动功能在加载前验证引导程序的签名
多重引导很容易，只需从 ESP 分区读取不同的条目，而不是依赖单个引导加载程序来链式加载所有可用的操作系统
Linux 内核的 EFISTUB 功能允许直接将内核作为 boot_program 启动
UEFI 比 MBR 更适合 GPT

必读：

Android 分区和文件系统

2. Android 启动顺序

可能存在一个或多个引导加载程序（以提供有关如何启动的指示）。对于典型的 Android 设备（最常见的 Qualcomm SoC / ARM 处理器），启动顺序如下：

BootROM（类似于 PC 上的 BIOS）。它与 SoC 集成在一起。
处理器、引导加载程序
开机自检 (POST)
SBL
- 并行加载来自不同分区的内容。
应用程序引导加载程序 (aboot)
- 主引导模式（如果未检测到内核或如果应用了引导加载程序/下载模式键组合）
  - 引导加载程序/下载模式
- 辅助引导
  - 内核（硬件检测和填充 /sys、/dev/ 和 /proc 目录，随着进程的启动）和 initramfs（在 rootfs 上创建 rootfs 和其他伪文件系统）
    - Init（PID 为“1”的第一个进程。它启动进程和守护进程的进一步加载）
    - 系统 / 操作系统 (ROM)
  - 恢复模式（如果应用了恢复模式键组合。它是一个带有 UI 的内核，用于执行基本的故障排除操作）

3. 引导加载程序

引导加载程序通过从 SoC 接管控制、执行必要的检查、加载所需的组件，然后将启动控制权移交给内核来促进设备的初始启动。在第一阶段检测到 RAM，以开始在其中加载其他硬件（如键盘、显示器等）的配置。存在（曾存在）多个由不同处理器、在具有不同（分区）名称的不同设备上执行的引导加载程序，如 RPM (PBL)、DBL（设备引导加载程序；CFG_DATA 或 sbl1）、SBL2、SBL3 (QCSBL) 和 OSBL（操作系统引导加载程序）等。

简而言之，在现代 ARM 设备（Qualcomm SoC）上：

BootROM / iROM 和 PBL

iROM 在按下电源按钮时由 CPU0 运行，加载到 iRAM 中（在 RAM 初始化之前）它可以设置 RAM 并执行 RAM 中的 PBL，或将此留给 SBL。iROM/PBL 在 SoC 上硬编码，在 CPU 生产过程中写入，并且是闭源的。在支持从多个来源（如 eMMC/sdcard/USB/UART/网络）启动的设备（如开放板或某些平板电脑）上，与 PC BIOS 一样，在 iROM 和 PBL 之间有一个额外的阶段：

IBL（初始 BL） 它也被加载到 iRAM 中。根据 iROM 通知的 CPU 引脚设置（隐藏和焊接或暴露以进行手动切换），IBL 将引导模式选择传递给 PBL，并且如果本身由 iROM 进行电子签名，则可以选择检查 PBL 的完整性。

SBL 或 XBL（预加载程序） IBL 从 eMMC/SDCard 调用 SBL，该 SBL 支持 LCD 输出。SBL 初始化 DDR RAM，加载可信固件 (TZ) 和 RPM 固件（如果 BootROM 未加载）。SBL 在自检设备后调用最终的引导加载程序。 Uboot 是用于嵌入式设备的开源辅助引导加载程序。但是，也可以从 Qualcomm 获取 SBL 的源代码。

ABOOT（APPSBL；Little Kernel 的前身）

ABOOT 加载分区表、内核、启动画面（徽标）和调制解调器。它还负责充电模式和快速启动模式。RAM 中用于启动/恢复分区的内存地址在 aboot 中硬编码。最终（即在内核之前）引导加载程序的其他示例包括 uboot（用于嵌入式设备的传统 Linux 引导加载程序）或制造商开发的 BL，如 hboot（由 HTC 使用）和 redboot 等。

制造商在此阶段设置其限制（例如网络运营商，即 SIM 卡锁和其他限制）。USB 协议不足以破解此类限制，与引导加载程序通信以破解此类限制需要特殊设备（通常称为刷机盒或维修盒），有时甚至需要像 JTAG 这样的协议，即直接与微处理器对话。按照惯例，所有这些阶段 1、2、3... 引导加载程序都简称为引导加载程序。而在某些设备上，根本没有引导加载程序分区，并且引导加载程序驻留在 SoC 上。

回到启动过程，在初始化启动过程后，引导加载程序（如果已锁定）检查 boot.img（正常启动）或 recovery.img（恢复启动）的完整性，将其加载到 RAM 中，并将控制权移交给内核，为它提供压缩（cpio，gzipped）initramfs 的“phys_initrd_start”地址。

4. 内核和 INITRAMFS

一旦内核被引导加载程序加载并解压到 RAM 中以及参数，内核就开始执行。内核实际上是一个自包含的（静态）可执行二进制文件，由在编译时链接在一起的许多目标文件 (.o) 组成。一旦确定了架构和 CPU，就会根据从引导加载程序传递的参数执行依赖于架构的代码。然后执行独立于架构的阶段，其中包括设置驱动程序（显示、触摸等）、文件系统（如 rootfs、tmpfs、proc、ext4 等）以及初始化控制台（如果已配置）。在这里，内核空间结束，用户空间开始（他们称之为）。

内核在 rootfs（其本身是 ramfs 或 tmpfs）中解压压缩的 initramfs，并执行 /init 二进制文件，该二进制文件随后读取其配置文件 /init.rc 和其他以 Android 特定 init 语言编写的 /*.rc 文件。在内核的帮助下，init 挂载伪文件系统 /sys 和 /proc，并填充包含设备节点文件的 /dev 目录。然后，它挂载 /system 和所有其他分区（包括 /data，如果已加密，则也会解密），并设置（SELinux 安全）策略、系统属性和环境变量（PATH、EXTERNAL_STORAGE 等）。此外，init 还负责处理任何硬件更改 (ueventd) 和动态发生的启动服务更改（看门狗）。

最后，init 启动位于系统分区上的运行时。init 启动的主要最后一个进程之一是 Zygote（Java 虚拟机），它会编译应用程序以在特定的架构（主要是 arm / arm64）上运行。

设备树 Blob

设备树 Blob (DTB) - 由 DT 编译器 (DTC) 从 DT 源 (DTS) 文本创建 - 是板/SoC 上硬件组件的映射，通常是内核源代码的一部分。

PC 硬件通常支持通过 ACPI 进行硬件枚举，即内核可以查询（探测）总线 - PCI（内部设备）、USB（外部设备）、SCSI（存储设备）、HDMI/DVI/VGA（显示设备）等 - 哪些设备连接到它。

嵌入式设备（包括 Android 设备）上的总线大多不支持枚举（硬件发现），因为通常存在固定的一组设备，并且无法选择在设备上加载不同的操作系统。因此，需要通知操作系统所有连接的设备，这是通过向内核提供标准的 DTB 来完成的。DTB 由 SoC/主板供应商提供，通常是内核源代码的一部分。在启动过程中，DTB 由引导加载程序在启动时加载并传递给内核，以便内核可以发现硬件并相应地创建节点点。

我们可以通过以下方式查看 Adroid 设备上的设备树：

~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree

DTB 可以像 AOSP 指定的那样位于单独的 dtb/odm 分区上（并且是 Android 诞生之前针对基于 ARM 的嵌入式 Linux 设备提出的解决方案），但这并没有得到广泛的应用。通常，DTB 会附加到内核 zImage/Image.gz 或放置在 boot.img 内的第二阶段。

验证/安全启动

确保从开机到加载内核的信任链属于 SoC 供应商（Qualcomm、Intel 等）和 OEM 的领域。在启动过程中的任何时候注入一些恶意或有害的代码都会变得非常困难，以至于不可能实现。

为了确保安全的启动链，PBL 验证 SBL 的真实性，SBL 随后验证引导加载程序（TZ、RPM、DSP、HYP 和 aboot）的完整性，以避免加载未签名的映像（引导、恢复、系统等）。TZ 在由 SBL 加载后，还使用基于硬件的根证书验证 ABOOT。

具有验证/安全启动实施的引导加载程序通过将其签名与存储在“OEM 密钥库”（某些分区，如 CMNLIB、KEYMASTER 或其他名称）中的密钥进行匹配来验证 boot.img 或 recovery.img（内核、initramfs 和附加到内核或 boot.img 第二阶段的 DTB），该密钥库本身由 OEM 签名。一些供应商允许用自定义密钥库替换/附加此密钥库，以便可以刷写自定义签名映像，然后重新锁定引导加载程序。此处给出了一个简单的详细信息。

在此阶段，信任链被移交给存储在引导映像 initramfs 中的“dm-verity”密钥，该密钥负责 Google/AOSP 的“验证启动”过程。Dm-verity（Google 的验证启动的一部分，它实现Linux 设备映射器）是一项内核功能，即它在 boot 映像（内核和 ramdisk）加载到 RAM 中后生效。它会验证随后加载的块设备；/system、（如果存在，则为 /vendor）和可选的其他设备。

有关详细信息，请参见此处、此处和此处。

Google 建议从验证启动 2 开始在引导加载程序中集成 libavb（用于验证 boot.img 完整性的本机代码）。

解锁引导加载程序

阅读此处以了解 BL 解锁的风险。

除非解锁引导加载程序，否则无法加载未签名的内核或恢复。要对操作系统进行任何修改，一个关键的过程是禁用 Android 引导加载程序 (aboot) 中内置的安全系统，该系统可保护只读分区免受意外（或故意）修改，以保护隐私、安全和 DRM。这就是所谓的“解锁 NAND”或“解锁引导加载程序”。您必须首先解锁引导加载程序才能修改分区“boot”或“recovery”并在 /system 上获得 root 访问权限。如果引导加载程序已锁定，则您只能对 /cache 和 /data 分区具有写入访问权限。设备上的其他所有内容都是只读的，并且引导加载程序会阻止将未签名的映像刷写到手机。解锁的引导加载程序会忽略 BootROM 启动的签名验证检查，然后转移到“SBL”，然后转移到“ABOOT”，同时加载内核或恢复。

一些较新的设备不允许在没有制造商许可的情况下直接解锁引导加载程序 (FRP)，以确保更高的安全性，即分区内容“devinfo”由 OEM 签名，未经其批准不得修改。获得许可后，提供了一种使用 PC 解锁 BL 的官方方法。尽管如此，由于解锁引导加载程序，某些与专有内容相关的功能可能会丢失。

DRM 用于保护内容不被复制。

由于移除了 DRM 安全密钥，设备上的某些预加载内容也可能无法访问。

Android Root

必读：Root 用户和 Linux 功能：Linux 与 Android 注意：解锁引导加载程序和 Root 会破坏“验证启动”。这可能是危险的。

为了在 Android 上执行某些特权任务，我们需要首先“root”该设备。由于无法从正在运行的 Android 操作系统中启动具有提升权限的进程，因此 root 通常涉及从具有所有功能的启动中运行 root 进程（su-守护进程）。超级用户请求由任何非特权程序通过执行“su”二进制文件提出，权限由应用程序管理。

在早期，root 通常涉及启动到自定义恢复模式，这反过来又挂载和修改 /system 文件。通常，某些守护进程的可执行二进制文件被替换为自定义脚本。为了解决因提高安全功能（SELinux、验证启动、SafetyNet 等）而导致的 OTA 和其他问题，引入了无系统 root 方法，该方法被最新的应用程序（如 Magisk）使用。它涉及修改 /boot 映像并将一些文件放在 /data 上。因此，注入了一个新的 init 服务，以满足新安全机制的所有必要要求。

在这两种情况下，锁定的引导加载程序都不会启动自定义恢复模式或修改后的内核 (boot.img)。请参阅验证启动。因此，需要解锁引导加载程序才能进行 root。但是，有时有可能在没有解锁引导加载程序的情况下获得 root 权限，但并非总是如此。

使用某种一键式 root 解决方案（KingRoot、Z4Root、KingoRoot 等）从正在运行的 ROM 中 root 手机的其他方法依赖于 Android 操作系统中的某些漏洞或漏洞利用。随着 Android 的每次新版本发布和改进的防御机制，制造此类安全漏洞变得越来越困难，尽管对于不同的供应商而言，情况也有所不同。最突出的是随着 Lollipop 和 Marshmallow 的发布，无系统方法不得不被引入，因为以前的方法无法工作。当使用这些不正确的 root 方法之一 root 手机时，很可能会在某个时候遇到“root 不完整”之类的消息。如果这样的 root 方法适用于您的设备，则令人震惊。此漏洞利用也是恶意软件进入您设备的一种方式。例如，请参阅 Magisk 安装 - 漏洞、此处和此处。一个非常流行的漏洞 dirty cow 后来被修补。

此外，对于某些设备，有一些技巧可以在不解锁引导加载程序的情况下刷写自定义恢复模式，这使用某种固件刷写工具（SPFlasher、MiFlasher 等）在下载模式下完成，因为下载模式甚至可以在加载引导加载程序/fastboot 之前访问设备。或者，如果您是编码专家，则可以模仿自定义恢复映像，使其看起来像工厂签名的固件，并通过库存恢复模式刷写它。但是，此漏洞利用也不是通用的解决方案。

因此，不需要任何漏洞利用的正确 root 方法是通过解锁的引导加载程序。在购买新手机时必须考虑这一点。让您远离 root 访问和解锁的引导加载程序有利于供应商。通过强迫您使用他们的 ROM（捆绑了一堆无用的膨胀软件应用程序），他们通过收集数据、显示广告和使用许多其他策略从您那里赚取大量资金（以及被迫的忠诚度）。选择提供内核源代码和解锁引导加载程序能力的品牌（当然是在客户承担责任且保修失效的情况下）。

固件更新协议（引导加载程序模式）

与 BL 类似，在每个设备上，可能存在一个或多个具有不同名称的 BL 模式，如引导加载程序模式、下载模式、紧急模式 (EDL)、ODIN (Samsung)、nvFlash 工具等。当我们在 BL 模式下启动时，设备卡在启动徽标上。一些工厂刷写器在这些模式下工作，例如 MiFlasher (Xiaomi) 和 SP Flash Tool（用于 MTK 设备）。即使设备软砖了，即如果无法访问恢复模式和/或 ROM，也可以访问引导加载程序或下载模式。

下载模式

下载模式（在设备开机时组合某些按钮；通常是音量上 + 音量下或音量下持续较长时间 + 电源）是许多供应商使用刷写器（软件）刷写工厂固件/更新的官方方法。紧急下载模式 (EDL)，正如它在小米设备上所称的那样，也可以通过 fastboot/adb 命令或使用某些跳线/跳线器访问。但是，为了确保更高的安全性，EDL 在某些较新的设备上被禁用。

下载模式是引导加载程序模式（在 PBL 或 SBL 阶段）的主要模式，可以在不解锁引导加载程序的情况下使用。 Odin (Samsung)、QPST/QFIL 在下载模式（Qualcomm HS-USB QDloader 9008）下工作。当我们在下载模式下启动时，设备卡在空白屏幕上。

快速启动模式

Fastboot - 由 ABOOT 提供 - 是一种软件开发工具和用于 Android 引导加载程序的标准通信协议。它是恢复刷写的替代方案，它在引导加载程序模式 (aboot) 下工作，并且捆绑在大多数最新的 ARM Qualcomm 设备上。它是一个通过命令行与设备进行交互的最小 UI，以防发生故障或修改/刷写分区。一些 OEM 提供的 fastboot 功能有限，例如 'fastboot oem' 命令不起作用，并且有些设备根本没有 fastboot。这取决于手机供应商的决定。

当设备通过 USB 连接到 PC 时，可以使用快速启动模式通过命令执行操作。即使手机未在恢复模式或 ROM 中打开，或者即使手机上未安装 Android，它也可以工作。您可以在此处阅读我们可以通过快速启动模式执行哪些操作。

在此阶段仅激活 NAND (eMMC) 和 USB 模块（驱动程序）。

INIT 进程和服务：Android 与 Linux

由 INIT 挂载的文件系统树：Android 与 Linux