ATF(Arm Trusted Firmware)/TF-A Chapter 04 Authentication Framework

本文深入剖析了嵌入式系统中TRUSTED_BOARD_BOOT=1的情况,详细阐述了固件加载和验证过程。从arm_bl1_platform_setup到load_auth_image,再到auth_mod_verify_img,解释了如何通过认证模块和图像解析模块检查镜像完整性和执行验签操作。文中提到了AUTH_METHOD_SIG和AUTH_METHOD_NV_CTR两种认证方法,以及防止rollback攻击的机制。此外,还讨论了如何利用非易失性计数器确保固件更新的安全性。

 

4.1. 代码分析

首先,重新分析之前忽略掉的 TRUSTED_BOARD_BOOT =1 的情况,bl1_platform_setup->arm_bl1_platform_setup->arm_load_tb_fw_config.

看138行,load_auth_image会调用load_auth_image_internal:

 

此时会执行236行宏控制的代码。243行,首先找到这个id的父id,递归调用认证镜像(我们也会注意到,如果支持TBBR,头文件中定义的stack大小也会相应的变大)。

237行,

当TRUSTED_BOARD_BOOT =1的前提下,并且定了DYN_DISABLE_AUTH,arm提供的这个方案是认证可以动态的打开和关闭,这在开发的时候是很有帮助的。先不定义DYN_DISABLE_AUTH,方便分析。

回到load_auth_image_internal,load前会获取这个image_id的parent_id,此时image_id=TB_FW_CONFIG_ID,

auth_mod_get_parent_id内部:

通过cot_desc_ptr这个全局变量,获取id的auth_img_desc_t类型的指针地址

cot_desc_ptr。通过查找代码,我们会发现在driver/tbbr/tbbr_cot.c中:

宏定义在include/driver/auth/auth_mod.h

Cot_desc是固定的,也在driver/tbbr/tbbr_cot.c中.

结构体变量类型:

看TB_FW_CONFIF的parent id:

证书级别:

通过密钥级别,递归到TRUSTED_BOOT_FW_CERT_ID已经没有父id了,auth_mod_get_parent_id返回非0,此时parent_id=TRUSTED_BOOT_FW_CERT_ID.在load_image后,继续load_auth_image_internal的260行.

auth_mod_verify_img(drivers/auth/auth_mod.c ,343行)是验签接口。

357行,首先检查镜像完整性。

img_parser_check_integrity是Image Parser Module (IPM)模块的接口之一,主要功能

  1. 检查通过IO framework加载的镜像完整性
  2. 根据由CoT描述符中的内容获取认证参数。

因为镜像可能有不同的格式(例如,认证镜像可以是x509v3证书,签名的ELF文件或平台特定的格式)。 IPM允许为CoT中的每种镜像格式分别注册一个镜像解析库Image Parser Library(IPL)。 实现具体的解析方法。 IPM从CoT获取镜像格式并调用正确的IPL来检查完整性并提取认证参数。

在代码中:

img_parser_check_integrity(Driver/auth/img_parser_mod.c, 66行)函数的84行

Parser_lib_indices是什么时候被赋值的?

bl1_main->auth_mod_init->img_parser_init:

第17,18行:

在bl1.ld.s中:

IPL必须实现如下接口:

并使用宏注册IPL函数:

我们看drivers/auth/mbedtls_x509_parser.c:

在include/driver/auth/img_parser_mod.h中:

函数的具体介绍在“auth-framework  1.2.1.   Describing the image parsing methods”有详细介绍。

注意:要想支持trust boot,即TRUSTED_BOARD_BOOT = 1和GENERATE_COT = 1则必须指定mbedtls库。需要先编译这个库。具体内容在后面的章节中分析。

img_parser_check_integrity完成后,获取认证方法,认证方法在定义cot时,已经写好了。

看TRUSTED_BOOT_FW_CERT_ID的auth_method,在auth_img_desc_s的auth_method_desc_t中:

有两种认证方法:AUTH_METHOD_SIG和AUTH_METHOD_NV_CTR,第一个方法很好理解,

关于auth_img_desc_s,有以下几种认证方法:

认证相关的接口,由 Authentication Module (AM)提供:

认证流程:

  1. 由IPM的get_auth_param()函数,从镜像中提取认证参数。
  2. 在调用Cryptographic Module (CM)和 TF-A Platform Port (PP)的验证函数时,对参数进行预处理。
  3. 从父镜像中提取验证参数用来验证子镜像

第二个:

是最新增加的认证方法,防止rollback攻击。所以,对于可更新的固件来说,需要进行两次认证。这个方法在后面有分析。

 

