All of lore.kernel.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: 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 [this message]
2026-04-25 14:11     ` Lothar Rubusch
2026-04-28 15:35   ` Thorsten Blum
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 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.