Re: [PATCH v2 0/5] avb: device lock state, root key provisioning and in-place verification

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

Hi Igor,

Thank you for the series

On Mon, Oct 12, 2026 at 22:25, Igor Opaniuk <igor.opaniuk@oss.qualcomm.com> wrote:

> This series completes the device state handling of the AVB 2.0
> implementation when the state is kept by the OP-TEE AVB TA, and fixes
> the way the Android bootmeth hands the boot images to libavb.
>
> Patches 1 and 2 add the shell side: "avb read_pvalue_hex" and
> "avb write_pvalue_hex" provision binary persistent values such as the
> SHA-256 digest of the vbmeta signing key that CONFIG_AVB_ROOT_KEY_TEE
> consumes, and "avb lock"/"avb unlock" set the lock state through a new
> avb_write_lock_state() helper. Until now U-Boot could only read the
> lock state, so a device backed by the TA could never leave the unlocked
> (orange) state.
>
> Patch 3 makes bootmeth_android verify the boot images in the buffers it
> boots them from, via AvbOps.get_preloaded_partition(), instead of
> letting libavb read, hash and free its own copies and then reading the
> partitions a second time for booting. This closes the TOCTOU window
> reported on the list and halves the amount of data read from storage.
>
> Patch 4 adds "fastboot flashing lock|unlock|get_unlock_ability" and the
> "unlocked" variable, so the state can be changed with the Android
> fastboot tool. Both transitions erase userdata and metadata before the
> state changes, as AVB requires.
>
> Patch 5 documents the root key sources, the provisioning of the TEE
> digest and the lock state in doc/android/avb2.rst.
>
> Tested on QEMU virt with OP-TEE 4.11.0-rc1 and the Cuttlefish Android
> 17 images: the chain boots locked (green) to sys.boot_completed, a
> modified kernel is refused, "fastboot flashing unlock/lock" over
> "fastboot tcp" erase the partitions and flip the state reported by
> "getvar unlocked" and "avb is_unlocked", and QEMU's SD card block trace
> shows every sector of boot and vendor_boot read exactly once.
>
> The lock state is stored in RPMB by the TA; on boards where U-Boot
> serves the RPMB requests of OP-TEE itself, the two fixes in "optee: two
> RPMB fixes for RPMB requests served by U-Boot" are needed at run time.
> There is no build dependency.
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>

Boot tested this on khadas-vim3_android_ab_defconfig using the following
AOSP images:
http://public.amlogic.binaries.baylibre.com/ci/build/baylibre/2026-09-17/2026-09-17_yukawa-bp2a-userdebug_vim3_yukawa-android-16_mainline_b25.tar.gz

Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>