auth_mod_verify_img执行时,会按顺序循环调用所有有效的认证方法,首先是AUTH_METHOD_SIG的auth_signature函数,传入的参数是auth_method->param.sig = .img_auth_methods.param.sig,变量使用宏定义,例如pk结构体:

结构体的第二个参数,前面说了,是用来在x509中定位扩展域的OID指针,告诉认证代码,要提取的hash或者公钥数据的指针,0表示不使用这个字段。

auth_signature的第二个参数img_desc=auth_img_desc_t类型的TRUSTED_BOOT_FW_CERT_ID,第三四个参数分别是base addr和length。

154,158,164行,最终会调用SoC厂商自己实现的注册在IPL接口中的get_auth_param函数指针指向的函数。

171行,获取parent的参数,对当前的image验签。由于没有parent,所以执行174行的plat_get_rotpk_info,否则会先获取parent的参数。plat_get_rotpk_info在porting guide中:

ROPTK必须是ASN.1格式的DER编码,有两种形式,一是返回ROTPK本身,另一个是返回他的hash。通过int plat_get_rotpk_info(void *cookie, void **key_ptr, unsigned int *key_len,

unsigned int *flags) 的flag参数区分

如果返回的是hash,则必须先使用ROTPK对image验签,在比较ROTPK的hash

如果flag是ROTPK_NOT_DEPLOVED,则跳过ROTPK hash比较。

在回到171行,除了跟证书之外,会执行auth_get_param获取pk_ptr,并且此时flag=0,直接对当前的image验签。

继续分析第二个验签方法AUTH_METHOD_NV_CTR:auth_mod_verify_img中,337行:

看下注释怎么说的(drivers/auth/auth_mod.c):

硬件上,SoC有一个non-volatile计数器,值只能增加。

证书中,所有证书都包含一个计数器值。

证书的值不应低于non-volatile计数器的值。 如果证书的值较大,则必须将non-volatile计数器的值更新为新值。

返回到auth_mod_verify_img,两个认证完成后,还需要更新认证数据。

auth_mod_verify_img(Drivers/auth/auth_mod.c ,390行,)把需要的类型拷贝到ptr指向的地址中:

看下TRUSTED_BOOT_FW_CERT_ID需要的认证数据有哪些类型:

最后,置标志位:

递归返回后,所有的加载并认证镜像的工作完成。

4.2 模块划分

本章结束。

