linux-kernel - Re: [PATCH 1/2] crypto: drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <8c3b242f-7d6f-4bec-9a44-61ac65a26637@app.fastmail.com>
Date:   Fri, 11 Aug 2023 15:38:00 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Herbert Xu" <herbert@...dor.apana.org.au>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Eric Dumazet" <edumazet@...gle.com>,
        "Jakub Kicinski" <kuba@...nel.org>
Cc:     "Arnd Bergmann" <arnd@...nel.org>,
        "Alexandre Belloni" <alexandre.belloni@...tlin.com>,
        "Ryan Wanner" <Ryan.Wanner@...rochip.com>,
        "Yangtao Li" <frank.li@...o.com>, linux-kernel@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        "Sergiu Moga" <sergiu.moga@...rochip.com>,
        "Ayush Sawal" <ayush.sawal@...lsio.com>,
        "Gaosheng Cui" <cuigaosheng1@...wei.com>,
        "Claudiu Beznea" <claudiu.beznea@...rochip.com>,
        linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
        "Kees Cook" <keescook@...omium.org>
Subject: Re: [PATCH 1/2] crypto: drivers - avoid memcpy size warning

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