Re: [RFC crypto v3 0/9] Chelsio Inline TLS

On Monday 22 January 2018 03:46 AM, Sabrina Dubroca wrote: 2017-12-20, 17:03:02 +0530, Atul Gupta wrote: RFC series for Chelsio Inline TLS driver (chtls.ko) Driver use the ULP infrastructure to register chtls as Inline TLS ULP. I don't think drivers should be registering their own ULP. TLS

Re: [PATCH -next] hwrng: make symbol imx_rngc_pm_ops static

Thus wrote Wei Yongjun (weiyongj...@huawei.com): > Fixes the following sparse warnings: > drivers/char/hw_random/imx-rngc.c:303:1: warning: > symbol 'imx_rngc_pm_ops' was not declared. Should it be static? > Signed-off-by: Wei Yongjun > --- >

Re: [PATCH] crypto: AF_ALG - inline IV support

On 21-01-2018 17:44, Stephan Müller wrote: > Hi Herbert, > > I tried to summarize the use cases of the AIO support at [1]. > > The use case covering the inline IV support is documented in section [2]. It > naturally would depend on this patch to be accepted. What is your take on > this > use

[PATCH v2 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 v2 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 v2 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 v2 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 v2 0/4] crypto: aesni - Use zero-copy for gcm(aes) buffers that are partially contiguous

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 contiguous. This series enables the use of zero-copy even if the

[PATCH] sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64

This patch fixes the typo CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64 Fixes: 81658ad0d923 ("sparc64: Add CAMELLIA driver making use of the new camellia opcodes.") Signed-off-by: Corentin Labbe --- arch/sparc/crypto/Makefile | 2 +- 1 file changed, 1