AVB disable toggle and avb_custom_key flashing

[Unb0rn]

I wanted to check if the bootloader on lemonadep was fixed in A14 update - I generated the keys, the cert, signed an OTA, flashed everything as per the doc but I met several problems along this path:

• The pubkey is not being flashed on device: Warning: skip copying avb_custom_key image avb footer (avb_custom_key partition size: 0, avb_custom_key image size: 1032) Can it be linked to the current device state? Maybe something is patched incorrectly or I have to flash something else? Or the bootloader is completely incompatible with custom keys now? (I think after upgrading to A12 it was possible to flash the key, but locking the bootloader would render device unbootable)
• (Probably result of the previous error) - AVB is completely disabled, grepping avb from dmesg results now in init: AVB is not enabled, skip verity setup for /metadata

The ota is verified without problems:

0.000s INFO Verifying whole-file signature
1.165s INFO Verifying payload
3.230s INFO Extracting partition images to temporary directory
3.230s INFO Extracting from the payload: abl, aop, bluetooth, boot, cpucp, devcfg, dsp, dtbo, engineering_cdt, featenabler, hyp, imagefv, keymaster, modem, multiimgoem, odm, oplus_sec, oplusstanvbk, product, qupfw, qweslicstore, shrm, splash, system, system_ext, tz, uefisecapp, vbmeta, vbmeta_system, vbmeta_vendor, vendor, vendor_boot, vendor_dlkm, xbl, xbl_config
14.314s INFO Successfully extracted OTA
14.315s INFO Verifying partition hashes
15.223s INFO Checking ramdisk's otacerts.zip
15.302s INFO Verifying AVB signatures
15.302s INFO vbmeta has a signed vbmeta header
15.303s INFO boot has a signed vbmeta header
15.303s INFO vendor_boot has a signed vbmeta header
15.304s INFO dtbo has a signed vbmeta header
15.304s INFO vbmeta_system has a signed vbmeta header
15.305s INFO vbmeta_vendor has a signed vbmeta header
15.305s INFO Verifying hash descriptor for: vendor_boot
15.305s INFO Verifying hash tree descriptor for: vendor_dlkm
15.305s INFO Verifying hash descriptor for: boot
15.305s INFO Verifying hash tree descriptor for: system_ext
15.305s INFO Verifying hash tree descriptor for: system
15.305s INFO Verifying hash tree descriptor for: vendor
15.305s INFO Verifying hash tree descriptor for: product
15.305s INFO Verifying hash tree descriptor for: odm
15.305s INFO Verifying hash descriptor for: dtbo
19.296s INFO Signatures are all valid!

And can be flashed through recovery without any problems
So it feels like the problem is in the new BL, but I want to be sure I'm not doing something wrong)

[chenxiaolong]

Warning: skip copying avb_custom_key image avb footer (avb_custom_key partition size: 0, avb_custom_key image size: 1032)

It looks they completely removed the functionality in the new bootloader version. Based on the error message, the bootloader is trying to flash a partition named avb_custom_key instead of handling avb_custom_key as a special case (for enrolling a key).

(Probably result of the previous error) - AVB is completely disabled, grepping avb from dmesg results now in init: AVB is not enabled, skip verity setup for /metadata

Yep, that is almost certainly the case.

The specific behavior in that error message is a LineageOS-specific addition. Normally, when the bootloader is unlocked, dm-verity remains enabled. dm-verity with an unlocked bootloader doesn't really provide much security, but dm-verity has other useful functionality like detecting and correcting corruption of OS partitions. That functionality is also getting disabled here.

I'm guessing LineageOS disables dm-verity when AVB is non-functional because they assume that if users are leaving the bootloader unlocked, they probably intend to flash other things that modify the OS partitions and dm-verity would get in the way of that.

[Unb0rn]

Got it. Thank you! Well, it seems instead of fixing the BL they just removed the feature altogether then...

[Unb0rn]

I had several tests with my other device - Pixel 8 Pro (husky) - seems like flashing avb_custom_key always returns this error with partition size. Tested it with ROMs natively supporting relocking - Calyx and Graphene. Also locking works well too.

So, is there any way to enable AVB for my old lemonadep device?
In addition to ota verify I also unpacked the ramdisk and checked the fstab - everything seems to be in order, but dmesg still tells me AVB is not enabled.

[chenxiaolong]

On your lemonadep device, are you seeing the AVB errors in dmesg before or after locking the bootloader? (or both?)

If the bootloader is locked, please give https://play.google.com/store/apps/details?id=io.github.vvb2060.keyattestation a try. It'll report the bootloader's true state via hardware attestation. You can try comparing what it looks like between your two devices. If it's working properly, you should see this:

• Verified boot key should match the output of openssl dgst -sha256 -binary avb_pkmd.bin | base64
• Device locked should be true
• Verified boot state should be Self-signed

If any of those are invalid, then the bootloader is not properly using your custom key and enforcing AVB.

[Unb0rn]

It looks like there's more to it - I signed a new OTA, flashed everything as before. After flashing lock I got this message (oppo-style on oneplus) stating something like the current image (boot/recovery) have been destroyed and can not boot
So it looks like it now tries to verify something before boot and fails.
After unlocking again and wiping data in recovery I now get (with the new vbmeta, from the signed OTA): Unable to enable ext4 verity on /dev/block/by-name/metadata because /system/bin/tune2fs is missing. So, it looks like the ROM doesn't have a tool to enable verity or am I wrong?

[chenxiaolong]

Unable to enable ext4 verity on /dev/block/by-name/metadata because /system/bin/tune2fs is missing

That's unrelated to the boot issues you're seeing. The boot process depends on dm-verity for read-only partitions like system/vendor.

The message is about enabling a similarly named feature, fs-verity, not dm-verity. Android tries to enable it for writable partitions like metadata/userdata. It allows a file to be written once and then be cryptographically guaranteed that it is never modified again. Android doesn't actually use this feature for the metadata partition. It prints out the warning and then ignores the result.

[Unb0rn]

Got it!
Anyway, I guess, there's nothing we can do - the OTA is verified, flashed through fastboot (and double checked through sideload), avb_custom_key flashed but BL throws this error about destroyed images. Thanks for your help!