search

chenxiaolong / avbroot

Sign (and root) Android A/B OTAs with custom keys while preserving Android Verified Boot
GNU General Public License v3.0
436 stars 41 forks source link

libfs_avb shows Error verifying vbmeta image #282

Closed ztmzzz closed 1 month ago

ztmzzz commented 1 month ago

I have successfully locked the bootloader. The following information was found during inspection. I would like to ask if the output of Error verifying vbmeta image has any potential impact. I use official rom, model is pixel 8 pro. adb shell su -c 'dmesg | grep libfs_avb' shows

[    1.603440] init: [libfs_avb] Returning avb_handle with status: Success
[    1.603526] init: [libfs_avb] Built verity table: '1 /dev/block/dm-0 /dev/block/dm-0 4096 4096 194404 194404 sha256 f4627fcb228f972790d1cf6fc3220f37a4511b6c074a909175e34048297cb23f 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-0 fec_roots 2 fec_blocks 195936 fec_start 195936 restart_on_corruption ignore_zero_blocks'
[    1.612091] init: [libfs_avb] : Error verifying vbmeta image: OK_NOT_SIGNED
[    1.612103] init: [libfs_avb] : allow verification error is not allowed
[    1.612123] init: [libfs_avb] Failed to load vbmeta: /dev/block/dm-1
[    1.612213] init: [libfs_avb] Built verity table: '1 /dev/block/dm-1 /dev/block/dm-1 4096 4096 2658 2658 sha256 8a189a5f31e70deb58800584b229169fede346bb49de1abbff2fc8d1732cd675 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-1 fec_roots 2 fec_blocks 2680 fec_start 2680 restart_on_corruption ignore_zero_blocks'
[    1.622967] init: [libfs_avb] Built verity table: '1 /dev/block/dm-2 /dev/block/dm-2 4096 4096 68149 68149 sha256 45159e80562daf90245e4c2a262cc99ee8808e80d4a6ec21005b1fd695707058 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-2 fec_roots 2 fec_blocks 68688 fec_start 68688 restart_on_corruption ignore_zero_blocks'
[    1.637919] init: [libfs_avb] Built verity table: '1 /dev/block/dm-3 /dev/block/dm-3 4096 4096 802931 802931 sha256 3d1ac6078b5499dc2f31345786908560a96e09c44ab8542a0ea67371936fe7ec 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-3 fec_roots 2 fec_blocks 809255 fec_start 809255 restart_on_corruption ignore_zero_blocks'
[    1.658975] init: [libfs_avb] Built verity table: '1 /dev/block/dm-4 /dev/block/dm-4 4096 4096 174721 174721 sha256 ed84d01fa8aad737ede32b75e28590470b324fd70228c6d614a53c7fc2ec8edb 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-4 fec_roots 2 fec_blocks 176099 fec_start 176099 restart_on_corruption ignore_zero_blocks'
[    1.685285] init: [libfs_avb] : Error verifying vbmeta image: OK_NOT_SIGNED
[    1.685302] init: [libfs_avb] : allow verification error is not allowed
[    1.685343] init: [libfs_avb] Failed to load vbmeta: /dev/block/dm-5
[    1.685557] init: [libfs_avb] Built verity table: '1 /dev/block/dm-5 /dev/block/dm-5 4096 4096 6570 6570 sha256 797ac00b25de1cad24d15ae4d690185676ee7d91fa91144d25054e9fa4a5690d 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-5 fec_roots 2 fec_blocks 6623 fec_start 6623 restart_on_corruption ignore_zero_blocks'

