本篇属于android AVB2.0学习总结系列的第二篇文章，本篇主要介绍一下UBOOT或者UEFI阶段AVB2.0的介绍。
因为google对UBOOT或者UEFI阶段的AVB校验是没有标准的，各厂家都可以进行定制。
虽然没有标准，但是google给出了建议的启动流程，各芯片厂家一般都会向这个靠齐。
google建议的启动流程图如下：
没怎么搞过AVB的同学，看到这张图，估计也不大清楚google想表示啥。我琢磨过一阵子，撸过相关的code，这里就给大家讲一下我的理解，一步步来分解一下。
Device Lock设备上锁
第一个遇到的是“Is Device Locked”，判断设备是否为locked上锁状态，意思是出厂的手机最好建议是上过锁的，如果没有上锁就warning告知一下用户。
那什么是上锁？ 上锁有什么用？ 是怎么上锁的？
一般OEM厂商最后产线出去的手机，可能会对设备进行上锁操作。上锁后，这台设备后续基本不大可能会被刷机了，刷机工具会去判断这条设备是否上过锁，如果是上锁的状态，对不起请先解锁。那怎么解锁类，OEM厂商的操作方式不一定一样，比如维修的时候提供fastboot功能等进行解锁，我这里只是说了一种可能性，实际上各家的方法不一定一样。
那这个上锁是怎么操作的？
一般是采用将数据写入到EMMC或者UFS中的RPMB分区（没听过这个词的可以度娘了解一下），上锁的流程又有可能是通过TEE侧去操作的，REE侧是不知道怎么上锁的（好的，TEE和REE没听的，一起度娘吧）。这样就把实现的细节全部屏蔽掉了，烧录工具烧录时判断是否上锁以及解决，也是走这个通路。
如果没有上锁，google建议界面显示橙色，提示用户当前设备没有上锁，可能不够安全，但一般不影响继续启到kernel阶段。
好了，Device Lock就介绍到这。
下面开始介绍
Valid Os found
accept verification errors and any of trust，这个是图中的括号里的，咋一看不知道这个在讲什么。其实也比较简单，就是检察vbmeta.img是否合法，检查vbmeta的header信息中是否有“AVB0”开头，是否有预置public key等，就是check这些内容，如果没有通过，设置了verify flag的话就直接启动失败。
下一个流程是
“Was the root of trust set by the user”
这个又是啥玩意，怎么跟user用户有关了？ 其实这是google提供的很好的方法，就是我这台google设备并不是最终产线出去的，但我又想用这个AVB验证功能，所以就提供了另一种方法，可以让用户自己设置key。但是如果使用的是用户设置的key，建议给个黄色的界面进行warning提醒，毕竟不是OEM厂商签名发出的版本嘛。
最后一个流程
“Update rollback”
什么是rollback，其实就是回滚。这里的意思是更新回滚，为什么要更新回滚？是因为android版本也会有漏洞，google会定期的发布安全补丁。
如果有人想使坏，使用没有打安全补丁的版本，然后想偷偷摸摸干点事情，嘿嘿，肯定是不好的对吧。
需要把这条路给它堵上。google就提供了rollball防回滚的机制。
比如我们发布的版本带有安全补丁，我们就把rollback index值加1，编译版本镜像->烧录->启动，启动的时候会去从设备的特殊分区中读取原来的rollback index值，如果发现设备中的index值小于vbmeta中的，就把vbmeta中的index更新到设备的特殊分区中。
这里的特殊分区可以是RPMB分区，也可以是其他不容易访问到的分区都是可以的。
如果这个时间，“某个坏人”通过OTA或者其他途径 刚好把有缺陷的镜像烧录成功到设备中了，启动的时候会遇到失败，因为有缺陷的版本rollback index值会小于特殊分区中的，启动失败，这样就达到了防止回滚了的目标了。
那么从代码层面上如何实现上面提到的这个点呢？就需要先移植libavb库到UBOOT或者UEFI中，然后实现avb_ops.c中的几个接口就可以了，我这里不方便贴代码，请见谅。
好了，朋友们，手动码字很累，以上就是UBOOT阶段AVB2.0的校验流程，如有错误请帮指出，一起学习交流讨论，谢谢！