[PATCH V7 6/7] crypto: AES vectors for AES CBC multibuffer testing

For more robust testing of AES CBC multibuffer support, additional test vectors have been added to the AES CBC encrypt/decrypt test case. Originally-by: Chandramouli Narayanan Signed-off-by: Megha Dey Acked-by: Tim Chen

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

On Tue, 2017-07-25 at 10:17 +0800, Herbert Xu wrote: > 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

[PATCH V7 7/7] crypto: AES CBC multi-buffer tcrypt

The tcrypt test framework for CBC multi-buffer testing is laid out in this patch. Tcrypt has been extended to validate the functionality and performance of AES CBC multi-buffer support. A new test(mode=600) has been added to test the speed of the multibuffer case, as multi-buffer encrypt will

[PATCH V7 4/7] crypto: AES CBC by8 encryption

This patch introduces the assembly routine to do a by8 AES CBC encryption in support of the AES CBC multi-buffer implementation. It encrypts 8 data streams of the same key size simultaneously. Originally-by: Chandramouli Narayanan Signed-off-by: Megha Dey

[PATCH V7 5/7] crypto: AES CBC multi-buffer glue code

This patch introduces the multi-buffer job manager which is responsible for submitting scatter-gather buffers from several AES CBC jobs to the multi-buffer algorithm. The glue code interfaces with the underlying algorithm that handles 8 data streams of AES CBC encryption in parallel. AES key

[PATCH V7 3/7] crypto: AES CBC multi-buffer scheduler

This patch implements in-order scheduler for encrypting multiple buffers in parallel supporting AES CBC encryption with key sizes of 128, 192 and 256 bits. It uses 8 data lanes by taking advantage of the SIMD instructions with XMM registers. The multibuffer manager and scheduler is mostly written

[PATCH V7 2/7] crypto: AES CBC multi-buffer data structures

This patch introduces the data structures and prototypes of functions needed for doing AES CBC encryption using multi-buffer. Included are the structures of the multi-buffer AES CBC job, job scheduler in C and data structure defines in x86 assembly code. Originally-by: Chandramouli Narayanan

[PATCH V7 1/7] crypto: Multi-buffer encryption infrastructure support

In this patch, the infrastructure needed to support multibuffer encryption implementation is added: a) Enhance mcryptd daemon to support skcipher requests. b) Add multi-buffer mcryptd skcipher helper which presents the top-level algorithm as an skcipher. b) Update configuration to include

[PATCH V7 0/7] crypto: AES CBC multibuffer implementation

In this patch series, we introduce AES CBC encryption that is parallelized on x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data streams in parallel with SIMD instructions. Decryption is handled as in the existing AESNI Intel CBC implementation which can already parallelize

Re: [PATCH v2 3/3] crypto: scompress - defer allocation of scratch buffer to first use

> On 26 Jul 2017, at 00:36, Giovanni Cabiddu wrote: > > Hi Ard, > >> On Fri, Jul 21, 2017 at 04:42:38PM +0100, Ard Biesheuvel wrote: >> +static int crypto_scomp_init_tfm(struct crypto_tfm *tfm) >> +{ >> +int ret; >> + >> +mutex_lock(_lock); >> +ret =

Re: [PATCH v2 3/3] crypto: scompress - defer allocation of scratch buffer to first use

Hi Ard, On Fri, Jul 21, 2017 at 04:42:38PM +0100, Ard Biesheuvel wrote: > +static int crypto_scomp_init_tfm(struct crypto_tfm *tfm) > +{ > + int ret; > + > + mutex_lock(_lock); > + ret = crypto_scomp_alloc_all_scratches(); > + mutex_unlock(_lock); > + > + return ret; > +} If

Re: [PATCH v3 3/4] btrfs: Add zstd support

Hi Nick, On Thu, Jul 20, 2017 at 10:27:42PM +0100, Nick Terrell wrote: > Add zstd compression and decompression support to BtrFS. zstd at its > fastest level compresses almost as well as zlib, while offering much > faster compression and decompression, approaching lzo speeds. Can we look at

Re: [PATCH v3 0/3] Update support for XTS-AES on AMD CCPs

On 07/25/2017 02:21 PM, Hook, Gary wrote: The following series adds support for XS-AES on version 5 CCPs, both 128- and 256-bit, and enhances/clarifies/simplifies some crypto layer code. Herbert: Oops. The last patch in this series depends upon a fix that was sent just prior to this. This

[PATCH v3 0/3] Update support for XTS-AES on AMD CCPs

The following series adds support for XS-AES on version 5 CCPs, both 128- and 256-bit, and enhances/clarifies/simplifies some crypto layer code. Changes since v2: - Move a CCP v5 fix out of this patch series and submit independently - In the unit-size check patch: - Edit comments -

[PATCH v3 1/3] crypto: ccp - Add a call to xts_check_key()

Vet the key using the available standard function Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-aes-xts.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c

[PATCH v3 2/3] crypto: ccp - Rework the unit-size check for XTS-AES

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 ---

[PATCH v3 3/3] crypto: ccp - Add XTS-AES-256 support for CCP version 5

Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-aes-xts.c | 26 ++ drivers/crypto/ccp/ccp-crypto.h |2 +- drivers/crypto/ccp/ccp-ops.c|2 ++ 3 files changed, 25 insertions(+), 5 deletions(-) diff --git

[PATCH] crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

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. cc: # 4.9.x+ Signed-off-by: Gary R Hook ---

Re: Fix dma unmap direction in iMX sahara aes calculation

Hi Mogens, On Sun, Jul 16, 2017 at 6:21 PM, Mogens Lauridsen wrote: > Hi, > > The direction used in dma_unmap_sg in aes calc in sahara.c is wrong. > This result in the cache not being invalidated correct when aes > calculation is done and result is dma'ed to memory. >

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

On 07/25/2017 03:29 AM, Kamil Konieczny wrote: Hi, minor misspelling, On 24.07.2017 22:02, Brijesh Singh wrote: 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

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

On Tue, Jul 25, 2017 at 01:31:52PM +, Horia Geantă wrote: > On 7/25/2017 4:22 PM, Shawn Guo wrote: > > On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote: > >> This patch set adds support for CAAM's legacy Job Ring backend / interface > >> on platforms having DPAA2 (Datapath

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

On 7/25/2017 4:22 PM, Shawn Guo wrote: > On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote: >> This patch set adds support for CAAM's legacy Job Ring backend / interface >> on platforms having DPAA2 (Datapath Acceleration Architecture v2), like >> LS1088A or LS2088A. >> >> I would like

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote: > This patch set adds support for CAAM's legacy Job Ring backend / interface > on platforms having DPAA2 (Datapath Acceleration Architecture v2), like > LS1088A or LS2088A. > > I would like to get the DT patches through the crypto list

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

Hi, minor misspelling, On 24.07.2017 22:02, Brijesh Singh wrote: > 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 >

Re: Poor RNG performance on Ryzen

On Sat, Jul 22, 2017 at 02:16:41PM -0400, Theodore Ts'o wrote: > On Fri, Jul 21, 2017 at 04:55:12PM +0200, Oliver Mangold wrote: > > On 21.07.2017 16:47, Theodore Ts'o wrote: > > > On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote: > > > > Better, but obviously there is still much