Re: [PATCH v2] crypto: arm/chacha20 - faster 8-bit rotations and other optimizations
On Sat, Sep 01, 2018 at 12:17:07AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Optimize ChaCha20 NEON performance by: > > - Implementing the 8-bit rotations using the 'vtbl.8' instruction. > - Streamlining the part that adds the original state and XORs the data. > - Making some other small tweaks. > > On ARM Cortex-A7, these optimizations improve ChaCha20 performance from > about 12.08 cycles per byte to about 11.37 -- a 5.9% improvement. > > There is a tradeoff involved with the 'vtbl.8' rotation method since > there is at least one CPU (Cortex-A53) where it's not fastest. But it > seems to be a better default; see the added comment. Overall, this > patch reduces Cortex-A53 performance by less than 0.5%. > > Signed-off-by: Eric Biggers > --- > arch/arm/crypto/chacha20-neon-core.S | 277 ++- > 1 file changed, 143 insertions(+), 134 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: arm64/crct10dif - refactor and implement non-Crypto Extension version
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote: > The current arm64 CRC-T10DIF code only runs on cores that implement the > 64x64 bit PMULL instructions that are part of the optional Crypto > Extensions, and falls back to the highly inefficient C code otherwise. > > Let's provide a SIMD version that is twice as fast as the C code even on > a low end core like the Cortex-A53, and is time invariant and much easier > on the D-cache. > > Some performance numbers at the bottom. > > Ard Biesheuvel (2): > crypto: arm64/crct10dif - preparatory refactor for 8x8 PMULL version > crypto: arm64/crct10dif - implement non-Crypto Extensions alternative > > arch/arm64/crypto/crct10dif-ce-core.S | 314 +++- > arch/arm64/crypto/crct10dif-ce-glue.c | 14 +- > 2 files changed, 251 insertions(+), 77 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/3] crypto: Introduce notifier for new crypto algorithms
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote: > Introduce a facility that can be used to receive a notification > callback when a new algorithm becomes available. This can be used by > existing crypto registrations to trigger a switch from a software-only > algorithm to a hardware-accelerated version. > > A new CRYPTO_MSG_ALG_LOADED state is introduced to the existing crypto > notification chain, and the register/unregister functions are exported > so they can be called by subsystems outside of crypto. > > Signed-off-by: Martin K. Petersen > Suggested-by: Herbert Xu > --- > crypto/algapi.c | 2 ++ > crypto/algboss.c| 2 ++ > crypto/internal.h | 8 > include/crypto/algapi.h | 10 ++ > 4 files changed, 14 insertions(+), 8 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 4/4] crypto: arm64/crc32 - remove PMULL based CRC32 driver
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote: > Now that the scalar fallbacks have been moved out of this driver into > the core crc32()/crc32c() routines, we are left with a CRC32 crypto API > driver for arm64 that is based only on 64x64 polynomial multiplication, > which is an optional instruction in the ARMv8 architecture, and is less > and less likely to be available on cores that do not also implement the > CRC32 instructions, given that those are mandatory in the architecture > as of ARMv8.1. > > Since the scalar instructions do not require the special handling that > SIMD instructions do, and since they turn out to be considerably faster > on some cores (Cortex-A53) as well, there is really no point in keeping > this code around so let's just remove it. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector
On Thu, Aug 23, 2018 at 05:48:45PM +0100, Ard Biesheuvel wrote: > Replace the literal load of the addend vector with a sequence that > performs each add individually. This sequence is only 2 instructions > longer than the original, and 2% faster on Cortex-A53. > > This is an improvement by itself, but also works around a Clang issue, > whose integrated assembler does not implement the GNU ARM asm syntax > completely, and does not support the =literal notation for FP registers > (more info at https://bugs.llvm.org/show_bug.cgi?id=38642) > > Cc: Nick Desaulniers > Signed-off-by: Ard Biesheuvel > --- > v2: replace convoluted code involving a SIMD add to increment four BE counters > at once with individual add/rev/mov instructions > > arch/arm64/crypto/aes-modes.S | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/ghash-ce - implement support for 4-way aggregation
On Thu, Aug 23, 2018 at 03:48:51PM +0100, Ard Biesheuvel wrote: > Speed up the GHASH algorithm based on 64-bit polynomial multiplication > by adding support for 4-way aggregation. This improves throughput by > ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte. > > When combined with AES into GCM, throughput improves by ~25%, from > 3.8 cycles per byte to 3.0 cycles per byte. > > Signed-off-by: Ard Biesheuvel > --- > v2: modulo schedule the loads of the input > add AES/GCM performance numbers to commit log > > arch/arm/crypto/Kconfig | 1 + > arch/arm/crypto/ghash-ce-core.S | 108 +++- > arch/arm/crypto/ghash-ce-glue.c | 38 +-- > 3 files changed, 131 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v8 0/9] crypto: Remove VLA usage
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote: > v8 cover letter: > > I continue to hope this can land in v4.19, but I realize that's unlikely. > It would be nice, though, if some of the "trivial" patches could get taken > (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them. > *fingers crossed* > > Series cover letter: > > This is nearly the last of the VLA removals[1], but it's one of the > largest because crypto gets used in lots of places. After looking > through code, usage, reading the threads Gustavo started, and comparing > the use-cases to the other VLA removals that have landed in the kernel, > I think this series is likely the best way forward to shut the door on > VLAs forever. > > For background, the crypto stack usage is for callers to do an immediate > bit of work that doesn't allocate new memory. This means that other VLA > removal techniques (like just using kmalloc) aren't workable, and the > next common technique is needed: examination of maximum stack usage and > the addition of sanity checks. This series does that, and in several > cases, these maximums were already implicit in the code. > > This series is intended to land via the crypto tree for 4.19, though it > touches dm, networking, and a few other things as well, since there are > dependent patches (new crypto #defines being used, etc). I have applied patches 1-4 and 6-8. I'd like to get an ack from the dm folks regarding patch 5. As to patch 9, please fix it so it doesn't rely on the BUG_ON to catch things. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86 - remove SHA multibuffer routines and mcryptd
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote: > 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=153476243825350=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 > --- > MAINTAINERS |8 - > arch/m68k/configs/amiga_defconfig |1 - > arch/m68k/configs/apollo_defconfig|1 - > arch/m68k/configs/atari_defconfig |1 - > arch/m68k/configs/bvme6000_defconfig |1 - > arch/m68k/configs/hp300_defconfig |1 - > arch/m68k/configs/mac_defconfig |1 - > arch/m68k/configs/multi_defconfig |1 - > arch/m68k/configs/mvme147_defconfig |1 - > arch/m68k/configs/mvme16x_defconfig |1 - > arch/m68k/configs/q40_defconfig |1 - > arch/m68k/configs/sun3_defconfig |1 - > arch/m68k/configs/sun3x_defconfig |1 - > arch/s390/configs/debug_defconfig |1 - > arch/s390/configs/performance_defconfig |1 - > arch/x86/crypto/Makefile |3 - > arch/x86/crypto/sha1-mb/Makefile | 14 - > arch/x86/crypto/sha1-mb/sha1_mb.c | 1011 > arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 134 --- > arch/x86/crypto/sha1-mb/sha1_mb_mgr.h | 110 -- > .../crypto/sha1-mb/sha1_mb_mgr_datastruct.S | 287 - > .../crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 304 - > .../crypto/sha1-mb/sha1_mb_mgr_init_avx2.c| 64 - > .../crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S | 209 > arch/x86/crypto/sha1-mb/sha1_x8_avx2.S| 492 > arch/x86/crypto/sha256-mb/Makefile| 14 - > arch/x86/crypto/sha256-mb/sha256_mb.c | 1013 > arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 134 --- > arch/x86/crypto/sha256-mb/sha256_mb_mgr.h | 108 -- > .../sha256-mb/sha256_mb_mgr_datastruct.S | 304 - > .../sha256-mb/sha256_mb_mgr_flush_avx2.S | 307 - > .../sha256-mb/sha256_mb_mgr_init_avx2.c | 65 - > .../sha256-mb/sha256_mb_mgr_submit_avx2.S | 214 > arch/x86/crypto/sha256-mb/sha256_x8_avx2.S| 598 -- > arch/x86/crypto/sha512-mb/Makefile| 12 - > arch/x86/crypto/sha512-mb/sha512_mb.c | 1047 - > arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 128 -- > arch/x86/crypto/sha512-mb/sha512_mb_mgr.h | 104 -- > .../sha512-mb/sha512_mb_mgr_datastruct.S | 281 - > .../sha512-mb/sha512_mb_mgr_flush_avx2.S | 297 - > .../sha512-mb/sha512_mb_mgr_init_avx2.c | 69 -- > .../sha512-mb/sha512_mb_mgr_submit_avx2.S | 224 > arch/x86/crypto/sha512-mb/sha512_x4_avx2.S| 531 - > crypto/Kconfig| 62 - > crypto/Makefile |1 - > crypto/mcryptd.c | 675 --- > include/crypto/mcryptd.h | 114 -- > 47 files changed, 8952 deletions(-) > delete mode 100644 arch/x86/crypto/sha1-mb/Makefile > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb.c > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_ctx.h > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr.h > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_datastruct.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_init_avx2.c > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_x8_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/Makefile > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb.c > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_ctx.h > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr.h > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_datastruct.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_init_avx2.c > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S > delete mode 100644 arch/x86/crypto/sha512-mb/Makefile > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb.c > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
Re: [PATCH crypto-2.6] crypto: ccp: add timeout support in the SEV command
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote: > Currently, the CCP driver assumes that the SEV command issued to the PSP > will always return (i.e. it will never hang). But recently, firmware bugs > have shown that a command can hang. Since of the SEV commands are used > in probe routines, this can cause boot hangs and/or loss of virtualization > capabilities. > > To protect against firmware bugs, add a timeout in the SEV command > execution flow. If a command does not complete within the specified > timeout then return -ETIMEOUT and stop the driver from executing any > further commands since the state of the SEV firmware is unknown. > > Cc: Tom Lendacky > Cc: Gary Hook > Cc: Herbert Xu > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Brijesh Singh > --- > drivers/crypto/ccp/psp-dev.c | 46 > +++- > 1 file changed, 41 insertions(+), 5 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel - switch to SPDX license identifiers
On Tue, Aug 21, 2018 at 04:36:09PM +0300, Tudor Ambarus wrote: > Adopt the SPDX license identifiers to ease license compliance > management. > > Signed-off-by: Tudor Ambarus > --- > drivers/crypto/atmel-aes.c | 5 + > drivers/crypto/atmel-authenc.h | 13 + > drivers/crypto/atmel-ecc.c | 11 +-- > drivers/crypto/atmel-ecc.h | 14 +- > drivers/crypto/atmel-sha.c | 5 + > drivers/crypto/atmel-tdes.c| 5 + > 6 files changed, 6 insertions(+), 47 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: remove Speck
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote: > 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=153359499015659 > > Signed-off-by: Jason A. Donenfeld > Acked-by: Eric Biggers > Cc: sta...@vger.kernel.org > --- > Documentation/filesystems/fscrypt.rst | 10 - > arch/arm/crypto/Kconfig | 6 - > arch/arm/crypto/Makefile | 2 - > arch/arm/crypto/speck-neon-core.S | 434 --- > arch/arm/crypto/speck-neon-glue.c | 288 -- > arch/arm64/crypto/Kconfig | 6 - > arch/arm64/crypto/Makefile| 3 - > arch/arm64/crypto/speck-neon-core.S | 352 > arch/arm64/crypto/speck-neon-glue.c | 282 -- > arch/m68k/configs/amiga_defconfig | 1 - > arch/m68k/configs/apollo_defconfig| 1 - > arch/m68k/configs/atari_defconfig | 1 - > arch/m68k/configs/bvme6000_defconfig | 1 - > arch/m68k/configs/hp300_defconfig | 1 - > arch/m68k/configs/mac_defconfig | 1 - > arch/m68k/configs/multi_defconfig | 1 - > arch/m68k/configs/mvme147_defconfig | 1 - > arch/m68k/configs/mvme16x_defconfig | 1 - > arch/m68k/configs/q40_defconfig | 1 - > arch/m68k/configs/sun3_defconfig | 1 - > arch/m68k/configs/sun3x_defconfig | 1 - > arch/s390/defconfig | 1 - > crypto/Kconfig| 14 - > crypto/Makefile | 1 - > crypto/speck.c| 307 --- > crypto/testmgr.c | 24 - > crypto/testmgr.h | 738 -- > fs/crypto/fscrypt_private.h | 4 - > fs/crypto/keyinfo.c | 10 - > include/crypto/speck.h| 62 --- > include/uapi/linux/fs.h | 4 +- > 31 files changed, 2 insertions(+), 2558 deletions(-) > delete mode 100644 arch/arm/crypto/speck-neon-core.S > delete mode 100644 arch/arm/crypto/speck-neon-glue.c > delete mode 100644 arch/arm64/crypto/speck-neon-core.S > delete mode 100644 arch/arm64/crypto/speck-neon-glue.c > delete mode 100644 crypto/speck.c > delete mode 100644 include/crypto/speck.h Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: caam - ablkcipher -> skcipher conversion
On Mon, Aug 06, 2018 at 03:43:56PM +0300, Horia Geantă wrote: > This patch set converts caam/jr and caam/qi top level drivers > from ablkcipher API to skcipher. > > First two patches remove the unused ablkcipher algorithms with > support for IV generation. > The following two patches deal with the conversion. > > Note: There is a dependency for the patch set - a fix sent separately: > "crypto: caam/qi - fix error path in xts setkey" > https://patchwork.kernel.org/patch/10557015 > > Horia Geantă (4): > crypto: caam/jr - remove ablkcipher IV generation > crypto: caam/qi - remove ablkcipher IV generation > crypto: caam/jr - ablkcipher -> skcipher conversion > crypto: caam/qi - ablkcipher -> skcipher conversion > > drivers/crypto/caam/caamalg.c | 729 > +++-- > drivers/crypto/caam/caamalg_desc.c | 142 ++-- > drivers/crypto/caam/caamalg_desc.h | 28 +- > drivers/crypto/caam/caamalg_qi.c | 626 ++- > drivers/crypto/caam/compat.h | 1 + > drivers/crypto/caam/qi.h | 1 - > 6 files changed, 449 insertions(+), 1078 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: correct obvious misspelling "cypto-controller"
On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
Adding Rob Herring to the cc list.
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> index 5e2ba385b8c9..53e39d5f94e7 100644
> --- a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> +++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> @@ -16,7 +16,7 @@ Required properties:
>
> Examples:
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0xff8a 0x4000>;
> interrupts = ;
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index d7e49d29ace5..dcfdb2c0d206 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -942,7 +942,7 @@
> status = "disabled";
> };
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0x0 0xff8a 0x0 0x4000>;
> interrupts = ;
>
> rday
>
> --
>
>
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca/dokuwiki
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
>
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
