2. 固件与版本管理基础

固件防回滚与版本安全工程的第一步，不是写校验代码，而是把“固件是什么、怎么启动、版本号怎么定义、版本如何流转、更新机制如何工作”这些基础问题讲清楚。只有建立统一的版本语义和更新模型，后续的签名校验、防降级策略、回滚窗口设计才有可靠的判断依据。

一、固件组成：不只是“一个bin文件”

从工程视角看，固件通常由多个可独立寻址、独立校验的镜像段组成。以典型的 MCU/SoC 设备为例，一次完整固件包往往包含：

• Boot ROM / 固化引导：芯片出厂固化，不可修改，负责最初始的信任根加载。
• Bootloader（一级/二级）：负责校验、搬运、跳转到应用；常带 A/B 分区切换逻辑。
• 应用固件（Application）：业务主程序，包含 .text、.rodata、.data、.bss 等段。
• 配置区 / 参数区：设备序列号、校准参数、网络配置、密钥槽等。
• 元数据（Metadata）：版本号、构建时间、签名、哈希、硬件兼容列表、回滚计数器。

其中，元数据是版本安全的核心载体。防回滚判断依赖的版本号、安全版本号（Security Version Number, SVN）、回滚计数器，通常都存放在元数据区，并由签名保护。

二、启动流程：信任链与版本检查的插入点

典型的安全启动流程如下：Boot ROM 验证一级 Bootloader 签名 → 一级 Bootloader 验证二级 Bootloader → 二级 Bootloader 验证应用固件 → 跳转执行。防回滚检查通常插入在“验证签名”之后、“跳转执行”之前，因为此时才能同时拿到镜像内容和元数据。

三、版本号规范：语义化与安全版本号

版本号不是随便递增的数字。工程上推荐采用语义化版本（Semantic Versioning）格式：MAJOR.MINOR.PATCH，例如 3.2.1。其中 MAJOR 表示不兼容变更，MINOR 表示向后兼容的功能新增，PATCH 表示向后兼容的问题修复。

但防回滚场景还需要一个独立于语义化版本的安全版本号（SVN）。SVN 只增不减，专门用于判断“这个固件是否比当前运行版本更旧”。语义化版本可能因为产品命名策略出现回退，而 SVN 必须严格单调递增。

固件版本元数据示例（JSON）：
{
  "version": "3.2.1",
  "svn": 17,
  "build_time": "2025-06-15T10:30:00Z",
  "hardware_compat": ["revA", "revB"],
  "min_bootloader_svn": 5,
  "signature": "MEUCIQ...",
  "sha256": "a3f5c9..."
}

四、版本生命周期与常见更新机制

一个固件版本从构建到退役，通常经历：开发构建 → 内部测试 → 发布候选 → 正式发布 → 灰度推送 → 全量推送 → 维护更新 → 停止支持（EOL）。每个阶段都应有明确的版本号、签名和回滚策略。

常见固件更新机制包括：

五、案例与误区复盘