linux-kernel - RE: [PATCH] crypto: arm/sha1 - Fix clang function cast warnings

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Dec 2022 15:19:35 +0000
From:   "Elliott, Robert (Servers)" <elliott@....com>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Ard Biesheuvel <ardb@...nel.org>
CC:     kernel test robot <lkp@...el.com>,
        "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
        "oe-kbuild-all@...ts.linux.dev" <oe-kbuild-all@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: RE: [PATCH] crypto: arm/sha1 - Fix clang function cast warnings



> On Thu, Dec 08, 2022 at 07:05:45PM +0100, Ard Biesheuvel wrote:
...
> Instead of casting the function which upsets clang for some reason,
> change the assembly function siganture instead.

Since the assembly function is passed directly to the generic sha1 helper
(sha1_base_do_update) then I agree that is the right approach. The
casts are a clue that something is not quite right.

There are several other arm modules with casts, not just sha1:
    sha1, sha1_neon, sha256, sha256_neon, sha2-ce, sha512, sha512-neon

> -       /* make sure casting to sha1_block_fn() is safe */
> +       /* make sure signature matches sha1_block_fn() */
>         BUILD_BUG_ON(offsetof(struct sha1_state, state) != 0);

I think this wording used by some of the modules provides a better
explanation (e.g. arch/arm/sha512-neon-glue.c):
	* Make sure struct sha512_state begins directly with the SHA512
	* 512-bit internal state, as this is what the asm functions expect.

Most of them only access the first field in the structure, so I'd be
tempted to change the callers to pass the offset of the state subfield
and make the prototypes match that, changing:
	block_fn(sctx, data, blocks);
to
	block_fn(sctx->state, data, blocks);

However, a few of them (e.g., arm64 sha1_neon_ce) do carefully
manipulate the other fields (it's important to not confuse the
caller by doing so), so that's not viable for sha1.