8-Trusted Board Boot

引流关键词: 中断、同步异常、异步异常、irq、fiq、BL1,BL2,BL3,BL31,BL32,BL33,AP_BL1,AP_BL2,AP_BL3,AP_BL31,AP_BL32,AP_BL33,SCP_BL1,SCP_BL2,BL0,BL30, optee、ATF、TF-A、Trustzone、optee3.14、MMU、VMSA、cache、TLB、arm、armv8、armv9、TEE、安全、内存管理、页表…

快速链接:
.
👉👉👉 个人博客笔记导读目录(全部) 👈👈👈


[专栏目录]-ATF/FF-A/specification学习

请添加图片描述

8.受信任的板引导

受信任的板引导 (TBB) 功能通过验证所有固件映像(包括普通世界引导加载程序)来防止恶意固件在平台上运行。它通过使用公钥密码标准 (PKCS) 建立信任链来做到这一点。

本文档描述了受信任固件 A (TF-A) TBB 的设计,它是受信任的板引导要求 (TBBR)规范 Arm DEN0006D 的实现。它应该与 固件更新 (FWU)设计文档一起使用,该文档实现了 TBBR 的特定方面。

8.1。信任链

信任链 (CoT) 从一组隐式可信组件开始。在 Arm 开发平台上,这些组件是:

  • 信任根公钥 (ROTPK) 的 SHA-256 哈希。它存储在受信任的根密钥存储寄存器中。或者,可以使用开发 ROTPK 并将其哈希嵌入到 BL1 和 BL2 映像中(仅用于开发目的)。

  • BL1 映像,假设它驻留在 ROM 中,因此不能被篡改。

CoT 中的其余组件是证书或引导加载程序映像。证书遵循X.509 v3标准。该标准允许向证书添加自定义扩展,这些扩展用于存储建立 CoT 的基本信息。

在 TBB CoT 中,所有证书都是自签名的。不需要证书颁发机构 (CA),因为 CoT 不是通过验证证书颁发者的有效性而是通过证书扩展的内容来建立的。要对证书进行签名,可以使用不同的签名方案,请参阅构建选项了解更多详细信息。

证书分为“密钥”和“内容”证书。密钥证书用于验证已用于签署内容证书的公钥。内容证书用于存储引导加载程序映像的哈希值。图像可以通过计算其哈希值并将其与从内容证书中提取的哈希值进行匹配来进行身份验证。支持各种哈希算法来计算所有哈希,请参阅构建选项 了解更多详细信息。公钥和哈希作为非标准扩展字段包含在X.509 v3证书中。

用于建立 CoT 的密钥是:

  • 信任根密钥
    此密钥的私有部分用于签署 BL2 内容证书和可信密钥证书。公共部分是ROTPK。

  • 可信世界密钥
    私有部分用于签署与安全世界映像(SCP_BL2、BL31 和 BL32)对应的密钥证书。公共部分存储在可信世界证书的扩展字段之一中。

  • 不可信的世界密钥
    私有部分用于签署非安全世界镜像(BL33)对应的密钥证书。公共部分存储在可信世界证书的扩展字段之一中。

  • BL3X 按键

对于 SCP_BL2、BL31、BL32 和 BL33 中的每一个,私有部分用于签署 BL3X 图像的内容证书。公共部分存储在相应密钥证书的扩展字段之一中。

CoT 中包含以下镜像:

  • BL1

  • BL2

  • SCP_BL2(可选)

  • BL31

  • BL33

  • BL32(可选)

以下证书用于对镜像进行身份验证。

  • BL2内容证书
    它使用 ROT 密钥的私有部分进行自签名。它包含 BL2 图像的散列。

  • 可信密钥证书
    它使用 ROT 密钥的私有部分进行自签名。它包含可信世界密钥的公共部分和非可信世界密钥的公共部分。

  • SCP_BL2 密钥证书
    它使用受信任的世界密钥进行自签名。它包含 SCP_BL2 密钥的公共部分。

  • SCP_BL2 内容证书
    它使用 SCP_BL2 密钥自签名。它包含 SCP_BL2 图像的散列。

  • BL31密钥证书
    它使用受信任的世界密钥进行自签名。它包含 BL31 密钥的公共部分。

  • BL31内容证书
    它是使用 BL31 密钥自签名的。它包含 BL31 图像的散列。

  • BL32密钥证书
    它使用受信任的世界密钥进行自签名。它包含 BL32 密钥的公共部分。

  • BL32内容证书
    它是使用 BL32 密钥自签名的。它包含 BL32 图像的哈希。

  • BL33密钥证书
    它使用不受信任的世界密钥自签名。它包含 BL33 密钥的公共部分。

  • BL33内容证书
    它是使用 BL33 密钥自签名的。它包含 BL33 图像的散列。

