vbmeta.img镜像生成

vbmeta镜像的作用：
验证启动（Verified Boot）是Android一个重要的安全功能，主要是为了访问启动镜像被篡改，提高系统的抗攻击能力，简单描述做法就是在启动过程中增加一条校验链，即 ROM code 校验 BootLoader，确保 BootLoader 的合法性和完整性，BootLoader 则需要校验 boot image，确保 Kernel 启动所需 image 的合法性和完整性，而 Kernel 则负责校验 System 分区和 vendor 分区。

由于 ROM code 和 BootLoader 通常都是由设备厂商 OEM 提供，而各家实际做法和研发能力不尽相同，为了让设备厂商更方便的引入 Verified boot 功能，Google 在 Android O上推出了一个统一的验证启动框架 Android verified boot 2.0，好处是既保证了基于该框架开发的verified boot 功能能够满足 CDD 要求，也保留了各家 OEM 定制启动校验流程的弹性。

由于 ROM code 校验 BootLoader 的功能通常与 IC的设计相关，所以 AVB 2.0 关注的重点在 BootLoader 之后的校验流程。BootLoader 之后系统启动所涉及的关键镜像通常包括 boot.img，system.img，Android O 的 treble Project 还引入了 dtbo 和 vendor.img。这些 image 挨个校验可以说费时费力，而 AVB 2.0 的做法事实上十分简单，引入一个新的分区：vbmeta.img（verified boot metadata），然后把所有需要校验的内容在编译时就计算好打包到这个分区，那么启动过程中 BootLoader 只需要校验 vbmeta.img，就能确认 vbmeta 内的数据是否可信。再用 vbmeta 中的数据去比对 bootimg，dtbo，system,img，vendor.img 即可。至于 OEM 是还需要放什么其他东西到 vbmeta 中，则可以由 OEM 自由定制，可以说保留了很好的客制化空间。

除了最基本的验证启动之外，AVB 2.0 还提供防止回滚的功能和对AB分区备份的支持，具体的可以看README文档（安卓源码external/avb/README.md）。

生成过程：
vbmeta.img 这个镜像不是编译生成的，它是依赖avbtool 工具生成，这个其实是一个python脚本，详细原理可以参阅external/avb/avbtool 源码，这里我们只整理Android源码下的生成流程，用最原始的方法追踪生成流程（事实证明是最直接、最有效的 ），安卓代码编译之后，在编译log只能看到一句log：

全局搜索vbmeta.img关键字，幸运的是我们在./out/build-xxx.ninja文件里找到了它的完整生成命令：
(./out/build-xxx.ninja 这个文件是安卓快速编译生成的工程文件，这里不做介绍–想介绍也不会^_^，想了解的同学自行学习)
xxx是具体的工程名。

实际上看过external/avb/README.md之后我们就知道它是怎么生成的了，但是具体的参数还需要从实际的源码编译中落实，如下是一条完整的命令：
out/host/linux-x86/bin/avbtool make_vbmeta_image --chain_partition recovery:1:out/target/product/xxx/obj/avb_chain_keys/recovery.avbpubkey --include_descriptors_from_image out/target/product/xxx/recovery.img --chain_partition boot:2:out/target/product/xxx/obj/avb_chain_keys/boot.avbpubkey --include_descriptors_from_image out/target/product/xxx/dtbo.img --chain_partition vbmeta_system:3:out/target/product/xxx/obj/avb_chain_keys/vbmeta_system.avbpubkey --include_descriptors_from_image out/target/product/xxx/vbmeta_system.img --chain_partition vbmeta_vendor:4:out/target/product/xxx/obj/avb_chain_keys/vbmeta_vendor.avbpubkey --include_descriptors_from_image out/target/product/xxx/vbmeta_vendor.img --algorithm SHA256_RSA2048 --key device/mediatek/system/common/oem_prvk.pem --padding_size 4096 --rollback_index 1 --output out/target/product/xxx/vbmeta.img

然后我们用它生成的关键字make_vbmeta_image 再次全局搜索，所幸的是我们有在build/make/core/Makefile文件中找到如下信息：

然后阅读Makefile文件

define build-vbmetaimage-target
$(call pretty,“Target vbmeta image: $(INSTALLED_VBMETAIMAGE_TARGET)”)
$(hide) mkdir -p $(AVB_CHAIN_KEY_DIR)
$(call extract-avb-chain-public-keys, $(AVB_CHAIN_KEY_DIR))
$(hide) $(AVBTOOL) make_vbmeta_image
$(INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS)
$(PRIVATE_AVB_VBMETA_SIGNING_ARGS)
$(BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS)
–output $@
$(hide) rm -rf $(AVB_CHAIN_KEY_DIR)
endef
然而所有的参数都来自$(INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS)变量，我们再来整理先$(INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS)变量的赋值过程，这个比较重要，如果需要添加其他镜像的校验信息进去，也必须在这个变量里面添加：
当前文件继续搜索INTERNAL_AVB_MAKE_VBMETA_IMAGE_ARGS

发现它实在_check-and-set-avb-chain-args函数中被赋值的。

Tips：Makefile文件的函数定义 ：

define  函数名
…
do something
…
endif
##调用的话，直接在需要的地方协商函数名就可以了 

然后我们继续搜索_check-and-set-avb-chain-args：

在check-and-set-avb-args函数被调用，继续搜索check-and-set-avb-args：

根据宏定义，每一个镜像都会去调用一下，将所需的镜像信息添加到vbmeta镜像，最终的组成参数见如上完整命令，最后生成vbmeta.img.

检查添加到镜像的检验信息：
external/avb/avbtool info_image --image vbmeta.img

可以看到其他镜像的校验信息。
这里只是生成校验信息的镜像，后续有机会在梳理下内核的校验过程。—待续。