Re: [PATCH 1/2] crypto: drivers - avoid memcpy size warning

From: Arnd Bergmann
Date: Fri Aug 11 2023 - 09:38:30 EST


On Fri, Aug 11, 2023, at 12:48, Herbert Xu wrote:
> On Mon, Aug 07, 2023 at 02:04:05PM +0200, Arnd Bergmann wrote:

>
> struct atmel_sha_hmac_ctx *hmac = crypto_ahash_ctx(tfm);
> size_t bs = ctx->block_size;
>
> memcpy(hmac->opad, hmac->ipad, bs);
>
> The block_size is set by the algorithm, you can easily grep for
> it in atmel-sha.c and the biggest one there is SHA512_BLOCK_SIZE,
> which is how big hmac->ipad/hmac->opad are.
>
> So logically this code is perfectly fine.

Right, that was my conclusion as well.

> There is no way for the compiler to know how big ctx->block_size is.
> So why do we expect it to make deductions on how big bs can be?
>
> This warning looks broken to me.

I'm still unsure how exactly it goes wrong here, but I suspect
it works as designed and just happens to run into a case in these
drivers that is just not that common. I also see that the kernel's
memcpy() declaration is missing the "restrict" annotation,
but the fortified version calls the __builtin_memcpy() variant
that has an implicit prototype with those annotations.

> It looks like there is already a solution to this though. Just use
> unsafe_memcpy and be done with it.

Fine with me, I'll send a new version doing that.

Arnd