linux-kernel - RE: [PATCH v4 6/6] crypto: lib/sha256

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]

Message-ID: <0f039c0c94a64b329d09ae4a18261ba4@AcuMS.aculab.com>
Date:   Mon, 26 Oct 2020 10:06:21 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Arvind Sankar' <nivedita@...m.mit.edu>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        Eric Biggers <ebiggers@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Eric Biggers <ebiggers@...gle.com>
Subject: RE: [PATCH v4 6/6] crypto: lib/sha256 - Unroll LOAD and BLEND loops

From: Arvind Sankar
> Sent: 25 October 2020 23:54
...
> > That's odd, the BLEND loop is about 20 instructions.
> > I wouldn't expect unrolling to help - unless you manage
> > to use 16 registers for the active W[] values.
> >
> 
> I am not sure about what's going on inside the hardware, but even with
> a straightforward assembly version that just reads out of memory the way
> the calculation is specified, unrolling the BLEND loop 8x speeds up the
> performance by 7-8%.
> 
> The compiler is actually pretty bad here, just translating everything
> into assembler with no attempt to optimize anything gets a 10-12%
> speedup over the C version.

I'm not seeing anything particularly stupid.
The loop body (excluding loop control) is 23 instructions.
Doubles to 46 if I unroll once.
Unrolling 4 times does save a couple of instructions per iteration.

The only horrid part of the code is the long dependency
chain at the end when the values get xor'ed together.
gcc is very bad at that, it converts (a + b) + (c + d)
to (((a + b) + c) + d) which takes an extra clock.

Unrolling 4 times gives almost all the gain.
But it really shouldn't be needed at all.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)