Re: [PATCH v2 2/4] crypto: ccp - Enable XTS-AES-128 support on all CCPs

On 7/21/2017 2:04 PM, Gary R Hook wrote: Version 5 CCPs have some new requirements for XTS-AES: the type field must be specified, and the key requires 512 bits, with each part occupying 256 bits and padded with zeroes. This appears to be a fix and not a feature. You need to send this as a

Re: [PATCH v2 3/4] crypto: ccp - Rework the unit-size check for XTS-AES

On 7/21/2017 2:05 PM, Gary R Hook wrote: The CCP supports a limited set of unit-size values. Change the check for this parameter such that acceptable values match the enumeration. Then clarify the conditions under which we must use the fallback implementation. Signed-off-by: Gary R Hook

[RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) device support

AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory contents of a virtual machine to be transparently encrypted with a key unique to the guest VM. The programming and management of the encryption keys are handled by the AMD Secure Processor (AMD-SP), which exposes the commands

[RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support

Platform Security Processor (PSP) is part of AMD Secure Processor (AMD-SP), PSP is a dedicated processor that provides the support for key management commands in a Secure Encrypted Virtualiztion (SEV) mode, along with software-based Tursted Executation Environment (TEE) to enable the third-party

[RFC Part2 PATCH v3 00/26] x86: Secure Encrypted Virtualization (AMD)

This part of Secure Encryted Virtualization (SEV) patch series focuses on KVM changes required to create and manage SEV guests. SEV is an extension to the AMD-V architecture which supports running encrypted virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have their pages

Re: [PATCH v4 0/8] crypto: aes - retire table based generic AES

On 18 July 2017 at 13:06, Ard Biesheuvel wrote: > The generic AES driver uses 16 lookup tables of 1 KB each, and has > encryption and decryption routines that are fully unrolled. Given how > the dependencies between this code and other drivers are declared in > Kconfig

Re: [PATCH v4 0/8] crypto: aes - retire table based generic AES

On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote: > On 18 July 2017 at 13:06, Ard Biesheuvel wrote: > > The generic AES driver uses 16 lookup tables of 1 KB each, and has > > encryption and decryption routines that are fully unrolled. Given how > > the

Re: [PATCH v4 0/8] crypto: aes - retire table based generic AES

On 24 July 2017 at 17:57, Eric Biggers wrote: > On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote: >> On 18 July 2017 at 13:06, Ard Biesheuvel wrote: >> > The generic AES driver uses 16 lookup tables of 1 KB each, and has >> >

Re: [PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine

On Fri, Jul 21, 2017 at 10:01:42PM -0700, Haren Myneni wrote: > > This patch adds P9 NX support for 842 compression engine. Virtual > Accelerator Switchboard (VAS) is used to access 842 engine on P9. > > For each NX engine per chip, setup receive window using > vas_rx_win_open() which configures

Re: FW: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

On Tue, 2017-07-25 at 00:53 +, Dey, Megha wrote: > > -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Wednesday, July 19, 2017 12:02 AM > To: Dey, Megha > Cc: Tim Chen ; da...@davemloft.net; >

Re: FW: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

On Mon, Jul 24, 2017 at 06:09:56PM -0700, Megha Dey wrote: > > Under the skcipher interface, if both the outer and inner alg are async, > there should not be any problem right? Currently I do not see any > existing algorithms have both algorithms async. That's because the purpose of cryptd is to

Re: [bug report] crypto: chcr - Select device in Round Robin fashion

On 20-07-2017 16:02, Dan Carpenter wrote: > Hello Harsh Jain, > > The patch 14c19b178a01: "crypto: chcr - Select device in Round Robin > fashion" from Jun 15, 2017, leads to the following static checker > warning: > > drivers/crypto/chelsio/chcr_core.c:163 chcr_uld_add() > warn:

[PATCH resend 18/18] crypto: arm64/aes - avoid expanded lookup tables in the final round

For the final round, avoid the expanded and padded lookup tables exported by the generic AES driver. Instead, for encryption, we can perform byte loads from the same table we used for the inner rounds, which will still be hot in the caches. For decryption, use the inverse AES Sbox directly, which

[PATCH resend 17/18] crypto: arm/aes - avoid expanded lookup tables in the final round

For the final round, avoid the expanded and padded lookup tables exported by the generic AES driver. Instead, for encryption, we can perform byte loads from the same table we used for the inner rounds, which will still be hot in the caches. For decryption, use the inverse AES Sbox directly, which

[PATCH resend 14/18] crypto: arm64/gcm - implement native driver using v8 Crypto Extensions

Currently, the AES-GCM implementation for arm64 systems that support the ARMv8 Crypto Extensions is based on the generic GCM module, which combines the AES-CTR implementation using AES instructions with the PMULL based GHASH driver. This is suboptimal, given the fact that the input data needs to

[PATCH resend 16/18] crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL

Implement a NEON fallback for systems that do support NEON but have no support for the optional 64x64->128 polynomial multiplication instruction that is part of the ARMv8 Crypto Extensions. It is based on the paper "Fast Software Polynomial Multiplication on ARM Processors Using the NEON Engine"

[PATCH resend 15/18] crypto: arm/ghash - add NEON accelerated fallback for vmull.p64

Implement a NEON fallback for systems that do support NEON but have no support for the optional 64x64->128 polynomial multiplication instruction that is part of the ARMv8 Crypto Extensions. It is based on the paper "Fast Software Polynomial Multiplication on ARM Processors Using the NEON Engine"

[PATCH resend 03/18] crypto: arm64/ghash-ce - add non-SIMD scalar fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar C code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig | 3 +- arch/arm64/crypto/ghash-ce-glue.c | 49

[PATCH resend 09/18] crypto: arm64/aes-ce-cipher: add non-SIMD generic fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig | 1 + arch/arm64/crypto/aes-ce-cipher.c | 20 +---

[PATCH resend 06/18] crypto: arm64/sha1-ce - add non-SIMD generic fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar C code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig| 3 ++- arch/arm64/crypto/sha1-ce-glue.c | 18 ++

[PATCH resend 04/18] crypto: arm64/crct10dif - add non-SIMD generic fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar C code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crct10dif-ce-glue.c | 13 + 1 file changed, 9 insertions(+), 4

[PATCH resend 11/18] crypto: arm64/aes-blk - add a non-SIMD fallback for synchronous CTR

To accommodate systems that may disallow use of the NEON in kernel mode in some circumstances, introduce a C fallback for synchronous AES in CTR mode, and use it if may_use_simd() returns false. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig|

[PATCH resend 12/18] crypto: arm64/chacha20 - take may_use_simd() into account

To accommodate systems that disallow the use of kernel mode NEON in some circumstances, take the return value of may_use_simd into account when deciding whether to invoke the C fallback routine. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/chacha20-neon-glue.c

[PATCH resend 02/18] crypto/algapi - make crypto_xor() take separate dst and src arguments

There are quite a number of occurrences in the kernel of the pattern if (dst != src) memcpy(dst, src, walk.total % AES_BLOCK_SIZE); crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE); or crypto_xor(keystream, src, nbytes); memcpy(dst, keystream, nbytes); where crypto_xor()

[PATCH resend 01/18] crypto/algapi - use separate dst and src operands for __crypto_xor()

In preparation of introducing crypto_xor_cpy(), which will use separate operands for input and output, modify the __crypto_xor() implementation, which it will share with the existing crypto_xor(), which provides the actual functionality when not using the inline version. Signed-off-by: Ard

[PATCH resend 00/18] crypto: ARM/arm64 roundup for v4.14

This is a resend of all the patches I sent out recently that I would like to be considered for v4.14. Their main purpose is to prepare the arm64 crypto code to deal with situations where the SIMD register file is unavailable, which never occurs at present, but this will change in the future when

[PATCH resend 10/18] crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback

The arm64 kernel will shortly disallow nested kernel mode NEON. So honour this in the ARMv8 Crypto Extensions implementation of CCM-AES, and fall back to a scalar implementation using the generic crypto helpers for AES, XOR and incrementing the CTR counter. Signed-off-by: Ard Biesheuvel

[PATCH resend 07/18] crypto: arm64/sha2-ce - add non-SIMD scalar fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/Kconfig| 3 +- arch/arm64/crypto/sha2-ce-glue.c | 30 +---

[PATCH resend 05/18] crypto: arm64/crc32 - add non-SIMD scalar fallback

The arm64 kernel will shortly disallow nested kernel mode NEON, so add a fallback to scalar C code that can be invoked in that case. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crc32-ce-glue.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)

