Hi Jan, On 2026-10-16T07:26:37, Jan Kehren <[email protected]> wrote: > avb: Take a storage interface in the AVB operations > > AVB assumed its partitions were on mmc: avb_ops_alloc() took a bare device > number and get_partition() called find_mmc_device(), which rules out > verified boot from anything else. > > The user that benefits is "avb init", where boards already expect to name > an interface: board/armltd/total_compute/total_compute.env picks between > virtio and mmc at runtime and then runs "avb init ${blk_dev} 0", which no > release has ever accepted. bootmeth_android gains nothing yet, since > android_check() rejects non-mmc bootdevs through bootflow_iter_check_mmc(). > > Carry a uclass id alongside the device number and resolve the block device > with blk_get_devnum_by_uclass_id(), keeping mmc_init() and the hardware > partition switch on the mmc path only. "avb init <dev>" still means mmc, > "avb init <interface> <dev>" selects another bus, and neither touches the > device: it is still resolved on the first partition access. > > Only mmc is started by AVB itself, so say that in Kconfig and avb2.rst. > > [...] > > boot/bootmeth_android.c | 2 +- > cmd/avb.c | 25 +++++++++--- > common/Kconfig | 7 +++- > common/avb_verify.c | 71 > +++++++++++++++++++++++----------- > doc/android/avb2.rst | 14 ++++++- > include/avb_verify.h | 26 ++++++++++--- > test/py/tests/test_android/test_avb.py | 28 ++++++++++++++ > 7 files changed, 135 insertions(+), 38 deletions(-)
> diff --git a/doc/android/avb2.rst b/doc/android/avb2.rst > @@ -29,6 +29,17 @@ integration in ``common/avb_verify.c`` and the platform > port under > +If the Android images live on another interface while the AVB trusted > +application keeps its state in eMMC RPMB, the trusted application's first > +RPMB request is also the first eMMC access, and it is made from within a > +supplicant RPC. That needs OP-TEE to tolerate a nested RPMB announcement. As written, a board maintainer can't act on this. Please can you name the OP-TEE version or commit that tolerates the nested announcement, or say what a board can do instead, e.g. run 'mmc dev' or 'mmc rescan' before AVB so the eMMC is already set up? > diff --git a/common/Kconfig b/common/Kconfig > @@ -885,9 +885,14 @@ config AVB_VERIFY > + Only mmc is initialised by AVB itself. Any other interface must > + already be enumerated when AVB runs, either by the board code or by > + a command such as "usb start". BTW AVB_VERIFY still depends on MMC, so a virtio-only board must still enable MMC to use this. That is fine for now, since avb_init_mmc() calls find_mmc_device(). A follow-up could guard the mmc path with IS_ENABLED(CONFIG_MMC) and drop the dependency. Neither of these is blocking: Reviewed-by: Simon Glass <[email protected]> BTW I had to get this patch from lore as patchwork seems to not have it.
