[AVB/AB] Overhaul plans
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/bootloade...
-- Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opaniuk@gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk
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-ade...
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/...
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/bootloade...
-- Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opaniuk@gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk
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-ade...
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/...
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/bootloade...
-- Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opaniuk@gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk
Regards, Igor
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-ade...
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/...
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/bootloade...
-- 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
participants (2)
-
Igor Opaniuk -
Mattijs Korpershoek