RE: [PATCHv2] tls: Add support for encryption using async offload accelerator

> -Original Message- > From: Dave Watson [mailto:davejwat...@fb.com] > Sent: Wednesday, January 31, 2018 11:05 PM > To: Vakul Garg > Cc: linux-crypto@vger.kernel.org; il...@mellanox.com; > avia...@mellanox.com; da...@davemloft.net; net...@vger.kernel.org; > Gilad

[PATCH v3 3/4] crypto: aesni - Directly use kmap_atomic instead of scatter_walk object in gcm(aes)

gcmaes_crypt uses a scatter_walk object to map and unmap the crypto request sglists. But the only purpose that appears to serve here is to allow the D-Cache to be flushed at the end for pages that were used as output. However, that is not applicable on x86, so we can avoid using the scatter_walk

[PATCH v3 4/4] crypto: aesni - Use zero-copy for gcm(aes) even if the AAD/Data/AuthTag are separate

Enable the use of zero-copy even if the AAD and/or Auth Tag are in different buffers than the actual data, as long as each of them individually satisfies the zero-copy conditions (i.e. the entire buffer is either in low-mem or within a single high-mem page). Signed-off-by: Junaid Shahid

[PATCH v3 1/4] crypto: aesni - Fix out-of-bounds access of the AAD buffer in AVX gcm-aesni

The AVX/AVX2 versions of gcm-aes encryption/decryption functions can access memory after the end of the AAD buffer if the AAD length is not a multiple of 4 bytes. It didn't matter as long as the AAD and data buffers were always contiguous, since the AVX version are not used for small data sizes

[PATCH v3 2/4] crypto: aesni - Enable one-sided zero copy for gcm(aes) request buffers

gcmaes_encrypt/decrypt perform zero-copy crypto if both the source and destination satisfy certain conditions (single sglist entry located in low-mem or within a single high-mem page). But two copies are done otherwise, even if one of source or destination still satisfies the zero-copy conditions.

[PATCH v3 0/4] crypto: aesni - Use zero-copy for gcm(aes) buffers that are partially contiguous

Changes in v3: - Rebased on top of the latest linux-next Changes in v2: - Integrated https://patchwork.kernel.org/patch/10173981 Currently, the AESNI gcm(aes) implementation uses zero-copy only when the entire src and dest request buffers, including the AAD, the data and the Auth Tag are

Re: [PATCH v2 0/4] crypto: aesni - Use zero-copy for gcm(aes) buffers that are partially contiguous

Hi Steffen, On Wed, Jan 31, 2018 at 12:13 AM, Steffen Klassert wrote: > > I wonder which special usecase you have in mind that will be improved > by your patches. > This is not related to IPsec. We have an internal use case where the data buffer itself is a single

Re: [PATCH v2 2/4] crypto: aesni - Enable one-sided zero copy for gcm(aes) request buffers

Hi Stephan, Sure, I'll rebase and send another revision. Thanks, Junaid

RE: [RFC crypto v3 8/9] chtls: Register the ULP

-Original Message- From: Dave Watson [mailto:davejwat...@fb.com] Sent: Wednesday, January 31, 2018 10:14 PM To: Atul Gupta Cc: s...@queasysnail.net; herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org; ganes...@chelsio.co; net...@vger.kernel.org;

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

On Wed, Jan 31, 2018 at 7:34 PM, Dave Watson wrote: > On 01/31/18 05:22 PM, Vakul Garg wrote: >> > > On second though in stable we should probably just disable async tfm >> > > allocations. >> > > It's simpler. But this approach is still good for -next >> > > >> > > >> > >

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

On 01/31/18 05:22 PM, Vakul Garg wrote: > > > On second though in stable we should probably just disable async tfm > > > allocations. > > > It's simpler. But this approach is still good for -next > > > > > > > > > Gilad > > > > I agree with Gilad, just disable async for now. > > > > How to do

RE: [PATCHv2] tls: Add support for encryption using async offload accelerator

