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]> --- Changes in v2: - fastboot: guard the flashing_lock/unlock/get_unlock_ability prototypes with FASTBOOT_CMD_FLASHING. They were declared unconditionally while their definitions sit under that option, so every configuration with fastboot but without the flashing commands (sandbox, sei510, ...) failed with "declared 'static' but never defined" under -Werror. v1 was only build-tested on configurations that enable the option; the sandbox CI jobs caught it. The series is now also build-tested with sandbox, sandbox64 (out of tree) and the arm64/arm32 boards that enable AVB or fastboot flashing, and the 107-column dispatch line is wrapped. - Link to v1: https://patch.msgid.link/20261011-upstream-avb_lock_unlock_b4-v1-0-a45aeca54...@oss.qualcomm.com --- Igor Opaniuk (5): cmd: avb: add read_pvalue_hex/write_pvalue_hex cmd: avb: add lock/unlock commands avb: verify the boot images in the buffers they are booted from fastboot: add flashing lock/unlock/get_unlock_ability doc: android/avb2: document the root key provisioning and lock state boot/bootmeth_android.c | 73 ++++++++++++++++++---- cmd/avb.c | 141 ++++++++++++++++++++++++++++++++++++++++++ common/avb_verify.c | 103 ++++++++++++++++++++++++++++++ doc/android/avb2.rst | 69 +++++++++++++++++++++ drivers/fastboot/Kconfig | 11 ++++ drivers/fastboot/fb_command.c | 119 +++++++++++++++++++++++++++++++++++ drivers/fastboot/fb_getvar.c | 34 ++++++++++ include/avb_verify.h | 39 ++++++++++++ include/fastboot.h | 3 + 9 files changed, 580 insertions(+), 12 deletions(-) --- base-commit: ed869863c7e2aca50d57a05d843830dd843138c4 change-id: 20261011-upstream-avb_lock_unlock_b4-d3a266c809d4 Best regards, -- Igor Opaniuk <[email protected]>
