aboutsummaryrefslogtreecommitdiffstats
path: root/crypto/sha3_generic.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2018-02-08crypto: sha3-generic - Use __optimize to support old compilersGeert Uytterhoeven1-1/+1
With gcc-4.1.2: crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive ignored Use the newly introduced __optimize macro to fix this. Fixes: 83dee2ce1ae791c3 ("crypto: sha3-generic - rewrite KECCAK transform to help the compiler optimize") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-02-08crypto: sha3-generic - deal with oversize stack framesArd Biesheuvel1-100/+118
As reported by kbuild test robot, the optimized SHA3 C implementation compiles to mn10300 code that uses a disproportionate amount of stack space, i.e., crypto/sha3_generic.c: In function 'keccakf': crypto/sha3_generic.c:147:1: warning: the frame size of 1232 bytes is larger than 1024 bytes [-Wframe-larger-than=] As kindly diagnosed by Arnd, this does not only occur when building for the mn10300 architecture (which is what the report was about) but also for h8300, and builds for other 32-bit architectures show an increase in stack space utilization as well. Given that SHA3 operates on 64-bit quantities, and keeps a state matrix of 25 64-bit words, it is not surprising that 32-bit architectures with few general purpose registers are impacted the most by this, and it is therefore reasonable to implement a workaround that distinguishes between 32-bit and 64-bit architectures. Arnd figured out that taking the round calculation out of the loop, and inlining it explicitly but only on 64-bit architectures preserves most of the performance gain achieved by the rewrite, and also gets rid of the excessive use of stack space. Reported-by: kbuild test robot <fengguang.wu@intel.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-26crypto: sha3-generic - export init/update/final routinesArd Biesheuvel1-15/+18
To allow accelerated implementations to fall back to the generic routines, e.g., in contexts where a SIMD based implementation is not allowed to run, expose the generic SHA3 init/update/final routines to other modules. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-26crypto: sha3-generic - simplify codeArd Biesheuvel1-125/+59
In preparation of exposing the generic SHA3 implementation to other versions as a fallback, simplify the code, and remove an inconsistency in the output handling (endian swabbing rsizw words of state before writing the output does not make sense) Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-26crypto: sha3-generic - rewrite KECCAK transform to help the compiler optimizeArd Biesheuvel1-38/+96
The way the KECCAK transform is currently coded involves many references into the state array using indexes that are calculated at runtime using simple but non-trivial arithmetic. This forces the compiler to treat the state matrix as an array in memory rather than keep it in registers, which results in poor performance. So instead, let's rephrase the algorithm using fixed array indexes only. This helps the compiler keep the state matrix in registers, resulting in the following speedup (SHA3-256 performance in cycles per byte): before after speedup Intel Core i7 @ 2.0 GHz (2.9 turbo) 100.6 35.7 2.8x Cortex-A57 @ 2.0 GHz (64-bit mode) 101.6 12.7 8.0x Cortex-A53 @ 1.0 GHz 224.4 15.8 14.2x Cortex-A57 @ 2.0 GHz (32-bit mode) 201.8 63.0 3.2x Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-01-26crypto: sha3-generic - fixes for alignment and big endian operationArd Biesheuvel1-2/+3
Ensure that the input is byte swabbed before injecting it into the SHA3 transform. Use the get_unaligned() accessor for this so that we don't perform unaligned access inadvertently on architectures that do not support that. Cc: <stable@vger.kernel.org> Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-08-08crypto: sha3 - Add missing ULL suffixes for 64-bit constantsGeert Uytterhoeven1-8/+8
On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1): crypto/sha3_generic.c:27: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:28: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:29: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:29: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:31: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:31: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:33: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:33: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:34: warning: integer constant is too large for ‘long’ type crypto/sha3_generic.c:34: warning: integer constant is too large for ‘long’ type Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-06-20crypto: sha3 - Add SHA-3 hash algorithmJeff Garzik1-0/+300
This patch adds the implementation of SHA3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>