Hi James,

On 2026-07-20T04:13:44, 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.
>
> Validate the FIT cipher key length, IV length and unciphered-size
> property while preparing decryption, and build lib/aes/ by phase when
> FIT_CIPHER is enabled so the target-side decrypt helper is available to
> SPL builds. Use the DM AES provider helper when enabled, retaining the
> software implementation only when no provider supports the operation.
>
> For U-Boot proper, use decrypt_to for in-place decryption when the FIT
> payload is already in writable RAM. The encrypted data is no longer
> needed after hash verification, and this avoids a full-size allocation

Decrypting in place overwrites the encrypted payload, so a second bootm on
the same FIT re-hashes decrypted bytes (fails with verification on) or
decrypts twice and boots garbage silently (with verification off). How about
addding a note, and ideally make the second attempt fail cleanly in
the unverified case? What do you think?

> [...]
>
> boot/image-cipher.c         | 45 ++++++++++++++++++----
>  boot/image-fit.c            | 33 ++++++++++++++--
>  include/image.h             | 39 +++++++++++++++++--
>  include/u-boot/aes.h        | 27 ++++++++++----
>  lib/Makefile                |  2 +-
>  lib/aes/aes-decrypt.c       | 91 
> +++++++++++++++++++++++++++++++++++++--------
>  test/lib/Makefile           |  3 ++
>  test/lib/test_aes_decrypt.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 290 insertions(+), 39 deletions(-)

> diff --git a/lib/aes/aes-decrypt.c b/lib/aes/aes-decrypt.c
> @@ -4,37 +4,98 @@
> +#ifdef USE_HOSTCC
> +     return 0;
> +#else

This host stub still claims success while leaving *data and *size
untouched, so a host caller of fit_image_decrypt_data() uses an
uninitialised pointer. Since image_aes_decrypt_to() already returns
-ENOSYS on host, please make this one match so a host tool fails
cleanly rather than silently.

In any case:

Reviewed-by: Simon Glass <[email protected]>

Regards,
Simon

Reply via email to