testing/drivers/hash: Add unaligned buffer size test

[pbarada]

Add hash testing of unaligned buffer sizes via multiple call to ioctl(CIOCCRYPT) in a single session with buffer sizes incrementally increasing from zero size to 255 (with monotoncially increasing byte value data) to force all sizes to be handled by cryptodev implementations.

Summary

The Crypto API is silent on buffer size alignment and there is no testing that provides unaligned buffer sizes to ioctl(CIOCRYPT) in one session. This patch extends hash test utility (and adds Kconfig option to enable/disable) that starets with a zero-sized buffer passed to ioctl(CIOCCRYPT), then a one-byte buffer, then a two byt buffer and so on to stress the underlying cryptodev device's handling of unaligned buffers/sizes. The test continually increments the size of the buffer passed to ioctl(CIOCCRYPT) until its 255 bytes in length (causing underlying cryptodev to hash 32640 bytes of data). The data provided through all thes incrementally size increasing buffers is monotonically increassing bytes starting at 0x00.

Impact

• User experience: No adaptation required. This fix extends existing behavior.
• Build: No impact.
• Hardware: No impact.
• Documentation: No impact.
• Security: No impact.
• Compatibility: Backward compatible - adds testing functionality.

Testing

Build Host:

• OS: Ubuntu 24.04.4 LTS
• Compiler: arm-none-eabi-gcc 13.2.1

Target:

• Architecture: ARM (STM32H753ZI)
• Board: Nucleo-h753zi
• Configuration: nucleo-h753zi:crypto - then:
  • Disable cryptodev hardware support
  • Enable Crypto API Software library support
  • Enable Crypto API cryptodev software cipher support
• In Application Configuration:
  • Under Testing/drivers:
    • Enable hash unaligned buffer size test

Testing performed:

• Booted board and ran hash test utilities; verify hash test utilities with cryptodev software implementation.

Runtime testing:

From target console:

NuttShell (NSH) NuttX-12.13.0
nsh> uname -a
NuttX 12.13.0 bc3a2596c8-dirty Jun  2 2026 19:53:49 arm nucleo-h753zi
nsh> hash
hash md5 success
hash md5 success
hash md5 success
hash md5 success
hash md5 success
hash md5 success
hash md5 success
hash sha1 success
hash sha1 success
hash sha1 success
hash sha224 success
hash sha224 success
hash sha224 success
hash sha256 success
hash sha256 success
hash sha256 success
md5 huge block test success(4 passes over 153600 bytes to hash 614400 bytes)
sha1 huge block test success(4 passes over 153600 bytes to hash 614400 bytes)
sha224 huge block test success(4 passes over 153600 bytes to hash 614400 bytes)
sha256 huge block test success(4 passes over 153600 bytes to hash 614400 bytes)
md5 unaligned buffer size match success
sha1 unaligned buffer size match success
sha244 unaligned buffer size match success
sha256 unaligned buffer size match success
nsh>

[cederom]

Thank you @pbarada :-)

[pbarada]

Fixed "may be used uninitialized" warning/error from Xtensa compiler by force-initializing huge_block to NULL even though all code paths for huge_block assign it before reference. Pushed squashed commit.

[lupyuen]

FYI: I restarted the CI Build to fix the Docker Image

• ci/docker: bump risc-v toolchain gcc14 nuttx#19035

[lupyuen]

@pbarada Could you check this error? Thanks :-)
https://github.com/apache/nuttx-apps/actions/runs/26888626961/job/79428686703#step:10:943

Configuration/Tool: esp32-devkitc/crypto
hash.c: In function 'hash_main':
Error: hash.c:1081:3: error: 'huge_block' may be used uninitialized [-Werror=maybe-uninitialized]
 1081 |   free(huge_block);
      |   ^~~~~~~~~~~~~~~~
hash.c:913:18: note: 'huge_block' was declared here
  913 |   unsigned char *huge_block = NULL;
      |                  ^~~~~~~~~~

[pbarada]

@pbarada Could you check this error? Thanks :-) https://github.com/apache/nuttx-apps/actions/runs/26888626961/job/79428686703#step:10:943

Configuration/Tool: esp32-devkitc/crypto
hash.c: In function 'hash_main':
Error: hash.c:1081:3: error: 'huge_block' may be used uninitialized [-Werror=maybe-uninitialized]
 1081 |   free(huge_block);
      |   ^~~~~~~~~~~~~~~~
hash.c:913:18: note: 'huge_block' was declared here
  913 |   unsigned char *huge_block = NULL;
      |                  ^~~~~~~~~~

I'd love to "fix" it, but how can huge_block be uninitialized? The compiler notes at line 913 that huge_block is forcibly initialized during declaration to NULL which makes any code path that gets to line 1081 have an initialized value for huge_block.
May take a bit (need to install xtensa toolchain) and try some code rearrangements, but I believe that compiler warning is erroneously generated

[pbarada]

@pbarada Could you check this error? Thanks :-) https://github.com/apache/nuttx-apps/actions/runs/26888626961/job/79428686703#step:10:943

Configuration/Tool: esp32-devkitc/crypto
hash.c: In function 'hash_main':
Error: hash.c:1081:3: error: 'huge_block' may be used uninitialized [-Werror=maybe-uninitialized]
 1081 |   free(huge_block);
      |   ^~~~~~~~~~~~~~~~
hash.c:913:18: note: 'huge_block' was declared here
  913 |   unsigned char *huge_block = NULL;
      |                  ^~~~~~~~~~

I'd love to "fix" it, but how can huge_block be uninitialized? The compiler notes at line 913 that huge_block is forcibly initialized during declaration to NULL which makes any code path that gets to line 1081 have an initialized value for huge_block. May take a bit (need to install xtensa toolchain) and try some code rearrangements, but I believe that compiler warning is erroneously generated

Fixed.

1. Verified warning using xtensa-esp-elf-gcc (crosstool-NG esp-15.2.0_20251204) 15.2.0, added -Wextra to tease out any other lurking warnings in hash.c
2. Moved declaration of huge_block to top of main() to suppress "may be used uninitialized" warning
3. Added -Wextra to building of hash.c to see if other unreported warnings; declared "i" as unsigned int to suppress "comparison of integer expressions of different signedness" warning.