public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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: Sat, 25 Apr 2026 16:08:00 +0200	[thread overview]
Message-ID: <aezKwAqWPo0kXHDu@linux.dev> (raw)
In-Reply-To: <aezFsF8gLkABZZ1O@linux.dev>

On Sat, Apr 25, 2026 at 03:46:30PM +0200, Thorsten Blum wrote:
> Hi Lothar,
> 
> 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>

[...]

> > -	max = min(sizeof(cmd.data), max);
> > -	memcpy(data, cmd.data, max);
> > +	max = min_t(size_t, ATMEL_RNG_BLOCK_SIZE, max);
> > +	memcpy(data, &cmd.data[1], max);

I just noticed that index 1 is already defined as RSP_DATA_IDX in
drivers/crypto/atmel-i2c.h.

> This works and fixes rngtest for me on real hardware.
> 
> min_t() is not strictly necessary here, since the types are compatible
> and min() is sufficient.
> 
> I agree with Ard that patch 2/3 should be a separate patch for easier
> stable backporting.

Thanks,
Thorsten


  reply	other threads:[~2026-04-25 14:08 UTC|newest]

Thread overview: 12+ 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-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 [this message]
2026-04-25 14:11     ` Lothar Rubusch
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=aezKwAqWPo0kXHDu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox