> 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.
