AB分区如何实现无缝系统更新？

Question

在基于AB分区的系统中，如何确保OTA更新过程中新系统分区的完整性与可启动性？常见问题包括：更新下载后写入备用分区时遭遇断电或中断，导致镜像损坏；校验机制未正确触发，使设备下次启动时加载了不完整或不兼容的系统镜像，从而引发启动循环。此外，若未合理配置dm-verity或AVB（Android Verified Boot）验证链，可能无法及时识别篡改或损坏的分区，影响无缝切换的可靠性。如何在更新完成后、重启前充分验证备用分区的完整性和签名合法性，是保障AB无缝更新成功的关键技术难点。

Answer 1

基于AB分区系统的OTA更新完整性与可启动性保障机制

1. 背景与架构概述

在现代嵌入式系统（尤其是Android设备）中，A/B分区（也称无缝更新）已成为主流的OTA升级架构。该设计通过维护两个完整的系统分区（A和B），实现系统更新时无需进入恢复模式即可完成切换。

其核心优势在于：

• 支持“在线”升级，用户无感知中断
• 失败后可自动回滚至旧版本
• 提升系统可用性和用户体验

然而，这种架构也引入了新的挑战：如何确保写入备用分区的数据完整、未被篡改，并且具备合法签名以通过启动验证链？

2. 常见问题分析

问题类型	触发场景	潜在后果
写入过程中断电	OTA镜像写入B分区时设备断电	B分区数据不完整或损坏
校验机制缺失	未启用AVB或dm-verity	加载非法或篡改系统镜像
签名验证绕过	boot.img未正确签署或公钥未预置	恶意固件注入风险
元数据未同步	super分区扩容后未更新逻辑映射	启动失败或挂载异常
rollback protection配置错误	AVB版本号倒退	合法更新被拒绝
存储介质磨损	eMMC/UFS区块老化	静默写入错误导致CRC失败
电源管理策略不当	系统休眠中断写操作	部分块未刷盘
OTA包完整性受损	下载过程网络丢包	解压后镜像内容错误
SELinux策略冲突	新系统SEPolicy与旧vendor不兼容	init进程卡死
动态分区管理异常	LPT(Linear Partition Table)解析失败	system/vendor无法挂载

3. 核心技术栈与验证流程

为应对上述问题，需构建多层防护体系，涵盖从OTA包生成到重启前验证的全流程控制。关键组件包括：

1. OTA包签名（使用私钥签署）
2. 增量/全量差分算法（bsdiff, brillo_update_payload）
3. payload parser解析器（解析操作指令）
4. 写入时原子性保证（block-level checksum）
5. AVB（Android Verified Boot）链式验证
6. dm-verity设备映射器（只读完整性保护）
7. vbmeta结构体（包含所有分区的哈希树根与签名）
8. recoveryless update服务（如update_engine）
9. 启动控制HAL（BootControl HAL v1.2+）
10. firmware rollback index管理

4. 完整性校验的关键阶段

真正的安全性不仅依赖于启动时验证，更应在更新完成后、重启前主动进行预检。以下是典型验证流程：

// 示例：在update_engine中调用VerifyUpdate()
bool PayloadVerifier::VerifyUpdate(const string& payload_path,
                                   const vector<PartitionInfo>& partitions) {
    for (const auto& part : partitions) {
        // 1. 打开目标分区（如 /dev/block/by-name/system_b）
        int fd = open(part.device.c_str(), O_RDONLY);
        
        // 2. 计算实际哈希值
        SecureHash hasher = SecureHash::Create(SecureHash::SHA256);
        CopyAndHash(fd, &hasher);

        // 3. 对比AVB元数据中的expected_hash
        if (hasher.GetResult() != part.expected_hash) {
            LOG(ERROR) << "Integrity check failed for " << part.name;
            return false;
        }

        // 4. 验证vbmeta签名（RSA-PSS + PKCS#1 v1.5）
        if (!AvbSlotVerifyIsSuccess(slot_data)) {
            LOG(ERROR) << "VBMeta signature verification failed";
            return false;
        }
    }
    return true;
}
    

5. Mermaid流程图：OTA更新验证全过程

graph TD
            A[开始OTA更新] --> B{下载完整Payload}
            B --> C[解析操作指令: REPLACE_B, MOVE, BSDIFF等]
            C --> D[写入备用分区（B）]
            D --> E{是否断电或中断?}
            E -- 是 --> F[标记B分区为unbootable]
            E -- 否 --> G[执行完整性校验]
            G --> H[验证vbmeta签名链]
            H --> I[检查dm-verity hash tree根一致性]
            I --> J[调用BootControl HAL设置active slot为B]
            J --> K[设置slot_retry_count=2, priority++]
            K --> L[重启并尝试启动B分区]
            L --> M{启动成功?}
            M -- 是 --> N[标记B为successful]
            M -- 否 --> O[自动回滚至A分区]

6. 实践建议与高级优化

针对企业级部署和高可靠性需求，推荐以下增强措施：

• 双副本vbmeta：分别存于boot和misc分区，防止单点损坏
• 前向纠错码（FEC）：用于payload传输层，容忍一定比特错误
• 写入缓冲区强制刷盘：调用fsync/fdatasync确保落盘
• 低电量禁止更新：结合BatteryService判断是否允许开始OTA
• 安全环境验证（TEE）：在可信执行环境中完成签名验证
• 灰度发布+AB测试：先推送小批量用户验证稳定性
• 日志上报机制：收集update_engine日志用于故障诊断
• 动态分区快照：利用dm-snapshot保存原始状态以便回退
• OTA压缩+流式解码：减少内存占用，支持大包直接写入
• OTA前后性能基线对比：监控I/O延迟、启动时间变化