android AVB2.0介绍，本篇主要介绍AVB2.0的概述和工作原理、配置和编译。 有关AVB2.0的其他子系统的介绍，请查看android AVB2.0学习总结
一、AVB2.0概述
什么是AVB？
先看一段google官方的定义： “Verified boot is the process of assuring the end user of the integrity of the software running on a device. It typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn’t have any known security flaws. AVB is one implementation of verified boot.”
支持原创，转载请标明来源 https://blog.csdn.net/jackone12347/article/details/119043280
AVB是确保终端用户运行的设备安全的一整套流程。 通常从设备固件的只读部分启动，使用加密的方式验证代码是真实的，且没有任何已知的安全缺陷后才执行它。AVB是验证启动的一种实现。
AVB是android的一个非常重要的安全功能，主要是防止启动镜像被篡改，提高系统整体的抗攻击的能力，在启动的过程实现一整套的校验链，确保各个启动阶段是安全启动的。
我们先通过几个疑问，来了解一下AVB2.0
AVB在系统启动的哪些阶段工作？
AVB一般在bootloader阶段和INIT的第一阶段工作。
AVB在这两个阶段做了哪些事情？
AVB主要在Bootloader中校验vbmeta/vbmeta_system/boot/vendor_boot等分区，在init的第一阶段校验vbmeta/system/vendor等分区。
AVB工作原理大概是怎样的？
在bootloader或者UEFI中对vbmeta分区做校验，通过vbmeta中的descriptor描述符信息，去校验boot/vendor_boot等分区，同时获取系统中的device_status(locked or unlocked 即上锁或者未上锁)、boot_status(启动状态)、vbmeta中的加密的digest/加密算法/vbmeta大小等信息，append到kernel cmdline中； 然后启动kernel,kernel加载ramdisk运行init进程，进入init第一阶段，进行system/vendor分区的安全校验，会利用kernel cmdline中的值，跳过boot分区的校验；同时，因为system/vendor分区比较大，对大分区会执行hashtree的数据处理，将root digest等信息通过ioctl存到kernel中，后面访问数据时文件系统会执行dm-verity校验，执行运行时动态安全校验。
AVB对分区的处理是怎样的？ 知道了其工作原理后，那google是如何设计框架的，对系统分区做了哪些设计呢？ 首先，google想到了这样的设计：通过增加一个独立的分区，这个分区包括了其他分区的重要校验信息；只要保证这个vbmeta的足够安全，那么vbmeta中包含的其他分区的信息也就足够安全。 其次，这些安全的信息总不能用明文吧，所以得加密。用什么加密方式比较合适呢？google采用了RSA非对称加密，对镜像数据做RSA签名，将来在启动加载镜像分区时做公钥验证签名。一级级的保证各个分区的安全性。
好了，有了这些基本内容后，我们接下就介绍vbmeta的设计细节，以及它的设计用意。
一、vbmeta镜像内容说明： 在整个AVB验证的过程中，需要借助于vbmeta分区，需要增加vbmeta分区和vbmeta.img镜像。 vbmeta.img镜像，编译出来的大小为4KB 可使用avbtool提供的工具查看编译出来的vbmeta.img镜像内容： 命令：./android/external/avb/avbtool info_image --image android/out/target/product/xxx/vbmeta.img
The vbmeta image consists of three blocks:
| Header data - fixed size 256 bytes rollback index | algorithm_type | signature offset | public_key offset
| Authentication data - variable size hash of vbmeta.img | signature of vbmeta.img
| Auxiliary data - variable size public key | public key metadata | descriptors of other include image
vbmeta分区描述内容及vbmeta_system.img内容 ： Vbmeta的Descriptor的分类：
Chain Descriptor: 链式，vbmeta等分区数据少的分区。 Hash Descriptor:hash哈希，boot等小分区。 Hashtree Descriptor: dm-verity校验的大分区，像vendor
在A/B版本中的vbmeta分区描述： vbmeta镜像的加解密过程简述 ● 加密过程 根据摘要信息生成private key(私钥），利用私钥extra生成public key(公钥)，同时利用私钥对vbmeta镜像进行签名(signature)，并将公钥和计算的hash写到vbmeta镜像的header中。 ● 解密过程 先验证公钥是否平台签发的（公钥比对，防止vbmeta镜像的公钥和签名都被篡改掉），然后利用公钥进行解密签名。
AVB中镜像的加密和解密过程，以boot.img镜像为例
编译制作boot.img时进行签名时，先通过SHA-256算法得到一个散列值digest（十六进制长度为64），然后用带RSA算法的私钥加密这个digest，并生成签名后和公钥一起加在镜像的footer尾部上，编译时也会将这个digest存一份到vbmeta.img镜像中。
在bootloader中加载boot镜像时，先从vbmeta.img镜像分区中读出boot descriptor的digest，然后利用boot镜像中的公钥进行解密计算得到一个digest，和自己SHA-256计算得到的digest进行比较； digest相等则说明boot.img是平台编译签名的，如果不相等，则boot.img可能是被篡改过的，boot启动失败。 最后再计算一次boot镜像内容的hash是否相等，hash不相等，启动也是失败。
私钥签名 公钥验签的python脚本举例说明，这个看起来就更明白些了吧？
私钥签名 def rsa_private_sign(data): private_key = get_key('rsa_private_key.pem') signer = PKCS1_signature.new(private_key) digest = SHA.new() digest.update(data.encode("utf8")) sign = signer.sign(digest) signature = base64.b64encode(sign) signature = signature.decode('utf-8') return signature ? ?公钥验证签名 def rsa_public_check_sign(text, sign): publick_key = get_key('rsa_public_key.pem') verifier = PKCS1_signature.new(publick_key) digest = SHA.new() digest.update(text.encode("utf8")) return verifier.verify(digest, base64.b64decode(sign)) ? ?调用 def test_sign(): msg = ‘test content' sign = rsa_private_sign(msg) print(rsa_public_check_sign(msg, sign)) # True周末抽时间上来码字，平时太忙。。。
二、AVB2.0的配置和编译 AVB2.0的配置，其实看完android/external/avb/README.md中的内容，估计就了解的差不多了，耐着点心看完。 我简单点归纳一下，主要分下面三个部分来介绍。 1、AVB的配置总开关
# Enable AVB 2.0 BOARD_AVB_ENABLE := true这个开关会决定android编译时是否使能AVB2.0的功能，主要会影响andrioid/build/core/Makefile文件，会影响镜像的编译及签名处理。
2、AVB key配置介绍
BOARD_AVB_ALGORITHM := SHA256_RSA4096 BOARD_AVB_KEY_PATHAVB使用的key的路径和加密算法类型。这个key可自己使用openssl命令生成即可， 唯一需要注意的是使用-f4 4096参数，算法类型保持不变。为什么要用4096而不用2048？这个长度越长，越难被破解，vbmeta的public key验证时尽量用4096这个长度。
3、AVB编译镜像 镜像的编译主要有vbmeta.img、boot.img、system/vendor.img、recovery.img等。 我们一个个来看。
vbmeta.img镜像的编译 vbmeta.img需要配置物理分区大小为64KB，这个是google推荐的，实际上数据只有4KB左右。
因为vbmeta.img里面要保存boot/dtbo/system/vendor等分区的校验信息，所以编译时会依赖于这些镜像的编译。BOARD_AVB_KEY_PATH可自定义，如果没有定义则使用avb默认的test测试密钥。
下面是build/core/Makefile中编译vbmeta.img部分的脚本，其中BOARD_AVB_ALGORITHM和BOARD_AVB_KEY_PATH就是前面章节提到的需要自定义的算法和KEY路径了。
ifdef BUILDING_VBMETA_IMAGE INSTALLED_VBMETAIMAGE_TARGET := $(BUILT_VBMETAIMAGE_TARGET) $(INSTALLED_VBMETAIMAGE_TARGET): PRIVATE_AVB_VBMETA_SIGNING_ARGS := \ --algorithm $(BOARD_AVB_ALGORITHM) --key $(**BOARD_AVB_KEY_PATH**) #key是私钥 $(INSTALLED_VBMETAIMAGE_TARGET): \ $(AVBTOOL) \ $(INSTALLED_BOOTIMAGE_TARGET) \ $(INSTALLED_VENDOR_BOOTIMAGE_TARGET) \ $(INSTALLED_SYSTEMIMAGE_TARGET) \ $(INSTALLED_VENDORIMAGE_TARGET) \ $(INSTALLED_PRODUCTIMAGE_TARGET) \ $(INSTALLED_SYSTEM_EXTIMAGE_TARGET) \ $(INSTALLED_ODMIMAGE_TARGET) \ $(INSTALLED_DTBOIMAGE_TARGET) \ $(INSTALLED_CUSTOMIMAGES_TARGET) \ $(INSTALLED_RECOVERYIMAGE_TARGET) \ $(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET) \ $(INSTALLED_VBMETA_VENDORIMAGE_TARGET) \ $(BOARD_AVB_VBMETA_SYSTEM_KEY_PATH) \ $(BOARD_AVB_VBMETA_VENDOR_KEY_PATH) \ $(BOARD_AVB_KEY_PATH) $(build-vbmetaimage-target)这个会调用external/avb/avbtool.py脚本的make_vbmeta_image函数，去完成对vbmeta.img镜像的处理，后面会专门拿一个章节来介绍这些脚本函数。
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) \ ##添加chain链式分区信息和avbpubkey公钥信息 $(PRIVATE_AVB_VBMETA_SIGNING_ARGS) \ ##添加—algorithm和BOARD_AVB_KEY_PATH，在板卡mk中配置过的 $(BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS) \ ##设置padding_size/set_hashtree_disabled_flag/rollback_index等参数 --output $@编译出来的vbmeta.img镜像，可用info_image命令进行查看。 命令：
#./android/external/avb/avbtool info_image --image your_out_put_dir/vbmeta.imgboot镜像的编译 在boot.img镜像编译的时候，会调用add_hash_footer函数，也是调用的avbtool.py脚本的函数，是为了在boot.img镜像的尾部添加校验信息，为后面bootloader校验boot.img安全性做的功能，通过这个尾部的信息来判断当前启动的boot.img是否足够安全。
@build/core/Makefile $(INSTALLED_BOOTIMAGE_TARGET): $(MKBOOTIMG) $(AVBTOOL) $(INTERNAL_BOOTIMAGE_FILES) $(BOARD_AVB_BOOT_KEY_PATH) $(call pretty,"Target boot image: $@") $(hide) $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_ARGS) $(INTERNAL_MKBOOTIMG_VERSION_ARGS) $(BOARD_MKBOOTIMG_ARGS) --output $@ $(hide) $(call assert-max-image-size,$@,$(call get-hash-image-max-size,$(BOARD_BOOTIMAGE_PARTITION_SIZE))) $(hide) $(AVBTOOL) **add_hash_footer** \ ####主要是这个函数 --image $@ \ --partition_size $(BOARD_BOOTIMAGE_PARTITION_SIZE) \ --partition_name boot $(INTERNAL_AVB_BOOT_SIGNING_ARGS) \ $(BOARD_AVB_BOOT_ADD_HASH_FOOTER_ARGS)编译完成后，可以使用xxd命令查看镜像中的内容，看一下就大致明白是怎么回事了。
# xxd boot.img | head # xxd boot.img | tailsysmte/vendor镜像的编译
system/vendor镜像处理是类型的，因为这两个镜像一般都比较大，不能采用和boot.img镜像的add_hash_footer，如果在开机的时候对system/vendor整个内容进行hash计算，会比较耗时，所以google设计采用了hashtree的方式，计算整体分区最后只保证root digest hash和salt，只校验这两个值速度就比较快了。
下面是脚本内容
@build/core/Makefile ifeq ($(BOARD_AVB_ENABLE),true) $(BUILT_SYSTEMIMAGE): $(BOARD_AVB_SYSTEM_KEY_PATH) endif $(BUILT_SYSTEMIMAGE): $(FULL_SYSTEMIMAGE_DEPS) $(INSTALLED_FILES_FILE) $(call build-systemimage-target,$@) $(INSTALLED_SYSTEMIMAGE_TARGET): $(BUILT_SYSTEMIMAGE) @echo "Install system fs image: $@" $(copy-file-to-target) $(hide) $(call assert-max-image-size,$@,$(BOARD_SYSTEMIMAGE_PARTITION_SIZE)) ifeq ($(BOARD_AVB_ENABLE),true) PATH=$(INTERNAL_USERIMAGES_BINARY_PATHS):$$$$PATH \ $(AVBTOOL) add_hashtree_footer \ ###主要是这个函数了 --image $(3) \ --key $(BOARD_AVB_$(call to-upper,$(2))_KEY_PATH) \ --algorithm $(BOARD_AVB_$(call to-upper,$(2))_ALGORITHM) \ --partition_size $(BOARD_AVB_$(call to-upper,$(2))_PARTITION_SIZE) \ --partition_name $(2) \ $(INTERNAL_AVB_CUSTOMIMAGES_SIGNING_ARGS) \ $(BOARD_AVB_$(call to-upper,$(2))_ADD_HASHTREE_FOOTER_ARGS) endif至于avbtool脚本如何处理hashtree数据，本篇就不介绍了，请自行看看这个函数。
好了朋友们，关于AVB2.0的工作原理和编译配置本篇就介绍到这里了。
===================================================== 补充： 上面编译制作镜像时，没有讲清楚vbmeta和vbemta_system，以及vbmeta_system和system等分区的关系。 下面就补充一下相关知识内容：
android/build/make/core/board_config.mk BUILDING_SYSTEM_IMAGE := true BUILDING_VBMETA_IMAGE := trueboardxx.mk 配置vbmeta_system.img的签名需要的内容
BOARD_AVB_VBMETA_SYSTEM := system system_ext product BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 2build/core/Makefile 制作vbmeta_system.img
define build-chained-vbmeta-image $(call pretty,"Target chained vbmeta image: $@") $(hide) $(AVBTOOL) make_vbmeta_image \ $(INTERNAL_AVB_$(call to-upper,$(1))_SIGNING_ARGS) \ $(BOARD_AVB_MAKE_$(call to-upper,$(1))_IMAGE_ARGS) \ $(foreach image,$(BOARD_AVB_$(call to-upper,$(1))), \ --include_descriptors_from_image $(call images-for-partitions,$(image))) \ ##遍历遍历BOARD_AVB_VBMETA_SYSTEM所有的分区描述符，并保存在vbmeta_system中 --output $@ endef ifdef BUILDING_SYSTEM_IMAGE ifdef BOARD_AVB_VBMETA_SYSTEM INSTALLED_VBMETA_SYSTEMIMAGE_TARGET := $(PRODUCT_OUT)/vbmeta_system.img $(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET): \ $(AVBTOOL) \ $(call images-for-partitions,$(BOARD_AVB_VBMETA_SYSTEM)) \ ##遍历BOARD_AVB_VBMETA_SYSTEM所有的分区镜像，并将这些镜像的信息存在vbmeta_system中 $(BOARD_AVB_VBMETA_SYSTEM_KEY_PATH) $(call build-chained-vbmeta-image,vbmeta_system) endif endif # BUILDING_SYSTEM_IMAGE制作vbmeta.img，这里能看到有添加INSTALLED_VBMETA_SYSTEMIMAGE_TARGET这个vbmeta_system.img进来 #这样vbmeta.img就包含vbmeta_system.img内容了
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 ifdef BUILDING_VBMETA_IMAGE INSTALLED_VBMETAIMAGE_TARGET := $(BUILT_VBMETAIMAGE_TARGET) $(INSTALLED_VBMETAIMAGE_TARGET): PRIVATE_AVB_VBMETA_SIGNING_ARGS := \ ##vbmeta的key路径和算法类型 --algorithm $(BOARD_AVB_ALGORITHM) --key $(BOARD_AVB_KEY_PATH) $(INSTALLED_VBMETAIMAGE_TARGET): \ ... $(INSTALLED_VBMETA_SYSTEMIMAGE_TARGET) \现在我们来分解一下vbmeta_system.img，看下是如何将这些分区镜像的数据进行存储的。 执行./external/avb/avbtool.py info_image --image out/xxx/vbmeta_system.img
Minimum libavb version: 1.0 Header Block: 256 bytes Authentication Block: 320 bytes Auxiliary Block: 2176 bytes Public key (sha1): cdbb77177f731920bbe0a0f94f84d9038axxxxxx Algorithm: SHA256_RSA2048 Rollback Index: 1633046400 Flags: 0 Release String: 'avbtool 1.1.0' Descriptors: Prop: com.android.build.system.os_version -> '11' Hashtree descriptor: Version of dm-verity: 1 Image Size: 385806336 bytes Tree Offset: 385806336 Tree Size: 3043328 bytes Data Block Size: 4096 bytes Hash Block Size: 4096 bytes FEC num roots: 2 FEC offset: 388849664 FEC size: 3080192 bytes Hash Algorithm: sha1 Partition Name: product Salt: d29a6163c3bed5c9e9b4f141d163722369xxxxxx Root Digest: c05e7f1987d2ec59ca3d39e7a5f9d8e070xxxxxxvim vbmeta_system.img，然后输入%!xxd，就可以看到如下内容了：
00000000: 4156 4230 0000 0001 0000 0000 0000 0000 AVB0............ 00000010: 0000 0140 0000 0000 0000 0880 0000 0001 ...@............ 00000020: 0000 0000 0000 0000 0000 0000 0000 0020 ............... 00000030: 0000 0000 0000 0020 0000 0000 0000 0100 ....... ........ 00000040: 0000 0000 0000 0670 0000 0000 0000 0208 .......p........ 00000050: 0000 0000 0000 0878 0000 0000 0000 0000 .......x........ 00000060: 0000 0000 0000 0000 0000 0000 0000 0670 ...............p 00000070: 0000 0000 6156 4f80 0000 0000 0000 0000 ....aVO......... 00000080: 6176 6274 6f6f 6c20 312e 312e 3000 0000 avbtool 1.1.0... 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 我把这里分割一下，前面256字节内容长度是固定的，用来存储vbmeta_system.img本身的内容 00000100: f471 409a 8786 ca2f 2d22 0f33 732c e431 .q@..../-".3s,.1 00000110: a164 95fb a21b e7dd 646e 8879 5a70 6943 .d......dn.yZpiC 00000120: af4a a9ca 55c2 7050 7201 10ca 8561 eb68 .J..U.pPr....a.h 00000130: 83b9 839b 0a80 42ac ee56 5855 720b f9be ......B..VXUr... 00000140: b37b c224 2292 9f99 a903 9c19 a423 38d0 .{.$"........#8. 00000150: d495 9f22 b7fa b7ee af00 3b46 5680 3130 ..."......;FV.10 00000160: 1d1e 84d3 241b 6366 0121 c7db 60e6 ad0b ....$.cf.!..`... 00000170: 9fa7 adbd 920e 1def 4a9b 5102 e359 2072 ........J.Q..Y r 00000180: dbac f867 42b9 5dd2 a7c5 5398 e6b9 5e3d ...gB.]...S...^= 00000190: 770f ede6 0df0 cb89 31e0 f1ac ad3c 6540 w.......1....<e@ 000001a0: f435 215d f298 d1d4 bbb4 91e9 6bc3 9174 .5!]........k..t 000001b0: 2377 dc5a 27e9 cc97 e5fb eb6f e6e6 9a13 #w.Z'......o.... 000001c0: 3428 c340 6f0a 3a71 788c 76fe 2b4d 9da4 4(.@o.:qx.v.+M.. 000001d0: ee5e 4ac4 7936 478a d9ef 10c6 2ffd 813c .^J.y6G...../..< 000001e0: 90d8 68af 31be 9ca9 0b8e b840 8fb3 877d ..h.1......@...} 000001f0: fcb1 cf2a d092 3c64 af9f 0d14 876a cdbc ...*..<d.....j.. 00000200: db84 c462 b32f cbc1 af4e 2be8 0c1b aa78 ...b./...N+....x 00000210: a359 263e f7a8 e3fe 1efb dcd7 7663 0206 .Y&>........vc.. 00000220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000240: 0000 0000 0000 0000 0000 0000 0000 0088 ................ 说明：到这里是576字节 =256 +320 ，这里存的是Authentication签名和hash数据了，加密混淆了。 Header Block: 256 bytes Authentication Block: 320 bytes ... 00000a30: 5c3b 9436 c18f fec9 d25a 6aa0 46e1 a28b \;.6.....Zj.F... 00000a40: 2f51 6151 a336 9183 b4fb cda9 4034 4698 /QaQ.6......@4F. 00000a50: 8a1a 91df d92c 3abf 573a 4646 20f2 f0bc .....,:.W:FF ... 00000a60: 315e 29fe 5890 325c 6697 999a 8e15 23eb 1^).X.2\f.....#. 00000a70: a947 d363 c618 bb8e d220 9f78 af71 b32e .G.c..... .x.q.. 00000a80: 0889 a1f1 7db1 30a0 e61b bd6e c8f6 33e1 ....}.0....n..3. 00000a90: dab0 bd16 41fe 076f 6e97 8b6a 33d2 d780 ....A..on..j3... 00000aa0: 036a 4de7 0582 281f ef6a a975 7ee1 4ee2 .jM...(..j.u~.N. 00000ab0: 955b 4fe6 dc03 b981 0000 0000 0000 0000 .[O............. 这些数据就是辅助数据了，存的是vbmeta_system包含的system等分区的descriptor信息了 Auxiliary Block: 2176 bytes分析完了vbmeta_system.img，再回过头来看vbmeta.img，可以看到vbmeta镜像中包含了vbmeta_system镜像的信息。 $ ./external/avb/avbtool.py info_image --image out/xxx/vbmeta.img
Minimum libavb version: 1.0 Header Block: 256 bytes Authentication Block: 576 bytes Auxiliary Block: 3136 bytes Public key (sha1): 6fc544ec428a010fa304a398f3a8fe62c1xxxxxx Algorithm: SHA256_RSA4096 Rollback Index: 0 Flags: 0 Release String: 'avbtool 1.1.0' Descriptors: Chain Partition descriptor: Partition Name: vbmeta_system Rollback Index Location: 2 Public key (sha1): cdbb77177f731920bbe0a0f94f84d9038axxxxxx ###公钥的sha1值和前面vbmeta_system Public key (sha1)值是相同的 Prop: com.android.build.boot.fingerprint -> xxx:userdebug/test-keys' Prop: com.android.build.boot.os_version -> '11' Hash descriptor: Image Size: 26800128 bytes Hash Algorithm: sha256 Partition Name: boot Salt: a55c2fa693f09b24bf261f2cae3c0290d37aad3a63a78f7ed673a2d656xxxxxx Digest: f352ae2862e12e85c921394448fc47585a01ec29a77c6d8dea8c6f9e33xxxxxx Flags: 0 ...一般android设备在uboot阶段加载校验vbmeta本身和校验boot/vendor_boot/dtbo等分区， 在android init阶段启动的时候，不再需要校验vbmeta本身了，但是会加载vbmeta整个分区(此接口libavb静态库中有实现)，这样能读到vbmeta_system的信息。
所以，init启动AVB校验的第一个分区是system分区。 代码处理在first_stage_mount.cpp中的SetUpDmVerity函数
bool FirstStageMount::MountPartition(const Fstab::iterator& begin, bool erase_same_mounts, Fstab::iterator* end) { ... //AVB校验 if (!SetUpDmVerity(&(*begin))) { PLOG(ERROR) << "Failed to setup verity for '" << begin->mount_point << "'"; return false; } LOG(INFO) << "MountPartition SetUpDmVerity done."; //mount挂载 bool mounted = (fs_mgr_do_mount_one(*begin) == 0); ... }SetUpDmVerity会读fstab： 会先判断fstab中是否有avb_keys=/avb/q-gsi.avbpubkey:/avb/r-gsi.avbpubkey:/avb/s-gsi.avbpubkey的flag 然后判断fstab中是否有avb=vbmeta_system的flag 如果都没有，则没有开启AVB
bool FirstStageMountVBootV2::SetUpDmVerity(FstabEntry* fstab_entry) { AvbHashtreeResult hashtree_result; // It's possible for a fstab_entry to have both avb_keys and avb flag. // In this case, try avb_keys first, then fallback to avb flag. if (!fstab_entry->avb_keys.empty()) { if (!InitAvbHandle()) return false; // Checks if hashtree should be disabled from the top-level /vbmeta. if (avb_handle_->status() == AvbHandleStatus::kHashtreeDisabled || avb_handle_->status() == AvbHandleStatus::kVerificationDisabled) { LOG(ERROR) << "Top-level vbmeta is disabled, skip Hashtree setup for " << fstab_entry->mount_point; return true; // Returns true to mount the partition directly. } else { auto avb_standalone_handle = AvbHandle::LoadAndVerifyVbmeta( *fstab_entry, preload_avb_key_blobs_[fstab_entry->avb_keys]); if (!avb_standalone_handle) { LOG(ERROR) << "Failed to load offline vbmeta for " << fstab_entry->mount_point; // Fallbacks to built-in hashtree if fs_mgr_flags.avb is set. if (!fstab_entry->fs_mgr_flags.avb) return false; LOG(INFO) << "Fallback to built-in hashtree for " << fstab_entry->mount_point; hashtree_result = avb_handle_->SetUpAvbHashtree(fstab_entry, false /* wait_for_verity_dev */); } else { // Sets up hashtree via the standalone handle. if (IsStandaloneImageRollback(*avb_handle_, *avb_standalone_handle, *fstab_entry)) { return false; } hashtree_result = avb_standalone_handle->SetUpAvbHashtree( fstab_entry, false /* wait_for_verity_dev */); } } } else if (fstab_entry->fs_mgr_flags.avb) { if (!InitAvbHandle()) return false; hashtree_result = avb_handle_->SetUpAvbHashtree(fstab_entry, false /* wait_for_verity_dev */); } else { return true; // No need AVB, returns true to mount the partition directly. }那么fstab中为什么要添加avb_keys=/avb/q-gsi.avbpubkey公钥的flag呢？这种设计是要解决什么问题？ system分区的公钥和签名信息都在了vbmeta_system中了，为什么还需要在first_stage_ramdisk中保存一份avbpubkey呢？ 我们看一下编译产物： android/out/target/product/xxx/recovery/root/first_stage_ramdisk/avb/r-gsi.avbpubkey
再回过头来看一下extract-avb-chain-public-keys的定义，从定义的内容来看，应该是各partition的公钥了，形式为partition.avbpubkey
define extract-avb-chain-public-keys $(if $(BOARD_AVB_BOOT_KEY_PATH),\ $(hide) $(AVBTOOL) extract_public_key --key $(BOARD_AVB_BOOT_KEY_PATH) \ --output $(1)/boot.avbpubkey) $(if $(BOARD_AVB_VENDOR_BOOT_KEY_PATH),\ $(AVBTOOL) extract_public_key --key $(BOARD_AVB_VENDOR_BOOT_KEY_PATH) \ --output $(1)/vendor_boot.avbpubkey) $(if $(BOARD_AVB_SYSTEM_KEY_PATH),\ $(hide) $(AVBTOOL) extract_public_key --key $(BOARD_AVB_SYSTEM_KEY_PATH) \ --output $(1)/system.avbpubkey)…
而我们这里是r-gsi.avbpubkey，那r-gsi表示什么？搞过XTS的应该知道是google搞的通用系统镜像，是需要烧录对应的system.img的。 所以，在fstab中配置的avb_keys=/avb/xxx.avbpubkey，应该是为了过GSI测试用的，在VTS测试时，会往data分区push google签名对应的public key
为方便与大家及时交流，弄了一个微信公众号，欢迎大家留言沟通~
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
标签： #avb20 #Android #AVB20学习总结一
