洛奇看世界

上一篇《Android AVB 分析（十）AVB 有哪些相关的源码？》中分析了 AVB 源码结构，本篇正式深入 AVB 源码，看看在 bootloader 中是如何使用 libavb 进行 verify boot 检查验证的。

上一篇 《Android AVB 分析（十一）bootloader 是如何进行 verify boot 检查的？》 分析了 bootloader 中是如何调用 libavb 函数库验证 vbmeta 和 boot 等分区的。接下来就打算写一篇介绍 dm-verity 原理的文章，然后再写一篇徒手 dm-verity 实践的文章，结果偶然发现了本篇的英文原版。写得太好，我觉得自己完全没有必要再写原理了。由于原文是英文，有些英语不太好的朋友不一定能完全理解。我花了点时间，结合 AI 将英语原文翻译成中文。

在上一篇《Android AVB 分析（十二）嵌入式设备安全中的 dm-verity 简介》介绍 dm-verity 原理的时候，作者提供了一个 dm-verity 演示的例子。本篇我们基于 AOSP 源码 `android-13.0.0_r41` 实际编译生成的 Google Pixel 7 (“panther”) 设备的 system 分区镜像进行 dm-verity 设备验证实战。

关于 FEC 是如何工作的，一直是我 Android OTA 讨论群中的未解话题，大家基本上都不清楚 Android 上面的 FEC 是如何工作的，为什么在 OTA 升级的最后阶段，FEC 的编码计算会消耗大量的 IO 资源，并持续很长时间。接下来的几篇，我会从一个程序员的角度，演示基于里德所罗门编码的 FEC 到底是如何工作的。

上一篇《Android AVB 分析（十六）5个例子理解 FEC(Reed-Solomon) 的工作原理》中解释了 FEC 以及 RS(里德所罗门编码)的原理，并基于 Python 的 reedsolo 库提供了 5 个 RS 编码和解码的例子。通过对原始数据进行编码生成 FEC，以及对错误数据进行纠正还原数据。我相信如果您阅读了这篇文章，并亲自去做了这几个实验，那一定会对 RS 编码有一个比较切身的了解。也可能你还希望有一些补充，所以我个人觉得以程序员实践的角度为出发点的本篇同样可以让你有些收获。总体上，

在《Android AVB 分析（六）FEC 数据到底是如何生成的？》中，我分析 Android 如何调用 avbtool 生成 FEC 数据的过程。实际上，avbtool 自己并不直接生成 FEC，而是进一步调用 fec 工具处理带有 HashTree 的镜像得到 FEC 数据。在本篇，我们将彻底解决关于 Android 镜像中 FEC 数据是如何生成的所有疑问。 1. Android 中用于生成 FEC(Reed-Solomen) 编码的 fec 工具介绍；2. Android 中 FEC 的参数；..

我在 《Android AVB 分析（十三）dm-verity 设备是如何映射和纠错的？》中做过一个 system 分区镜像 system.img 进行 dm-verity 映射，加载和 FEC 纠错的例子。本文提供更多源于 Android 镜像数据破坏和使用 FEC 纠错的例子。

在前两篇中详细介绍了 Android 镜像中的 FEC 数据是如何生成的。以及 Android 镜像中使用 FEC 对多达 6.63M 连续破坏数据的修复。但你可能还会觉得不过瘾，为啥采用 RS(255, 253) 编码，为啥不采用具有更强纠错的其它编码？采用 FEC 纠错的代价有多大？采用 FEC 对 Android 性能的影响有多大？为此，Android 在官方的 AVB 文档中补充了一篇文章链接：《严格强制执行的启动时验证与纠错》，这篇文章详细介绍了为什么采用 FEC 纠错，以及相应的评估和需要为此特