[PATCH 3/9] boot: image: add FIT decrypt-to-buffer helper

[Simon Glass]

Hi James,

On 2026-07-02T01:46:51, James Hilliard <james.hilliard1 at gmail.com> 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 <james.hilliard1 at gmail.com>
>
> 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