linux.git/crypto/Kconfig, branch v4.20

crypto: user - Disable statistics interface

2018-12-07T05:56:08+00:00

Since this user-space API is still undergoing significant changes,
this patch disables it for the current merge window.

Signed-off-by: Herbert Xu

crypto: x86/aes-ni - remove special handling of AES in PCBC mode

2018-10-05T02:16:56+00:00

For historical reasons, the AES-NI based implementation of the PCBC
chaining mode uses a special FPU chaining mode wrapper template to
amortize the FPU start/stop overhead over multiple blocks.

When this FPU wrapper was introduced, it supported widely used
chaining modes such as XTS and CTR (as well as LRW), but currently,
PCBC is the only remaining user.

Since there are no known users of pcbc(aes) in the kernel, let's remove
this special driver, and rely on the generic pcbc driver to encapsulate
the AES-NI core cipher.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: ofb - add output feedback mode

2018-09-28T04:46:26+00:00

Add a generic version of output feedback mode. We already have support of
several hardware based transformations of this mode and the needed test
vectors but we somehow missed adding a generic software one. Fix this now.

Signed-off-by: Gilad Ben-Yossef 
Signed-off-by: Herbert Xu

crypto: user - Implement a generic crypto statistics

2018-09-28T04:46:25+00:00

This patch implement a generic way to get statistics about all crypto
usages.

Signed-off-by: Corentin Labbe 
Signed-off-by: Herbert Xu

crypto: x86 - remove SHA multibuffer routines and mcryptd

2018-09-04T03:37:04+00:00

As it turns out, the AVX2 multibuffer SHA routines are currently
broken [0], in a way that would have likely been noticed if this
code were in wide use. Since the code is too complicated to be
maintained by anyone except the original authors, and since the
performance benefits for real-world use cases are debatable to
begin with, it is better to drop it entirely for the moment.

[0] https://marc.info/?l=linux-crypto-vger&m=153476243825350&w=2

Suggested-by: Eric Biggers 
Cc: Megha Dey 
Cc: Tim Chen 
Cc: Geert Uytterhoeven 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: speck - remove Speck

2018-09-04T03:35:03+00:00

These are unused, undesired, and have never actually been used by
anybody. The original authors of this code have changed their mind about
its inclusion. While originally proposed for disk encryption on low-end
devices, the idea was discarded [1] in favor of something else before
that could really get going. Therefore, this patch removes Speck.

[1] https://marc.info/?l=linux-crypto-vger&m=153359499015659

Signed-off-by: Jason A. Donenfeld 
Acked-by: Eric Biggers 
Cc: stable@vger.kernel.org
Acked-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: x86/salsa20 - remove x86 salsa20 implementations

2018-05-30T16:13:57+00:00

The x86 assembly implementations of Salsa20 use the frame base pointer
register (%ebp or %rbp), which breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Recent (v4.10+) kernels will warn about this, e.g.

WARNING: kernel stack regs at 00000000a8291e69 in syzkaller047086:4677 has bad 'bp' value 000000001077994c
[...]

But after looking into it, I believe there's very little reason to still
retain the x86 Salsa20 code. First, these are *not* vectorized
(SSE2/SSSE3/AVX2) implementations, which would be needed to get anywhere
close to the best Salsa20 performance on any remotely modern x86
processor; they're just regular x86 assembly. Second, it's still
unclear that anyone is actually using the kernel's Salsa20 at all,
especially given that now ChaCha20 is supported too, and with much more
efficient SSSE3 and AVX2 implementations. Finally, in benchmarks I did
on both Intel and AMD processors with both gcc 8.1.0 and gcc 4.9.4, the
x86_64 salsa20-asm is actually slightly *slower* than salsa20-generic
(~3% slower on Skylake, ~10% slower on Zen), while the i686 salsa20-asm
is only slightly faster than salsa20-generic (~15% faster on Skylake,
~20% faster on Zen). The gcc version made little difference.

So, the x86_64 salsa20-asm is pretty clearly useless. That leaves just
the i686 salsa20-asm, which based on my tests provides a 15-20% speed
boost. But that's without updating the code to not use %ebp. And given
the maintenance cost, the small speed difference vs. salsa20-generic,
the fact that few people still use i686 kernels, the doubt that anyone
is even using the kernel's Salsa20 at all, and the fact that a SSE2
implementation would almost certainly be much faster on any remotely
modern x86 processor yet no one has cared enough to add one yet, I don't
think it's worthwhile to keep.

Thus, just remove both the x86_64 and i686 salsa20-asm implementations.

Reported-by: syzbot+ffa3a158337bbc01ff09@syzkaller.appspotmail.com
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu

crypto: morus - Mark MORUS SIMD glue as x86-specific

2018-05-30T16:13:41+00:00

Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
MORUS") accidetally consiedered the glue code to be usable by different
architectures, but it seems to be only usable on x86.

This patch moves it under arch/x86/crypto and adds 'depends on X86' to
the Kconfig options and also removes the prompt to hide these internal
options from the user.

Reported-by: kbuild test robot 
Signed-off-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu

crypto: x86 - Add optimized MORUS implementations

2018-05-18T16:15:35+00:00

This patch adds optimized implementations of MORUS-640 and MORUS-1280,
utilizing the SSE2 and AVX2 x86 extensions.

For MORUS-1280 (which operates on 256-bit blocks) we provide both AVX2
and SSE2 implementation. Although SSE2 MORUS-1280 is slower than AVX2
MORUS-1280, it is comparable in speed to the SSE2 MORUS-640.

Signed-off-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu

crypto: morus - Add common SIMD glue code for MORUS

2018-05-18T16:15:18+00:00

This patch adds a common glue code for optimized implementations of
MORUS AEAD algorithms.

Signed-off-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu