3. TF-M 概述
Trusted Firmware-M（简称 TF-M）是 Arm 主导的开源可信固件项目，目标是在基于 Armv8-M 架构（含 TrustZone-M）的微控制器上，提供一套符合 PSA Certified 与 PSA Firmware Framework for M（PSA-FF-M）规范的安全固件实现。它把安全启动、安全分区隔离、安全服务调用、密钥与密码学操作等能力，封装成可裁剪、可移植、可认证的软件栈，使 MCU 厂商与设备开发者不必从零构建可信根。
项目背景：从“能启动”到“可被信任”
在传统 MCU 开发中，固件通常只有一个执行环境，应用代码、通信协议栈与密钥处理逻辑混在一起。一旦通信协议栈或第三方库出现漏洞，攻击者就可能直接读取密钥、篡改启动流程或劫持设备。随着物联网设备接入云端、执行 OTA 升级、承载身份凭证，MCU 需要一套“可被验证的信任链”。
TF-M 的出现正是为了解决三个核心问题：第一，建立从不可变 ROM 到安全分区、再到非安全应用的启动信任链；第二，利用 TrustZone-M 的硬件隔离，把安全服务与非安全应用分离；第三，提供标准化的安全服务接口（PSA Crypto、PSA Attestation、PSA Internal Trusted Storage 等），让上层应用以统一方式调用安全能力。它由 Linaro、Arm 及多家芯片厂商共同维护，是 PSA 生态在 MCU 侧的关键落地组件。
一句话定位：TF-M 是 MCU 上的“安全操作系统内核 + 安全服务运行时”，它不直接面向最终业务，而是为业务提供可信执行环境与标准安全服务。
架构组成：启动、隔离与服务三层视角
TF-M 的架构可以从启动流程、运行时隔离和安全服务三个维度理解。启动维度上，BL1（不可变引导）验证 BL2，BL2 验证安全镜像与非安全镜像，最终跳转到安全分区管理器；隔离维度上，安全侧被划分为多个安全分区，非安全侧运行应用与 RTOS；服务维度上，每个安全分区对外暴露一组 PSA 接口，通过 IPC 或函数调用被非安全侧访问。
下图展示了 TF-M 的典型架构组成与数据流关系：非安全应用通过 PSA API 发起请求，经 SPE 客户端与 IPC 进入安全分区，安全分区调用底层驱动或密码学硬件，最终返回结果。
核心组件：SPM、安全分区与平台移植层
TF-M 的核心组件可以归纳为四类。第一类是安全分区管理器 SPM，它负责安全分区的加载、调度、内存隔离与 IPC 路由，是安全侧的内核。第二类是安全服务分区，包括 Crypto、Internal Trusted Storage（ITS）、Protected Storage（PS）、Attestation、Firmware Update 等，每个分区独立编译、独立配置权限。第三类是平台移植层，包含启动代码、时钟与电源、Flash 驱动、TRNG 驱动、MPU/SAU 配置等，是 TF-M 与具体 MCU 的粘合层。第四类是构建与配置系统，通过 CMake 与 Kconfig 风格选项裁剪分区、选择密码学后端、配置栈大小与日志级别。
下面是一个典型的 TF-M 构建配置片段，展示了如何选择平台与安全服务：
# 以 AN547 平台为例，裁剪安全服务
cmake -S trusted-firmware-m -B build \
-DTFM_PLATFORM=arm/mps3/an547 \
-DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake \
-DTFM_PARTITION_CRYPTO=ON \
-DTFM_PARTITION_INTERNAL_TRUSTED_STORAGE=ON \
-DTFM_PARTITION_ATTESTATION=ON \
-DTFM_PARTITION_FIRMWARE_UPDATE=OFF \
-DMCUBOOT_IMAGE_NUMBER=2
# 编译后产出：
# tfm_s.bin 安全侧镜像
# tfm_ns.bin 非安全侧镜像
# bl2.bin 引导加载程序
与 TF-A、OP-TEE 的关系：同源不同场景
TF-M、TF-A（Trusted Firmware-A）与 OP-TEE 同属“可信固件”家族，但面向的硬件与使用场景不同。TF-A 面向 Armv8-A 应用处理器，负责 A 核的启动阶段划分（BL1/BL2/BL31/BL32/BL33）与安全监控；OP-TEE 是运行在 A 核安全世界中的可信操作系统，提供 TEE 内部 API 与 TA 加载能力；TF-M 则面向 Armv8-M 微控制器，利用 TrustZone-M 在单核或双核 MCU 上实现安全隔离。
三者的关系可以概括为：TF-A 是 A 核的“启动与安全监控固件”，OP-TEE 是 A 核的“安全操作系统”，TF-M 是 M 核的“安全固件与安全服务运行时”。在异构系统中，M 核常作为安全协处理器运行 TF-M，A 核运行 TF-A + OP-TEE，两者通过 mailbox 或共享内存通信，形成“主处理器 + 安全 MCU”的架构。
| 对比维度 | TF-M | TF-A | OP-TEE |
|---|---|---|---|
| 目标硬件 | Armv8-M MCU（TrustZone-M） | Armv8-A 应用处理器 | Armv8-A 安全世界 |
| 核心职责 | 安全启动、分区隔离、PSA 服务 | 启动阶段划分、安全监控 | 可信 OS、TA 加载与调度 |
| 隔离机制 | TrustZone-M + MPU/SAU | EL 异常等级 + TrustZone-A | EL1/EL0 + 安全世界 |
| 典型接口 | PSA API（Crypto/ITS/Attest） | PSCI、SMC、BL 镜像接口 | TEE Internal Core API、TA |
| 常见组合 | M 核安全协处理器 | A 核启动固件 | A 核 TEE 运行环境 |
案例场景：智能门锁的安全启动与密钥调用
以智能门锁为例，设备上电后 BL1 从 ROM 运行，验证 BL2 签名；BL2 验证 TF-M 安全镜像与非安全应用镜像；安全镜像启动后，SPM 初始化 Crypto、ITS、Attestation 分区；非安全侧的应用通过 PSA Crypto API 请求生成会话密钥，通过 PSA ITS 存储设备身份凭证。攻击者即使攻破非安全侧协议栈，也无法直接读取安全分区内的密钥，因为 TrustZone-M 与 MPU 已阻止非法访问。
实践提示：移植 TF-M 时，优先确认芯片是否支持 TrustZone-M、是否有独立的安全 Flash/RAM 区域、TRNG 是否可用。这三项直接决定安全分区能否正常运行。
常见误区与复盘
- 误区一：把 TF-M 当成普通 RTOS。TF-M 不提供通用任务调度与文件系统，它的核心是安全隔离与安全服务，业务逻辑应放在非安全侧。
- 误区二：认为启用 TF-M 就自动安全。安全分区配置、密钥生命周期、调试口保护、OTA 签名验证同样关键，TF-M 只是提供基础能力。
- 误区三：忽略平台移植层。不同 MCU 的 Flash 驱动、TRNG、MPU 配置差异很大，移植层质量直接影响启动成功率与安全强度。
- 误区四：混淆 TF-M 与 OP-TEE 的 API。两者都提供安全服务，但接口规范、运行环境与部署位置不同，不能直接互换代码。
复盘建议：在项目初期就明确“哪些资产必须放入安全侧、哪些服务需要独立分区、非安全侧通过哪些 PSA 接口访问”，避免后期因分区划分不合理导致重构。
总体来看，TF-M 是 MCU 安全能力的标准化载体。理解它的项目背景、架构组成、核心组件以及与 TF-A、OP-TEE 的分工关系，是后续进行安全分区开发、平台移植与安全认证的基础。