From: Thorsten Blum <thorsten.blum@linux.dev>
To: Lothar Rubusch <l.rubusch@gmail.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
nicolas.ferre@microchip.com, alexandre.belloni@bootlin.com,
claudiu.beznea@tuxon.dev, ardb@kernel.org, linusw@kernel.org,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read
Date: Tue, 28 Apr 2026 17:35:40 +0200 [thread overview]
Message-ID: <afDTzL9zsSTaZtZD@linux.dev> (raw)
In-Reply-To: <20260422210936.20095-3-l.rubusch@gmail.com>
On Wed, Apr 22, 2026 at 09:09:35PM +0000, Lothar Rubusch wrote:
> The ATSHA204A returns a 35-byte packet consisting of a 1-byte count,
> 32 bytes of entropy, and a 2-byte CRC. The current blocking read
> implementation was incorrectly copying data starting from the
> count byte, leading to offset data and truncated entropy.
>
> Additionally, the chip requires significant execution time to
> generate random numbers, going by the datasheet. Reading the I2C bus
> too early results in the chip NACK-ing or returning a partial buffer
> followed by zeros.
>
> Verification:
> Tests before showed repeadetly reading only 8 bytes of entropy:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
>
> After this patch applied, the result will be as follows:
> $ head -c 32 /dev/hwrng | hexdump -C
> 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i|
> 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.|
> 00000020
>
> Fix these issues by:
> Increase cmd.msecs to 30ms to provide sufficient execution time. Then
> set cmd.rxsize to RANDOM_RSP_SIZE (35 bytes) to capture the entire
> hardware response. Eventually, correct the memcpy() offset to index 1 of
> the data buffer to skip the count byte and retrieve exactly 32 bytes of
> entropy.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
> drivers/crypto/atmel-sha204a.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 19720bdd446d..f7dc00d0f4cd 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -19,6 +19,9 @@
> #include <linux/workqueue.h>
> #include "atmel-i2c.h"
>
> +#define ATMEL_RNG_BLOCK_SIZE 32
> +#define ATMEL_RNG_EXEC_TIME 30
Maybe I missed it, but how did you arrive at 30 ms from the datasheet?
Thanks,
Thorsten
next prev parent reply other threads:[~2026-04-28 15:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 21:09 [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes Lothar Rubusch
2026-04-22 21:09 ` [PATCH v3 1/3] crypto: atmel-sha204a - fix memory leak at non-blocking RNG work_data Lothar Rubusch
2026-04-23 7:43 ` Ard Biesheuvel
2026-04-26 13:33 ` Thorsten Blum
2026-04-26 16:16 ` Lothar Rubusch
2026-04-22 21:09 ` [PATCH v3 2/3] crypto: atmel-sha204a - fix truncated 32-byte blocking read Lothar Rubusch
2026-04-23 7:55 ` Ard Biesheuvel
2026-04-25 13:46 ` Thorsten Blum
2026-04-25 14:08 ` Thorsten Blum
2026-04-25 14:11 ` Lothar Rubusch
2026-04-28 15:35 ` Thorsten Blum [this message]
2026-04-22 21:09 ` [PATCH v3 3/3] crypto: atmel-sha204a - fix non-blocking read logic Lothar Rubusch
2026-04-23 7:56 ` Ard Biesheuvel
2026-04-23 9:25 ` [PATCH v3 0/3] crypto: atmel-sha204a - multiple RNG fixes Ard Biesheuvel
2026-04-25 13:34 ` Lothar Rubusch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afDTzL9zsSTaZtZD@linux.dev \
--to=thorsten.blum@linux.dev \
--cc=alexandre.belloni@bootlin.com \
--cc=ardb@kernel.org \
--cc=claudiu.beznea@tuxon.dev \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=l.rubusch@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.