Does switching between ROMs signed with same AVBroot keys need unlocked bootloader?

[e-t-l]

If I have signed and flashed one ROM with AVBroot and relocked the bootloader, and I want to switch to a different ROM (for example, from GrapheneOS to CalyxOS), if I continue using AVBroot with the same signing keys, do I still need to unlock the bootloader to flash the new ROM?

[chenxiaolong]

In theory, no, though I've never personally tried it. If you end up trying this, I would suggest wiping data and flashing the new OS's OTA in the same recovery session.

[chenxiaolong]

Actually, I would not recommend this unless you're certain the bootloader version contained in the new OS's OTA is >= your currently installed bootloader version.

[e-t-l]

unless you're certain the bootloader version contained in the new OS's OTA is >= your currently installed bootloader version.

This part actually seems like a relatively easy thing to check. I just wasn't sure how to the whole process worked exactly, or what is contained in an "OTA" anyway.

In the Initial Setup, you wrote:

When setting things up for the first time, the device must already be running the correct OS.

That made me wonder if "the correct OS" refers to Graphene vs Calyx vs PixelOS etc. If not, then hypothetically I should just be able to use ADB sideload to flash a new ROM, just as long as:

1. It's signed with the same signing keys as the previously flashed one
2. The update version is newer than the previously flashed one
   2a. The bootloader version is newer than the previously flashed one

Is that right?

[chenxiaolong]

Ah, those are good questions.

what is contained in an "OTA" anyway

An OTA contains the full OS and also the bootloader.

That made me wonder if "the correct OS" refers to Graphene vs Calyx vs PixelOS etc.

For the initial setup documentation, yes. The fastboot flashall step only flashes the partitions that avbroot modified, not all partitions, which is why the correct OS must already be installed.

With what you're planning to do, every partition will get flashed during OTA installation, so that's not really relevant here.

hypothetically I should just be able to use ADB sideload to flash a new ROM, just as long as:

1. It's signed with the same signing keys as the previously flashed one
2. The update version is newer than the previously flashed one
   2a. The bootloader version is newer than the previously flashed one

Is that right?

Yep! However, point 2 is where issues could potentially occur.

AVB 2.0 has a concept of rollback indices. A partition can have a rollback index, which is a version number. It's allowed to increase or stay the same, but cannot decrease or else the device will fail to boot due to downgrade protection.

Not every OS uses rollback indices the same way. For example, the stock Pixel OS uses them on boot and vbmeta, but GrapheneOS only uses it on vbmeta. Using this method of switching from the stock Pixel OS to GrapheneOS would leave the device unbootable until the bootloader was unlocked and relocked again. (It would see that boot was downgraded from whatever the stock OS version was to version 0.)

[e-t-l]

Very informative, thank you!

Using this method of switching from the stock Pixel OS to GrapheneOS would leave the device unbootable

But switching from Graphene to stock PixelOS should work fine, then?

leave the device unbootable until the bootloader was unlocked and relocked again

So in this scenario, while it wouldn't boot the OS, it could still get to flashboot, which is where you can unlock the bootloader, right?

[chenxiaolong]

No problem!

But switching from Graphene to stock PixelOS should work fine, then?

Yep, I believe so.

So in this scenario, while it wouldn't boot the OS, it could still get to flashboot, which is where you can unlock the bootloader, right?

Yep (as long as the OEM unlocking checkbox was previously checked from Android, as usual).

[e-t-l]

Any idea if it's possible to edit the boot index value of an OTA file before flashing it?

[chenxiaolong]

Yes it is, but it's painful to do. The general approach (which I have not tested) would be:

• Extract the OTA with avbroot ota extract
• Check avbroot avb info -i <partition>.img for each partition to see if it uses rollback_index
• If it does, unpack it avbroot avb unpack, edit the value in avb.toml, and repack it with avbroot avb pack
• Patch the OTA, specifying --replace <partition> <partition>.img for every partition that was modified