Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440
Mime-Version: 1.0
Message-Id: <8c3b242f-7d6f-4bec-9a44-61ac65a26637@app.fastmail.com>
In-Reply-To: <ZNYSFWA3WNAdRqfg@gondor.apana.org.au>
References: <20230724135327.1173309-1-arnd@kernel.org>
 <ZMyz27awrVJ8QHzA@gondor.apana.org.au>
 <d9184ad7-7d34-45bf-81e3-db053bf7425c@app.fastmail.com>
 <ZNYSFWA3WNAdRqfg@gondor.apana.org.au>
Date:   Fri, 11 Aug 2023 15:38:00 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Herbert Xu" <herbert@gondor.apana.org.au>,
        "Linus Torvalds" <torvalds@linux-foundation.org>,
        "Eric Dumazet" <edumazet@google.com>,
        "Jakub Kicinski" <kuba@kernel.org>
Cc:     "Arnd Bergmann" <arnd@kernel.org>,
        "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
        "Ryan Wanner" <Ryan.Wanner@microchip.com>,
        "Yangtao Li" <frank.li@vivo.com>, linux-kernel@vger.kernel.org,
        "David S . Miller" <davem@davemloft.net>,
        "Sergiu Moga" <sergiu.moga@microchip.com>,
        "Ayush Sawal" <ayush.sawal@chelsio.com>,
        "Gaosheng Cui" <cuigaosheng1@huawei.com>,
        "Claudiu Beznea" <claudiu.beznea@microchip.com>,
        linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org,
        "Kees Cook" <keescook@chromium.org>
Subject: Re: [PATCH 1/2] crypto: drivers - avoid memcpy size warning
Content-Type: text/plain
Precedence: bulk

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