[AVB/AB] Overhaul plans

[AVB/AB] Overhaul plans

[Igor Opaniuk]

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 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

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!

[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

Re: [AVB/AB] Overhaul plans

[Mattijs Korpershoek]

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.

>
> 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]

[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)

>
> [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

Re: [AVB/AB] Overhaul plans

[Igor Opaniuk]

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.

>
> >
> > 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

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.

>
> [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

Re: [AVB/AB] Overhaul plans

[Mattijs Korpershoek]

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