SCP_BL2 和 BL32 证书是可选的,但如果存在相应的 SCP_BL2 或 BL32 映像,则它们必须存在。

8.2. 受信任的板引导序列

CoT 通过以下一系列步骤进行验证。如果任何步骤失败,系统就会出现紧急情况。

  • BL1 加载并验证 BL2 内容证书。从已验证的证书中读取颁发者公钥。计算该密钥的哈希值,并将其与从可信根密钥存储寄存器读取的 ROTPK 哈希值进行比较。如果它们匹配,则从证书中读取 BL2 哈希。
    注意:匹配操作是特定于平台的,目前未在 Arm 开发平台上实现。

  • BL1 加载 BL2 图像。计算其哈希值并与从证书中读取的哈希值进行比较。如果所有比较都成功,则控制转移到 BL2 图像。

  • BL2 加载并验证可信密钥证书。从已验证的证书中读取颁发者公钥。计算该密钥的哈希值,并将其与从可信根密钥存储寄存器读取的 ROTPK 哈希值进行比较。如果比对成功,BL2 从已验证的证书中读取并保存可信和不可信的世界公钥。

为每个 SCP_BL2、BL31 和 BL32 图像执行接下来的两个步骤。如果这些图像不存在,则跳过可选 SCP_BL2 和 BL32 图像的步骤。

  • BL2 加载并验证 BL3x 密钥证书。证书签名使用可信世界公钥进行验证。如果签名验证成功,BL2 从证书中读取并保存 BL3x 公钥。

  • BL2 加载并验证 BL3x 内容证书。使用 BL3x 公钥验证签名。如果签名验证成功,BL2 从证书中读取并保存 BL3x 图像哈希。

接下来的两个步骤仅针对 BL33 图像执行。

  • BL2 加载并验证 BL33 密钥证书。如果签名验证成功,BL2 从证书中读取并保存 BL33 公钥。

  • BL2 加载并验证 BL33 内容证书。如果签名验证成功,BL2 从证书中读取并保存 BL33 图像哈希。

对所有引导加载程序映像执行下一步。

  • BL2 计算每个图像的哈希值。它将它与从相应的内容证书中获得的散列进行比较。如果哈希匹配,则图像身份验证成功。

Trusted Board Boot 实现涵盖通用和特定平台的 BL1 和 BL2 代码,以及主机构建机器上的工具代码。该功能通过使用特定的构建标志来启用,如 构建选项中所述。

在主机上,一个工具会生成证书,这些证书与引导加载程序映像一起包含在 FIP 中。这些证书使用 IO 存储框架加载到 Trusted SRAM 中。然后它们由 TF-A 中包含的身份验证模块进行验证。

用于生成 FIP 和身份验证模块的机制将在以下部分中描述。

8.3. 身份验证框架

TF-A 中包含的身份验证框架为实现所需的受信任启动序列提供了支持。Arm 平台使用此框架来实现 受信任的板引导要求 (TBBR)文档中指定的引导要求。

有关身份验证框架的更多信息,请参阅身份 验证框架和信任链文档。

8.4. 证书生成工具

当. cert_create_ GENERATE_COT=1它将引导加载程序映像和密钥作为输入(密钥必须为 PEM 格式)并生成建立 CoT 所需的证书(DER 格式)。如果未提供新密钥,则该工具可以生成新密钥。然后将证书作为输入传递给fiptool用于创建 FIP 的实用程序。

证书也单独存储在输出构建目录中。

该工具位于tools/cert_create目录中。它使用 OpenSSL SSL 库版本来生成 X.509 证书。所需的库的特定版本在先决条件文档中给出。