> -Original Message- > From: Dave Watson [mailto:davejwat...@fb.com] > Sent: Wednesday, January 31, 2018 8:52 PM > To: Vakul Garg > Cc: linux-crypto@vger.kernel.org; il...@mellanox.com; > avia...@mellanox.com; da...@davemloft.net; net...@vger.kernel.org; > Gilad

Re: [RFC crypto v3 8/9] chtls: Register the ULP

On 01/31/18 04:14 PM, Atul Gupta wrote: > > > On Tuesday 30 January 2018 10:41 PM, Dave Watson wrote: > > On 01/30/18 06:51 AM, Atul Gupta wrote: > > > > > What I was referring is that passing "tls" ulp type in setsockopt > > > may be insufficient to make the decision when multi HW assist

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

From: Vakul Garg Date: Wed, 31 Jan 2018 21:34:37 +0530 > Async crypto accelerators (e.g. drivers/crypto/caam) support offloading > GCM operation. If they are enabled, crypto_aead_encrypt() return error > code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a >

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

On 01/31/18 09:34 PM, Vakul Garg wrote: > Async crypto accelerators (e.g. drivers/crypto/caam) support offloading > GCM operation. If they are enabled, crypto_aead_encrypt() return error > code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a > completion till the time the

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

On Tue, 30 Jan 2018 15:51:40 + Jonathan Cameron wrote: > On Tue, 30 Jan 2018 09:27:04 +0100 > Stephan Müller wrote: A few clarifications from me after discussions with Stephan this morning. > > > Hi Harsh, > > > > may I as you to try the

Re: [RFC crypto v3 8/9] chtls: Register the ULP

On Tuesday 30 January 2018 10:41 PM, Dave Watson wrote: On 01/30/18 06:51 AM, Atul Gupta wrote: What I was referring is that passing "tls" ulp type in setsockopt may be insufficient to make the decision when multi HW assist Inline TLS solution exists. Setting the ULP doesn't choose HW or SW

[PATCHv2] tls: Add support for encryption using async offload accelerator

Async crypto accelerators (e.g. drivers/crypto/caam) support offloading GCM operation. If they are enabled, crypto_aead_encrypt() return error code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a completion till the time the response for crypto offload request is received.

RE: [PATCH] tls: Add support for encryption using async offload accelerator

Forgot to add 'v2' in subject line. I will be resending. -Original Message- From: Vakul Garg Sent: Wednesday, January 31, 2018 9:29 PM To: linux-crypto@vger.kernel.org Cc: il...@mellanox.com; avia...@mellanox.com; davejwat...@fb.com; da...@davemloft.net; net...@vger.kernel.org; Vakul

[PATCH] tls: Add support for encryption using async offload accelerator

Async crypto accelerators (e.g. drivers/crypto/caam) support offloading GCM operation. If they are enabled, crypto_aead_encrypt() return error code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a completion till the time the response for crypto offload request is received.

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

Hi, I am working on a new Version for this patch addressing all comments, and following all guidelines. Best Regards, Benjamin Warnke

[PATCH] tls: Add support for encryption using async offload accelerator

Async crypto accelerators (e.g. drivers/crypto/caam) support offloading GCM operation. If they are enabled, crypto_aead_encrypt() return error code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a completion till the time the response for crypto offload request is received.

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

On Fri, Jan 26, 2018 at 11:43:28PM +0800, Herbert Xu wrote: > On Thu, Jan 18, 2018 at 09:58:13AM +0100, LABBE Corentin wrote: > > > > I have two way of adding a new netlink request > > - keep the current patch and simply add a new CRYPTO_MSG_GETSTAT which use > > the same function than

Re: [PATCH v2 0/4] crypto: aesni - Use zero-copy for gcm(aes) buffers that are partially contiguous

Hi Junaid. On Tue, Jan 23, 2018 at 12:19:12PM -0800, Junaid Shahid wrote: > Changes in v2: > - Integrated https://patchwork.kernel.org/patch/10173981 > > Currently, the AESNI gcm(aes) implementation uses zero-copy only when the > entire src and dest request buffers, including the AAD, the data