linux-kernel - Re: [PATCH] lib/crypto: arm64/sha512-ce: Drop compatibility macros for older binutils

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: <CAMj1kXEtPo7FfGMfE==DtHT=yk-H1KOdSdsfmKLk=t3gQ2hYEg@mail.gmail.com>
Date: Mon, 21 Jul 2025 14:27:04 +1000
From: Ard Biesheuvel <ardb@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, "Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH] lib/crypto: arm64/sha512-ce: Drop compatibility macros
 for older binutils

On Mon, 21 Jul 2025 at 14:18, Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Mon, Jul 21, 2025 at 01:31:47PM +1000, Ard Biesheuvel wrote:
> > On Sat, 19 Jul 2025 at 08:07, Eric Biggers <ebiggers@...nel.org> wrote:
> > >
> > > Now that the oldest supported binutils version is 2.30, the macros that
> > > emit the SHA-512 instructions as '.inst' words are no longer needed.  So
> > > drop them.  No change in the generated machine code.
> > >
> > > Changed from the original patch by Ard Biesheuvel:
> > > (https://lore.kernel.org/r/20250515142702.2592942-2-ardb+git@google.com):
> > >  - Reduced scope to just SHA-512
> > >  - Added comment that explains why "sha3" is used instead of "sha2"
> > >
> > > Signed-off-by: Eric Biggers <ebiggers@...nel.org>
> >
> > Acked-by: Ard Biesheuvel <ardb@...nel.org>
> >
> > Nit below
> >
> > > ---
> > >
> > > This patch is targeting libcrypto-next
> > >
> > >  lib/crypto/arm64/sha512-ce-core.S | 27 +++++++--------------------
> > >  1 file changed, 7 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/lib/crypto/arm64/sha512-ce-core.S b/lib/crypto/arm64/sha512-ce-core.S
> > > index 7d870a435ea38..eaa485244af52 100644
> > > --- a/lib/crypto/arm64/sha512-ce-core.S
> > > +++ b/lib/crypto/arm64/sha512-ce-core.S
> > > @@ -10,30 +10,17 @@
> > >   */
> > >
> > >  #include <linux/linkage.h>
> > >  #include <asm/assembler.h>
> > >
> > > -       .irp            b,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
> > > -       .set            .Lq\b, \b
> > > -       .set            .Lv\b\().2d, \b
> > > -       .endr
> > > -
> > > -       .macro          sha512h, rd, rn, rm
> > > -       .inst           0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> > > -       .endm
> > > -
> > > -       .macro          sha512h2, rd, rn, rm
> > > -       .inst           0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> > > -       .endm
> > > -
> > > -       .macro          sha512su0, rd, rn
> > > -       .inst           0xcec08000 | .L\rd | (.L\rn << 5)
> > > -       .endm
> > > -
> > > -       .macro          sha512su1, rd, rn, rm
> > > -       .inst           0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> > > -       .endm
> > > +       /*
> > > +        * While SHA-512 is part of the SHA-2 family of algorithms, the
> > > +        * corresponding arm64 instructions are actually part of the "sha3" CPU
> > > +        * feature.  (Except in binutils 2.30 through 2.42, which used "sha2".
> >
> > Nit: the ARM ARM describes these features as FEAT_SHA256, FEAT_SHA512
> > and FEAT_SHA3, and the latter two happen to have appeared in the same
> > architecture revision. So this is likely just the GCC/binutils devs
> > getting confused, and assuming a) that SHA-3 implies SHA-2 (which is
> > silly if you know the difference) and b) SHA512 has anything to do
> > with SHA-3.
>
> How does the following look?
>
>         /*
>          * We have to specify the "sha3" feature here, since the GNU and clang
>          * assemblers both consider the SHA-512 instructions to be part of the
>          * "sha3" feature.  (Except binutils 2.30 through 2.42, which used
>          * "sha2".  But "sha3" implies "sha2", so "sha3" still works in those
>          * versions.)  "sha3" doesn't make a lot of sense, since SHA-512 is part
>          * of the SHA-2 family of algorithms, and also the Arm Architecture
>          * Reference Manual defines FEAT_SHA512 and FEAT_SHA3 separately.
>          * Regardless, we must use "sha3" to be compatible with the assemblers.
>          */
>

LGTM

> By the way, the ARM ARM does actually have the following:
>
>     If FEAT_SHA256 is implemented, then FEAT_SHA1 is implemented.
>     If FEAT_SHA512 is implemented, then FEAT_SHA256 and FEAT_SHA1 are implemented.
>     If FEAT_SHA3 is implemented, then FEAT_SHA256 and FEAT_SHA1 are implemented.
>
> So some of the SHAs do imply other ones.  But notably absent is
> FEAT_SHA3 implying FEAT_SHA512...

Yeah, and such policies usually evaporate into thin air as soon as
Apple decides to implement something different, so they tend to be
rather meaningless. (E.g, FEAT_SME used to imply FEAT_SVE but it no
longer does)