Re: [AVB/AB] Overhaul plans

[Mattijs Korpershoek <mkorpershoek@baylibre.com>]

Hi Igor,

On Fri, Feb 09, 2024 at 17:17, Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> Hello Mattijs,
>
> On Fri, Feb 9, 2024 at 11:30 AM Mattijs Korpershoek
> <mkorpershoek@baylibre.com> wrote:
>>
>> Hi Igor,
>>
>> On ven., févr. 09, 2024 at 11:14, Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>>
>> > Hi everyone,
>> >
>> > I'm currently planning a big overhaul of the current implementation of
>> > AVB/AB in U-Boot during the 2024 year, which I have barely touched since
>> > 2019. I used to believe that it was stillborn, but looks like it's
>> > being actively used
>> > now by some SoC vendors and Google folks [1][2].
>>
>> This is great news! I am not aware of any development related to the
>> above but I'm looking forward to this.
>>
>> I can't speak for all vendors but I know that TI uses both the AVB and
>> AB implementation on their AM62x Android solution.
> Amlogic also uses it.

I know for VIM3 and VIM3L (since quite some folks at BayLibre were
involved in this, including myself) :)

I did not know that they use the commands in their vendor implementation.

>
>>
>> >
>> > This is what I have in my todo list:
>> > * Backport latest libavb from AOSP upstream and add support for
>> >    Verified Boot 1.3.0 version
>> > * Sync include/android_bootloader_message.h with AOSP upstream
>> > * Check and backport fixes for AVB in AOSP U-Boot fork if needed [1]
>> > * Get acquainted with a current state of A/B support in AOSP and
>> >    backport all needed changes
>> > * Re-factor libavb, switch to U-Boot existing implementation of
>> >    rsa/sha256/sha512
>> > * Add SHA512 implementation that leverage ARMv8 CE
>> >    (pull it from Linux)
>> > * Enable hw acceleration of SHA256/SHA512 that supports ARMv8
>> >    Crypto Extensions to speed up verification process on ARMv8-based boards.
>> > * AVB support for NAND storage
>>
>> I know that this has been send but I don't think Alistair has send any
>> follow-up on this:
>> https://patchwork.ozlabs.org/project/uboot/patch/20220926220211.868968-1-adelva@google.com/
>>
>> >
>> > If someone is already working on anything from the above list -
>> > please feel free to reach out to me, so we can avoid duplication of effort.
>> >
>> > Any comments/suggestions are welcome! Thanks!
>>
>> From my understanding, the AOSP version of U-Boot has quite a different
>> bootflow since it relies on the (out-of-tree) boot_android command [3]
>
> Correct, but it turned out that they are using some parts of the existing avb
> implementation in that out-of-tree "boot_android" cmd +
> the made some adjustments on top of it, that we might be interested in :
>
> $ git log --grep=ANDROID --oneline | grep avb
> ea8f0bb45e ANDROID: Add avb_verify unit tests
> c9f88bf213 ANDROID: Adding function comments to avb_verify
> c5599e4a9f Merge "ANDROID: avb_verify: Handle failed malloc in get_partition()"
> 3aeeae4426 ANDROID: avb_verify: Handle failed malloc in get_partition()
> 2910c1042c Merge "ANDROID: avb_pubkey: Use bin2c instead of ld"
> 30fbf100b6 Merge "ANDROID: avb: Extract avb_pubkey_is_trusted()"
> 296361e80c ANDROID: avb_pubkey: Use bin2c instead of ld
> 5af2c6d968 ANDROID: avb: Extract avb_pubkey_is_trusted()
> f74b3f5815 ANDROID: avb_verify: Don't Return ERROR_IO for mismatch in
> pubkey sizes
> d6615cd233 Merge "ANDROID: Qualify avb_find_main_pubkey() parameters as const"
> 9c8470ed6b ANDROID: Qualify avb_find_main_pubkey() parameters as const
> af808f4b04 ANDROID: avb_find_main_pubkey returns CMD_RET_*
> 2070f02c75 ANDROID: remove erraneous avb logs

Indeed, these seem interesting.

>
> Btw, my initial intention (back in 2018) was to make avb
> implementation boot-command
> agnostic, as at the time of implementing it different board/SoC
> vendors used different
> approaches for booting AOSP; moreover, iirc AOSP-specific cmd
> (boota/boot_android
> or whatever it's called now) didn't manage to land to the U-Boot
> mainline despite
> multiple attempts by different contributors.

Understood. Maybe with bootflow/bootmeth we could do something named
bootmeth_android !
>
>>
>> [3] https://android.googlesource.com/platform/external/u-boot/+/refs/heads/main/cmd/boot_android.c
>>
>> Please keep me in the loop with your progress. If you want, you can
>> reach me on IRC as well (libera: #u-boot, nick: mkorpershoek)
> Sure, will keep you posted!
>
>>
>> >
>> > [1] https://android.googlesource.com/platform/external/u-boot
>> > [2] https://source.android.com/docs/devices/cuttlefish/bootloader-dev
>> > [3] https://android.googlesource.com/platform/bootable/recovery/+/main/bootloader_message/include/bootloader_message/bootloader_message.h
>> >
>> > --
>> > Best regards - Atentamente - Meilleures salutations
>> >
>> > Igor Opaniuk
>> >
>> > mailto: igor.opaniuk@gmail.com
>> > skype: igor.opanyuk
>> > http://ua.linkedin.com/in/iopaniuk
>
> Regards,
> Igor
>
> -- 
> Best regards - Atentamente - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opaniuk@gmail.com
> skype: igor.opanyuk
> http://ua.linkedin.com/in/iopaniuk