Re: [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes

Ard Biesheuvel
2026-04-23T09:25:39Z

Hi Lothar,

On Wed, 22 Apr 2026, at 23:09, Lothar Rubusch wrote:
> When testing the RNG functionality on the Atmel SHA204a hardware, I
> found the following issues: rngtest reported failures and hexdump
> reveiled only the first 8 bytes out of 32 provided actually entropy.
>
> Having a closer look into it, I found a (small) memory leak, missing
> to free work_data, miss-reading of the count field into the entropy
> fields and parts of the 32 random bytes staying 0 due to reading the
> slow i2c device.
>
> The series proposes fixes and how fixed functionality can be/was
> verified. Executing rngtest afterward showed a decent result, due
> to the i2c bus a bit slow.
>
> All setups require selecting the Atmel-sha204a as active RNG.
> $ cat /sys/class/misc/hw_random/rng_available
> 3f104000.rng 1-0064 none
>
> $ echo 1-0064 > /sys/class/misc/hw_random/rng_current
>
> $ cat /sys/class/misc/hw_random/rng_current
> 1-0064
>
> Testing RNG properties currently shows problematic results:
> $ rngtest < /dev/hwrng
> rngtest 2.6
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 1040032
> rngtest: FIPS 140-2 successes: 0
> rngtest: FIPS 140-2 failures: 52
> rngtest: FIPS 140-2(2001-10-10) Monobit: 52
> rngtest: FIPS 140-2(2001-10-10) Poker: 52
> rngtest: FIPS 140-2(2001-10-10) Runs: 52
> rngtest: FIPS 140-2(2001-10-10) Long run: 52
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 52
> rngtest: input channel speed: (min=7.631; avg=7.804; max=7.827)Kibits/s
> rngtest: FIPS tests speed: (min=32.273; avg=32.701; max=33.056)Mibits/s
> rngtest: Program run time: 130177956 microseconds
>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> v2 -> v3: Removal blank line, rebased
> v1 -> v2: Removal of C++ style comment (I saw it too late, sry for that)
> ---
> Lothar Rubusch (3):
> crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data
> crypto: atmel-sha204a - fix truncated 32-byte blocking read
> crypto: atmel-sha204a - fix non-blocking read logic
>
> drivers/crypto/atmel-sha204a.c | 60 ++++++++++++++++++++++------------
> 1 file changed, 39 insertions(+), 21 deletions(-)
>

Thanks for the report and the fixes. However, I'm not sure you are entirely
on the right track here. I managed to fix the rngtest issues that you report by
making the changes below. As I already replied, I think it would be better to
propose this as a standalone patch, and backport it to stable.

The remaining changes are somewhat debatable IMO: the leak is not really a leak,
so I'd like to understand better what you are fixing here. The command field
changes seems completely misguided (unless I am missing something)

--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -47,8 +47,8 @@

if (rng->priv) {
work_data = (struct atmel_i2c_work_data *)rng->priv;
- max = min(sizeof(work_data->cmd.data), max);
- memcpy(data, &work_data->cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &work_data->cmd.data[1], max);
rng->priv = 0;
} else {
work_data = kmalloc_obj(*work_data, GFP_ATOMIC);
@@ -86,8 +86,8 @@
if (ret)
return ret;

- max = min(sizeof(cmd.data), max);
- memcpy(data, cmd.data, max);
+ max = min(RANDOM_RSP_SIZE - CMD_OVERHEAD_SIZE, max);
+ memcpy(data, &cmd.data[1], max);

return max;
}