Hi James, On 2026-07-02T01:46:51, James Hilliard <[email protected]> wrote: > boot: image: add FIT decrypt-to-buffer helper > > FIT cipher support currently allocates the output buffer inside the AES > helper. SPL often needs to decrypt directly into a caller-selected buffer, > for example a load buffer or a scratch buffer used before decompression. > > Add a decrypt_to callback to the FIT cipher algorithm and wire it up for > AES. The existing allocating decrypt path becomes a wrapper around the new > helper. > > When DM_AES is enabled, try the first UCLASS_AES provider before using the > software AES fallback in U-Boot proper. Return AES device errors to the > caller instead of hiding them with a software fallback after the device has > accepted the operation. > > Signed-off-by: James Hilliard <[email protected]> > > boot/image-cipher.c | 38 ++++++++++++++++++-- > boot/image-fit.c | 7 ++-- > include/image.h | 39 ++++++++++++++++++-- > include/u-boot/aes.h | 10 ++++++ > lib/Makefile | 2 +- > lib/aes/aes-decrypt.c | 98 > +++++++++++++++++++++++++++++++++++++++++++-------- > 6 files changed, 170 insertions(+), 24 deletions(-)
> Add a decrypt_to callback to the FIT cipher algorithm and wire it up for > AES. The existing allocating decrypt path becomes a wrapper around the new > helper. This patch also adds key/IV length validation in fit_image_setup_decrypt(), a length check on 'data-size-unciphered' in fit_image_get_data_size_unciphered() and makes the lib/aes/ build rule phase-keyed, none of which is mentioned in the commit message. Please can you split the validation hardening into its own patch, or at least explain it here? The lib/Makefile change looks like preparation for SPL support, so it might sit better in patch 4 which adds SPL_FIT_CIPHER > diff --git a/lib/aes/aes-decrypt.c b/lib/aes/aes-decrypt.c > @@ -4,37 +4,105 @@ > + unsigned int aes_blocks, key_len = info->cipher->key_len; > + int ret = -ENOSYS; > + > + ret = image_aes_validate_lengths(info, cipher_len); The -ENOSYS initialiser is dead, since ret is immediately overwritten by the validate call. So in an XPL build with DM_AES disabled the function falls past both the DM and software paths and returns 0 without decrypting anything. Kconfig prevents that combination once patch 4 makes SPL_FIT_CIPHER depend on SPL_DM_AES, but silent success here would be nasty to debug. Please return -ENOSYS explicitly when no implementation is available > diff --git a/lib/aes/aes-decrypt.c b/lib/aes/aes-decrypt.c > @@ -4,37 +4,105 @@ > + ret = dm_aes_set_key_for_key_slot(dev, key_len * 8, > + (u8 *)info->key, 0); > + if (ret) > + return ret; > + > + ret = dm_aes_select_key_slot(dev, key_len * 8, 0); Just to check, is it safe to assume key slot 0 is free on all UCLASS_AES providers? On Tegra, slot 0 is TEGRA_AES_SLOT_SBK, holding the secure boot key loaded by the bootrom, so writing the FIT key there would clobber it (see arch/arm/include/asm/arch-tegra/crypto.h and tegra_aes.c). It might be safer to pick the last slot reported by dm_aes_available_key_slots(), or make the slot a parameter. What do you think? Regards, Simon