构建和使用该工具的说明可以在 构建证书生成工具中找到。

8.5。认证加密框架

TF-A 中包含的经过身份验证的加密框架支持实现可选的固件加密功能。可以选择在平台上启用此功能以实现可选要求:R060_TBBR_FUNCTION,如受信任的板引导要求 (TBBR) 文档中指定的那样。

8.6. 固件加密工具

当. encrypt_fw_ 它将普通固件映像作为输入并生成加密固件映像,然后可以将其作为输入传递给实用程序以创建 FIP。DECRYPTION_SUPPORT != nonefiptool

加密的固件也单独存储在输出构建目录中。

该工具位于tools/encrypt_fw目录中。它使用 OpenSSL SSL 库版本 1.0.1 或更高版本来执行经过身份验证的加密操作。构建和使用该工具的说明可以在 构建固件加密工具中找到。

<think>好的,我现在要详细解释U-Boot的启动流程。首先,我需要回忆U-Boot的基本结构和启动阶段。U-Boot是嵌入式系统中常用的引导加载程序,负责初始化硬件并加载操作系统。它的启动流程涉及多个阶段,每个阶段有不同的任务。 首先,启动流程通常从CPU上电开始,执行固化在ROM中的代码,比如芯片厂商提供的Boot ROM。这个阶段会初始化最基本的硬件,如时钟、内存控制器,然后加载SPL(Secondary Program Loader)。SPL是U-Boot的一部分,负责在内存初始化之前运行,因为它可能需要从存储设备(如MMC、NAND)加载完整的U-Boot到内存中。 接下来是SPL的执行。SPL需要初始化必要的外设,比如DRAM控制器,然后从存储介质中读取完整的U-Boot镜像到内存中。这里可能会有不同存储设备的处理,比如SD卡、eMMC、NOR/NAND Flash等,需要据具体的板级配置来初始化对应的驱动。 一旦完整的U-Boot被加载到内存中,控制权就转交给U-Boot的start.S,这是U-Boot的入口点。start.S通常用汇编语言编写,负责设置CPU模式(如切换到SVC模式)、关闭中断、设置堆栈指针等底层初始化工作。然后会调用board_init_f函数,进行早期的板级初始化,比如内存分配、全局数据结构的设置。 board_init_f之后,会进行重定位,将U-Boot自身从加载地址复制到链接地址,这通常在内存的高端地址。重定位完成后,调用board_init_r函数,进行更复杂的板级初始化,包括设备驱动初始化、环境变量加载、命令行接口准备等。此时,U-Boot会初始化各种子系统,如串口、网络、存储设备等,以便用户可以交互。 最后,U-Boot进入主循环,等待用户输入命令或者执行自动启动流程。自动启动时,U-Boot据环境变量(如bootcmd)加载内核镜像到内存,传递启动参数,并跳转到内核的入口点。 在这个过程中,我需要确认每个阶段的具体任务是否正确,比如SPL的作用,重定位的必要性,以及不同板级配置的差异。可能还需要考虑不同架构(如ARM、MIPS)之间的差异,但假设问题主要针对ARM架构。此外,需要注意U-Boot的配置选项,比如是否启用SPL,不同的存储介质处理方式等。如果有错误或遗漏的地方,需要修正,比如是否在board_init_f之前有其他初始化步骤,或者重定位的具体实现细节。同时,要确保术语准确,比如正确区分SPL和U-Boot proper,以及各初始化函数的调用顺序。</think>以下是对U-Boot启动流程的深度技术解析,按执行顺序分为六个关键阶段: ``` [启动流程架构图] ROM Code → SPL → TPL(可选) → U-Boot Proper → Kernel → OS │ │ └─MLO─────┘(针对OMAP等特殊架构) ``` ### 一、ROM Bootloader阶段 1. **触发条件**: - 芯片复位向量(ARM架构通常为0x00000000或0xFFFF0000) - 通过BOOT引脚选择启动介质(NAND/SD/eMMC等) 2. **核心任务**: - 初始化CPU核心时钟(PLL配置) - 配置最小可用内存(SRAM或片上RAM) - 加载SPL到SRAM(如TI SoC的MLO文件) 3. **典型代码位置**: ```assembly /* ARMv7复位向量示例 */ .globl _start _start: b reset ... reset: /* 关闭MMU和缓存 */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x00002000 @ 关闭MMU bic r0, r0, #0x00000005 @ 关闭D-cache和分支预测 mcr p15, 0, r0, c1, c0, 0 /* 设置临时堆栈指针 */ ldr sp, =CONFIG_SPL_STACK /* 跳转到C入口 */ bl spl_main ``` ### 二、SPL(Secondary Program Loader)阶段 1. **代码入口**: - `spl\arm\crt0.S`中的`_start`符号 - 主要文件:`common/spl/spl.c` 2. **关键流程**: ```c void spl_main(void) { arch_cpu_init(); // CPU架构初始化 board_init_f(0); // 早期板级初始化 spl_load_image(); // 加载U-Boot Proper jump_to_image_no_args(&spl_image); // 跳转 } ``` 3. **内存初始化细节**: - DDR控制器参数配置(时序、PHY校准) - 内存训练(High-Speed SerDes初始化) - 内存映射表建立(通过`dram_init_banksize()`) ### 三、U-Boot Proper阶段 1. **执行入口**: - `arch/arm/lib/crt0.S`中的`_main` - 调用链:`_main → board_init_f → relocate_code → board_init_r` 2. **重定位机制**: ```c // 重定位偏移量计算 gd->reloc_off = (ulong)dest_addr - (ulong)__image_copy_start; // 重定向全局数据结构 gd->relocaddr = dest_addr; gd->ram_size = CONFIG_SYS_SDRAM_SIZE; ``` 3. **设备树处理流程**: - 初始DTB位置:`CONFIG_SYS_FDT_BASE` - 重定位后通过`fdt_shrink_to_minimum()`压缩DTB - 通过`fdtdec_setup()`更新内存节点 ### 四、驱动初始化顺序 1. **关键初始化序列**: ```c board_init_r() { serial_initialize(); // 串口子系统 dm_scan_platdata(); // 设备树解析 mmc_initialize(); // 存储设备初始化 env_initialize(); // 环境变量加载 set_cpu_clk_info(); // 时钟树构建 initr_net(); // 网络子系统 } ``` 2. **环境变量处理**: - 存储介质优先级:`ENV_IMPORT_FDT` > `ENV_IS_IN_MMC` > `ENV_IS_IN_SPI_FLASH` - 变量覆盖机制:`env_import()` → `himport_r()` ### 五、自动引导流程 1. **bootcmd执行逻辑**: ```c void autoboot_command(const char *s) { char *autoboot = env_get("bootcmd"); if (autoboot) run_command_list(autoboot, -1, 0); } ``` 2. **典型内核加载步骤**: ```bash # 环境变量示例 bootcmd=mmc dev 0; fatload mmc 0:1 0x80008000 zImage; fatload mmc 0:1 0x83000000 dtb; bootz 0x80008000 - 0x83000000 ``` 3. **ATF(ARM Trusted Firmware)集成**: - BL2 → BL31 → U-Boot(BL33)启动链 - PSCI服务初始化(CPU热插拔、电源管理) ### 六、高级调试技巧 1. **异常追踪方法**: ```bash # 开启调试日志 setenv bootargs earlycon console=ttyS0,115200 debug # 查看重定位信息 md.l 0x1ffb7230 1 # gd->relocaddr地址 ``` 2. **JTAG调试配置**: ```gdb target remote :3333 add-symbol-file u-boot 0x8ff00000 b board_init_f ``` **性能优化关键点**: 1. 减少SPL大小:`CONFIG_SPL_FRAMEWORK`裁剪 2. 加速DDR初始化:预校准参数存储到OTP 3. 快速启动配置:`CONFIG_BOOTDELAY=0`跳过倒计时 **启动时间优化示例**: ```c // 在include/configs/myboard.h中配置 #define CONFIG_SKIP_LOWLEVEL_INIT // 跳过重复的lowlevel_init #define CONFIG_BOOTSTAGE_REPORT // 启动阶段耗时分析 #define CONFIG_HW_WATCHDOG // 硬件看门狗优化 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Arm精选

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值