FR: Erase partition "avb_custom_key"

[lucasmz-dev]

Some devices support bootloader relocking with custom Verified Boot keys, and it is used by relockable OSes like CalyxOS. (which now supports the G32, G42 and G52, but doesn't have instructions for returning to stock yet)

One partition used by these OSes for this, seems to be avb_custom_key. This is not removed by Motorola's setup.

Motorola doesn't seem to ship this; so it might be nice to run this in order to prevent possible issues with security.

Note: it's possible there are other partitions used that would also be part of a custom signed Verified Boot setup that I'm not aware.

[dlenski]

I don't think I understand this description fully…

Are you saying that this AVB_CUSTOM_KEY partition gets created during the installation of a non-stock OS, but doesn't get properly removed/erased when you return to a stock OS?

And you want to have an option (let's say motoflash2sh --erase-partition AVB_CUSTOM_KEY) to insert an extra command to erase it?

Or something else?

[lucasmz-dev]

Yeah, that's basically the issue, to be fair I'm unaware of the consequences (if any) of this partition staying there

I was thinking more along the lines of when an XML is converted into a .sh file, that that command would be inserted like at the beginning as an extra cleanup step

This might not be the scope of this project so I'm fine with how this works, it does what it says it does, though maybe I should test what is possible with this partition being there (like maybe it would be possible to flash partitions from the custom OS and maybe bypass things like Google FRP, as long as there's awareness about this when it comes to users of a certain OS we should be fine)

Usually the custom OS would warn about this; I personally noticed this issue and found it curious. But to be fair it doesn't seem to be the scope of this tool; I'm unsure if it's safe to run fastboot erase avb_custom_key on a device that doesn't have it, probably though?

[dlenski]

I'm unaware of the consequences (if any) of this partition staying there

For what it's worth, the newest Android device I own (and the newest device for which I've personally used motoflash2sh) is the Moto X4 which was released in 2017, and I've had it since 2018.

So my knowledge of Android devices’ seemingly-ever-more-complex partitioning schemes is not up-to-date 😬

I was thinking more along the lines of when an XML is converted into a .sh file, that that command would be inserted like at the beginning as an extra cleanup step

How would/should motoflash2sh decide if this cleanup step should be inserted?

I'm unsure if it's safe to run fastboot erase avb_custom_key on a device that doesn't have it, probably though?

It seems like this partition is used to store a persistent customized bootloader unlock key on Android 9.0+ devices, so that you can have a locked bootloader but still be able to run custom OSes:
https://android.googlesource.com/platform/external/avb/+/pie-release/README.md#pixel-2

So I'm skeptical that it makes sense to delete it as a default behavior 🤔

[lucasmz-dev]

For what it's worth, the newest Android device I own (and the newest device for which I've personally used motoflash2sh) is the Moto X4 which was released in 2017, and I've had it since 2018.

So my knowledge of Android devices’ seemingly-ever-more-complex partitioning schemes is not up-to-date 😬

For your comfort, nothing seems to have changed with how Motorola deals with flashing. It seems like the partition scheme Android is using now a days AFAIK is A/B, which is the one my device uses, and the XML files seem to deal with it very similarly to before; though if I was to go back to stock right now, I would maybe switch slots and re-do the flashing on the other slot. (It seems as if avb_custom_key is just one for the device, no _a or _b variants)

How would/should motoflash2sh decide if this cleanup step should be inserted?

That I'm not sure. I don't think there is any way to check, though it should be safe to delete it.

It seems like this partition is used to store a persistent customized bootloader unlock key on Android 9.0+ devices, so that you can have a locked bootloader but still be able to run custom OSes: https://android.googlesource.com/platform/external/avb/+/pie-release/README.md#pixel-2

So I'm skeptical that it makes sense to delete it as a default behavior 🤔

Considering it is not the same signing key as stock, I think it does, I'm just worried perhaps Motorola doesn't do it.