Recently I have gotten into many conversations around AVB - Android Verified Boot - and how apparently, any ROM which doesn't ship with it is inherintly insecure, but I don't agree with that sentiment and I want to explain why.

Android Verified Boot essentially works by having two components, one of which houses valid signatures (vbmeta) and the other being your actual system, signed with the set of valid signatures.

To ensure that your system isn't compromised - or rather modified - Android uses a kernel feature called dm-verity. According to the Android Documentation:

The dm-verity feature lets you look at a block device, the underlying storage layer of the file system, and determine if it matches its expected configuration. It does this using a cryptographic hash tree. For every block (typically 4k), there is a SHA256 hash.

This essentially means that you can use dm-verity to verify that your filesystem is unmodified / configured in an expected way.

Android Verified Boot and dm-verity work hand in hand to make sure that, on a locked device, there is no tampering done to compromise the device, install rootkits or do other shenanigans.

What Android Verified Boot doesn't do.

1. AVB Doesn't protect your device from temporary root solutions being abused, like what POCs like mtk-su would allow. Android verified boot is at it's core a mechanism to verify that the system is in an expected (or supported) state, so if the system is never actually modified, dm-verity never gets tripped and AVB never stops working. This means that programs CAN indeed gain root access through exploits on locked bootloaders.
2. AVB Doesn't prohibit user-facing root solutions. Because of how AVB works, you can indeed install something like Magisk or KernelSU and continue to use it on a locked bootloader with Android Verified Boot. all you have to do is:
   • Make sure your device can set custom AVB keys
   • Sign your (patched) boot image or KernelSU GKI image with a valid key
   • Flash your device with said images
   • Make sure AVB doesn't report any errors in the UNLOCKED state (where it doesn't report errors as fatal)
   • Lock the bootloader.
   Or you can just use AVBRoot. Of course, this is YOU rooting the device. When AVB is disabled / not treating errors as fatal, that doesn‘t mean that any app can just elevate to root. Exploits which allow you to get root access work with or without AVB (see point 1).
3. AVB Doesn't relate to encryption, runtime permissions, and other security measures found within the OS. Other security measures that are found within the Android OS aren't directly related to AVB. For example, runtime permissions are fine without it, so is encryption. (including File Based Encryption* that's used nowadays)* This means that outside of verified boot, you're absolutely fine using Custom ROMs that don't offer AVB 2.0 support with a locked bootloader out of the box. BUT If one component isn‘t working right, you may be subject to „Evil Maid“ attacks, which involve somebody having physical access to your device and installing malicious software to, for example, bypass encryption or otherwise extract data. More on Wikipedia

Conclusion

So essentially, Android Verified Boot isn't this silver bullet that can enact perfect security against every single thing that can, has or will ever attack your Android device, but it does provide a secure-boot-esque environment that can be highly beneficial if you're securing your device.

As a general rule of thumb, look at your threat model and whether something like AVB (and other secure/verified boot mechanisms for that matter) is required for your personal security before jumping to conclusions.

---

Thank you very much for reading! This time I wanted to write a bit of a shorter post, but I'll probably be back with something longer some time down the line. Either way, I wish you a wonderful day, night, or whatever other time you're reading this! <3