[PATCH resend 08/18] crypto: arm64/aes-ce-cipher - match round key endianness with generic code

In order to be able to reuse the generic AES code as a fallback for situations where the NEON may not be used, update the key handling to match the byte order of the generic code: it stores round keys as sequences of 32-bit quantities rather than streams of bytes, and so our code needs to be

[PATCH v2 0/4] crypto: add driver for Axis ARTPEC crypto accelerator

This series adds a driver for the crypto accelerator in the ARTPEC series of SoCs from Axis Communications AB. Changelog v2: - Use xts_check_key() for xts keys. - Use CRYPTO_ALG_TYPE_SKCIPHER instead of CRYPTO_ALG_TYPE_ABLKCIPHER in cra_flags. Lars Persson (3): dt-bindings: crypto: add

[PATCH resend 13/18] crypto: arm64/aes-bs - implement non-SIMD fallback for AES-CTR

Of the various chaining modes implemented by the bit sliced AES driver, only CTR is exposed as a synchronous cipher, and requires a fallback in order to remain usable once we update the kernel mode NEON handling logic to disallow nested use. So wire up the existing CTR fallback C code.

[PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto

Document the device tree bindings for the ARTPEC crypto accelerator on ARTPEC-6 and ARTPEC-7 SoCs. Signed-off-by: Lars Persson --- .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 1 file changed, 16 insertions(+) create mode 100644

[PATCH v2 4/4] MAINTAINERS: Add ARTPEC crypto maintainer

Assign the Axis kernel team as maintainer for crypto drivers under drivers/crypto/axis. Signed-off-by: Lars Persson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index d5b6c71e783e..72186cf9820d 100644 --- a/MAINTAINERS +++

[PATCH v2 3/4] crypto: axis: add ARTPEC-6/7 crypto accelerator driver

This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson --- drivers/crypto/Kconfig |

[PATCH v2 2/4] crypto: add crypto_(un)register_ahashes()

From: Rabin Vincent There are already helpers to (un)register multiple normal and AEAD algos. Add one for ahashes too. Signed-off-by: Lars Persson --- crypto/ahash.c | 29 + include/crypto/internal/hash.h | 2 ++