<think> 我们正在分析一个Makefile命令:`$(ATF_MAKE) -C $(ATF_DIR)/arm-trusted-firmware-2.3 PLAT=$(TCSOCNAME) distclean -j10` 根据之前的讨论,我们已经知道: - `ATF_MAKE` 指向ATF自带的make工具,即`$(ATF_DIR)/make` - `ATF_DIR` 是ATF源码的根目录 现在,我们将详细解释这个命令及其输出内容的含义和作用。 命令分解: 1. `$(ATF_MAKE)`:调用ATF自带的make工具。这通常是一个特定版本的make,或者是一个封装了环境设置的make脚本。 2. `-C $(ATF_DIR)/arm-trusted-firmware-2.3`:`-C`选项告诉make工具切换到指定的目录(这里是ATF的具体版本目录)下执行命令。 3. `PLAT=$(TCSOCNAME)`:这是一个变量赋值,它将传递给Makefile。`PLAT`是ARM Trusted Firmware中定义的一个变量,用于指定目标硬件平台(例如,imx8mm,rk3399等)。`$(TCSOCNAME)`是当前构建系统中定义的变量,其值为目标SoC的名称。 4. `distclean`:这是Makefile中的一个目标(target),它的作用是清除构建过程中生成的所有文件,包括配置文件,使得目录回到未构建的状态(类似于初始状态)。 5. `-j10`:指定并行执行的任务数,这里是10个并行任务,用于加速清理过程(因为清理过程中删除多个文件可以并行执行)。 作用: 这条命令的作用是:在指定的ATF版本目录(`arm-trusted-firmware-2.3`)中,使用ATF自带的make工具,针对特定的硬件平台(由`TCSOCNAME`指定),执行`distclean`目标,以多线程(10个线程)的方式清除所有构建生成的文件。 输出内容: 当我们运行这个命令时,输出内容通常包括: - make工具进入指定目录的提示(如果有相关日志设置) - 执行`distclean`目标所触发的具体命令,例如删除构建目录(`build`)、中间文件(`*.o`)、配置文件(`*.config`)等。 - 由于是并行执行,删除操作可能会同时进行,但输出通常是顺序的,每条命令执行的状态(成功或失败)会被打印出来。 示例输出(模拟): ``` make[1]: Entering directory '/path/to/arm-trusted-firmware-2.3' PLAT=imx8mm CLEAN build/imx8mm/release RM build/imx8mm/release/bl1/bl1.elf RM build/imx8mm/release/bl1/bl1.bin ... (更多删除的文件) make[1]: Leaving directory '/path/to/arm-trusted-firmware-2.3' ``` 重要性: 在执行新的构建之前,通常需要执行清理操作,以确保构建环境是干净的,避免之前构建残留的文件影响新构建的结果。尤其是在切换平台(PLAT)或者更改了配置后,清理操作尤为重要。 注意事项: 1. 由于使用了并行选项(-j10),如果目录结构很大,删除操作会很快,但有时可能会因为文件过多而出现权限问题或文件正在使用中的错误(虽然清理时通常不会遇到文件占用)。 2. 如果`distclean`目标在Makefile中没有定义,那么该命令会失败。但是,在ARM Trusted Firmware中,通常都提供了`distclean`目标。 3. 确保`ATF_DIR`和`TCSOCNAME`变量已经正确设置,否则命令会失败。 总结: 该命令是一个针对特定硬件平台(`PLAT=$(TCSOCNAME)`)的ATF项目的多线程清理命令,用于彻底删除构建产物,为下一次构建做准备。 </think> ### 命令解析:`$(ATF_MAKE) -C $(ATF_DIR)/arm-trusted-firmware-2.3 PLAT=$(TCSOCNAME) distclean -j10` #### 1. **命令结构分解** | 组件 | 含义 | 作用 | |------|------|------| | `$(ATF_MAKE)` | ATF专用make工具 | 执行ARM Trusted Firmware的自定义构建系统<br>(避免系统make版本冲突)[^1] | | `-C $(ATF_DIR)/arm-trusted-firmware-2.3` | 切换工作目录 | 定位到ATF 2.3版本的源码目录<br>(`-C`参数等效于`cd`命令) | | `PLAT=$(TCSOCNAME)` | 平台标识变量 | 指定目标SoC平台<br>(如`PLAT=imx8mm`或`PLAT=rk3399`) | | `distclean` | 清理目标 | 彻底删除所有构建产物<br>(比`clean`更彻底,包含配置文件) | | `-j10` | 并行任务数 | 启用10线程并行清理<br>(加速大项目清理过程) | #### 2. **执行流程** ```mermaid graph TD A[调用ATF专用make] --> B[切换到ATF-2.3目录] B --> C[加载平台配置] C --> D[执行distclean] D --> E[并行删除10类文件] E --> F[输出清理报告] ``` #### 3. **典型输出内容及含义** ```bash $ make distclean -j10 make[1]: Entering directory '/atf/arm-trusted-firmware-2.3' CLEAN build/imx8mm/release/bl1 RM build/imx8mm/release/bl1.o CLEAN build/imx8mm/release/bl31 RM build/imx8mm/release/fip.bin CLEAN docs RM config.mk platform_auto.mk make[1]: Leaving directory '/atf/arm-trusted-firmware-2.3' ``` - **`Entering directory`**:确认工作目录切换成功 - **`CLEAN`**:目录级清理操作 - **`RM`**:具体文件删除操作 - **`Leaving directory`**:执行完成退出 - **无错误提示**:表示完整清理(出现错误会显示`Error 1`) #### 4. **核心作用** 1. **环境重置** 清除所有编译生成文件(`.o`, `.bin`, `.elf`等)和配置缓存 $$ \text{删除文件数} \geq \sum(\text{源码文件数} \times \text{平台变体数}) $$ 2. **版本隔离** 确保: - 指定ATF 2.3版本目录 - 区分不同SoC平台(`PLAT=`参数) - 使用ATF专用构建工具 3. **构建准备** 为以下操作创建干净环境: - 跨平台编译(ARMv7/ARMv8) - 配置变更(如切换安全启动模式) - 工具链更新(如GCC版本升级)[^2] #### 5. **应用场景** - **SDK环境初始化** 在构建Yocto/Buildroot镜像前执行 - **持续集成(CI)** Jenkins流水线中每次构建前自动调用 - **故障排查** 解决因残留文件导致的构建失败: ```bash # 常见构建错误示例 Error: BL31 image overlap with BL2 Solution: distclean → rebuild ``` > 该命令是嵌入式Linux开发中的**关键维护操作**,可避免因环境残留导致的构建一致性问题[^3]。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值