avbroot ota verify output:

  0.000s  INFO Verifying whole-file signature
  1.170s  INFO Verifying payload
  3.202s  INFO Extracting partition images to temporary directory
  3.202s  INFO Extracting from the payload: abl, bl1, bl2, bl31, boot, dtbo, gcf, gsa, gsa_bl1, init_boot, ldfw, modem, pbl, product, pvmfw, system, system_dlkm, system_ext, tzsw, vbmeta, vbmeta_system, vbmeta_vendor, vendor, vendor_boot, vendor_dlkm, vendor_kernel_boot
  9.104s  INFO Successfully extracted OTA
  9.104s  INFO Verifying partition hashes
 10.777s  INFO Checking ramdisk's otacerts.zip
 10.842s  INFO Verifying AVB signatures
 10.842s  INFO vbmeta has a signed vbmeta header
 10.843s  INFO boot has a signed vbmeta header
 10.843s  INFO init_boot has a signed vbmeta header
 10.844s  INFO vbmeta_system has a signed vbmeta header
 10.844s  INFO vbmeta_vendor has a signed vbmeta header
 10.844s  INFO Verifying hash descriptor for: vendor_kernel_boot
 10.844s  INFO Verifying hash descriptor for: pbl
 10.844s  INFO Verifying hash descriptor for: pvmfw
 10.844s  INFO Verifying hash descriptor for: boot
 10.844s  INFO Verifying hash tree descriptor for: system_ext
 10.844s  INFO Verifying hash tree descriptor for: vendor_dlkm
 10.844s  INFO Verifying hash tree descriptor for: system
 10.844s  INFO Verifying hash descriptor for: bl1
 10.844s  INFO Verifying hash descriptor for: bl2
 10.844s  INFO Verifying hash descriptor for: bl31
 10.844s  INFO Verifying hash descriptor for: dtbo
 10.844s  INFO Verifying hash descriptor for: init_boot
 10.844s  INFO Verifying hash descriptor for: gsa
 10.844s  INFO Verifying hash descriptor for: abl
 10.844s  INFO Verifying hash descriptor for: tzsw
 10.844s  INFO Verifying hash tree descriptor for: product
 10.844s  INFO Verifying hash descriptor for: vendor_boot
 10.844s  INFO Verifying hash descriptor for: gsa_bl1
 10.844s  INFO Verifying hash descriptor for: ldfw
 10.844s  INFO Verifying hash tree descriptor for: vendor
 10.845s  INFO Verifying hash tree descriptor for: system_dlkm
 10.845s  INFO Verifying hash descriptor for: gcf
 13.908s  INFO Signatures are all valid!
chenxiaolong commented 1 month ago

Hey, thanks for reporting this! This is a bug on Google's end, but it's not a security issue.

I downloaded husky-ota-ap1a.240505.005-6fd4a237.zip and extracted the partitions to take a look.

From your logs, the two block devices with the errors are:

[    1.612123] init: [libfs_avb] Failed to load vbmeta: /dev/block/dm-1
[    1.612213] init: [libfs_avb] Built verity table: '1 /dev/block/dm-1 /dev/block/dm-1 4096 4096 2658 2658 sha256 8a189a5f31e70deb58800584b229169fede346bb49de1abbff2fc8d1732cd675 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-1 fec_roots 2 fec_blocks 2680 fec_start 2680 restart_on_corruption ignore_zero_blocks'
...
[    1.685343] init: [libfs_avb] Failed to load vbmeta: /dev/block/dm-5
[    1.685557] init: [libfs_avb] Built verity table: '1 /dev/block/dm-5 /dev/block/dm-5 4096 4096 6570 6570 sha256 797ac00b25de1cad24d15ae4d690185676ee7d91fa91144d25054e9fa4a5690d 404ae4dbc2c76050d1e02a5b70e615c705dfe593a45b8ffdd41a14f81a1343b9 10 use_fec_from_device /dev/block/dm-5 fec_roots 2 fec_blocks 6623 fec_start 6623 restart_on_corruption ignore_zero_blocks'

The root digests (8a189a5f31e70deb58800584b229169fede346bb49de1abbff2fc8d1732cd675 and 797ac00b25de1cad24d15ae4d690185676ee7d91fa91144d25054e9fa4a5690d) can be used to determine what the actual partitions are. In this case, they are the system_dlkm and vendor_dlkm partitions.

I extracted the fstab.zuma file from the vendor_boot partition to see how Android is mounting these two partitions and found these lines:

system_dlkm                                              /system_dlkm                ext4    noatime,ro                       wait,slotselect,avb=vbmeta_system,avb_keys=no_such_key,logical,first_stage_mount,readahead_size_kb=128
...
vendor_dlkm                                              /vendor_dlkm                ext4    noatime,ro                       wait,slotselect,avb=vbmeta,avb_keys=no_such_key,logical,first_stage_mount

Google specified two verification methods for these partitions:

The errors you're seeing are caused by Android attempting to verify with avb_keys=no_such_key first. When that fails, it tries the other (valid) option and then succeeds.

The fact that avb_keys=no_such_key ended up in here is a bug on Google's end. This is not a security risk though. There's no way for someone to create a malicious file named no_such_key to trick Android into verifying with a different key. That would require modifying the system partition, which is not possible because it is properly signed and verified.