Hi Igor, Thank you for the series
On Mon, Oct 12, 2026 at 22:25, Igor Opaniuk <[email protected]> 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 <[email protected]> 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 <[email protected]>
