3. 中断应急处理原则：原子性、可恢复性、完整性、安全性

固件升级过程中，最怕的就是突然断电、通信中断或者芯片异常复位。我做了这么多年嵌入式，见过太多因为中断处理不当导致设备变砖的案例。说白了，升级中断本身不可怕，可怕的是你没有一套靠谱的应急处理机制。

这一章，我们来聊聊中断应急处理的四个核心原则。我个人习惯把它们称为「四大护法」——原子性、可恢复性、完整性、安全性。这四个原则，是你在设计任何升级方案时必须刻在脑子里的东西。

3.1 原子性：要么全做，要么全不做

原子性这个概念，搞过数据库的人应该不陌生。在固件升级里，原子性指的是：一个写操作要么完整执行，要么完全不执行，不能出现「写了一半」的状态。

为什么这么重要？你想想看，如果写Flash的时候突然断电，扇区只擦除了50%，或者数据只写了一半——那这块Flash就处于一个「半残」状态。下次上电，程序都不知道该从哪里开始跑。

实现原子性的常见手段：

• 事务性写入：先写到一个临时缓冲区，全部写完后一次性提交
• 标志位保护：先写数据，最后再写「完成标志」。如果中断发生，标志位没写，下次启动就知道升级没完成
• 双区备份：保持两个固件区，一个运行区一个备份区。升级只写备份区，完成后才切换

// 原子性写入示例：先写数据，最后写标志位
void atomic_write_flash(uint32_t addr, uint8_t *data, uint32_t len) {
    // 1. 擦除目标扇区
    flash_erase(addr, len);
    
    // 2. 写入数据（此时中断发生，数据不完整）
    flash_write(addr, data, len);
    
    // 3. 内存屏障，确保写入完成
    __DSB();
    
    // 4. 最后写完成标志 —— 原子性的关键
    flash_write_word(addr + len, VALID_FLAG);
    
    // 如果第4步之前中断，标志位不存在，下次启动可检测到
}

3.2 可恢复性：中断后能回到安全状态

原子性保证了「写操作不半残」，但升级过程中可能中断的点太多了——下载到一半断了、校验到一半断了、擦除到一半断了。这时候就需要可恢复性。

说白了，可恢复性就是：不管你在哪个阶段中断，设备都能回到一个已知的、可工作的状态。

我建议在设计中引入「状态机」机制。每个升级阶段都记录当前状态，中断重启后根据状态决定下一步：

状态	含义	恢复动作
STATE_IDLE	空闲状态，无升级任务	正常启动
STATE_DOWNLOADING	正在下载升级包	清除临时文件，回到空闲
STATE_VERIFYING	正在校验升级包	重新校验，失败则清除
STATE_FLASHING	正在写入固件	检查备份区，回滚到旧版本
STATE_COMMITTING	正在提交切换	检查标志位，决定是否重试

3.3 完整性：数据不能被破坏

完整性原则关注的是：你拿到的升级包是完整的、没有被篡改的、写入后也没有被破坏的。

我记得有一次，客户反馈设备升级后功能异常。排查了半天，发现是升级包在传输过程中被截断了——网络层分包重组出了问题，最后几K数据丢了。但设备校验时只检查了头部，没检查尾部，结果就「带病上岗」了。

从那以后，我对完整性校验的要求变得非常严格：

• 多重校验：CRC32 + SHA256 双重校验，一个都不能少
• 分块校验：大文件分块传输，每块单独校验，避免单点失败
• 写入后回读：写完后读出来再算一遍校验值，确保Flash写入无误
• 签名验证：使用非对称签名（如ECDSA）验证升级包的来源合法性

// 完整性校验流程示例
bool verify_firmware_integrity(firmware_t *fw) {
    // 1. 计算整个固件的SHA256哈希
    uint8_t hash[32];
    sha256_calc(fw->data, fw->size, hash);
    
    // 2. 与升级包中携带的哈希值对比
    if (memcmp(hash, fw->expected_hash, 32) != 0) {
        return false;  // 数据被篡改或损坏
    }
    
    // 3. 验证数字签名（使用公钥）
    if (!ecdsa_verify(fw->signature, hash, fw->public_key)) {
        return false;  // 签名无效，来源不可信
    }
    
    // 4. 写入Flash后回读验证
    uint8_t readback[32];
    flash_read(fw->flash_addr, fw->size, readback);
    sha256_calc(readback, fw->size, hash);
    
    return (memcmp(hash, fw->expected_hash, 32) == 0);
}

3.4 安全性：防篡改与防降级

安全性原则，说白了就是：你不能让不怀好意的人通过升级接口搞破坏。

安全性包含几个层面：

1. 来源认证：只有经过签名的升级包才能被接受。公钥要烧死在芯片里，不能从外部加载
2. 防回滚：防止攻击者把固件降级到有漏洞的旧版本。我建议在Bootloader里维护一个「最低版本号」
3. 加密传输：升级包在传输过程中要加密，防止被中间人窃取或篡改
4. 安全存储：密钥、证书等敏感信息要放在安全区域（如HSM或TrustZone）

防回滚的实现方式：

// 防回滚检查示例
bool check_version_rollback(uint32_t new_version, uint32_t min_allowed) {
    // 读取当前固件版本
    uint32_t current_version = read_current_version();
    
    // 检查新版本是否低于最低允许版本
    if (new_version < min_allowed) {
        log_error("Rollback attempt detected: %d < %d", new_version, min_allowed);
        return false;
    }
    
    // 检查新版本是否低于当前版本（可选，取决于业务需求）
    if (new_version < current_version) {
        log_warn("Downgrade from %d to %d", current_version, new_version);
        // 这里可以允许降级到特定版本，但必须高于min_allowed
    }
    
    return true;
}

3.5 四个原则的协同工作

这四个原则不是孤立的，它们需要协同工作。我习惯用一个简单的例子来说明它们的关系：

• 原子性保证写操作不半残 → 这是基础
• 可恢复性保证中断后能回到安全状态 → 这是兜底
• 完整性保证数据没有被破坏 → 这是质量
• 安全性保证整个过程不被攻击 → 这是底线

你想想看，如果只做了原子性和可恢复性，但没做完整性——那恢复回来的可能是一份被篡改过的固件。如果只做了完整性但没做安全性——那攻击者可以伪造一份「完整」的恶意固件。这四个原则，缺一不可。