Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote: > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > > This patch fixes the clang warning of extraneous parentheses, with the > > > following coccinelle script. > > > > > > @@ > > >

Re: [RESEND PATCH] crypto: Add zstd support

> On Mar 30, 2018, at 10:14 AM, Herbert Xu wrote: > > On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote: >> On (03/21/18 15:49), Nick Terrell wrote: >>> depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in >> >> Yikes! How come

[RESEND PATCH] crypto: Add zstd support

Adds zstd support to crypto and scompress. Only supports the default level. Previously we held off on this patch, since there weren't any users. Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in. I also see a patch adding zstd to

Re: [PATCH 1/2] crypto: ccree: remove unused enums

On Mon, Mar 26, 2018 at 08:32:18AM +0100, Gilad Ben-Yossef wrote: > Remove enums definitions unused in the driver code. > > Signed-off-by: Gilad Ben-Yossef Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type

On Sat, Mar 24, 2018 at 12:02:42PM +0100, Stefan Agner wrote: > In the AES cases enum spu_cipher_type and enum hash_type have > the same values, so the assignment is fine. Explicitly cast > the enum type conversion. > > This fixes two warnings when building with clang: >

Re: [PATCH v2 0/9] crypto: don't leak pointers to authenc keys

On Fri, Mar 23, 2018 at 12:42:15PM +0200, Tudor Ambarus wrote: > There are few places in crypto where we save pointers to the > authenc keys to a local variable of type struct crypto_authenc_keys > and we don't zeroize it after use. Fix all those cases and don't > leak pointers to the authenc

Re: [PATCH v1] crypto: Deduplicate le32_to_cpu_array() and cpu_to_le32_array()

On Wed, Mar 21, 2018 at 07:01:40PM +0200, Andy Shevchenko wrote: > Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them > to the generic header. > > No functional change implied. > > Signed-off-by: Andy Shevchenko Patch applied. Thanks. --

Re: [PATCH v2] crypto: talitos - fix IPsec cipher in length

On Thu, Mar 22, 2018 at 10:57:01AM +0100, Christophe Leroy wrote: > For SEC 2.x+, cipher in length must contain only the ciphertext length. > In case of using hardware ICV checking, the ICV length is provided via > the "extent" field of the descriptor pointer. > > Cc: #

Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine

On Tue, Mar 20, 2018 at 09:56:12AM +0200, Horia Geantă wrote: > Add a note that it is perfectly legal to "abandon" a request object: > - call .init() and then (as many times) .update() > - _not_ call any of .final(), .finup() or .export() at any point in > future > > Link:

Re: [PATCH v2 0/9] crypto: inside-secure - hmac(sha256/sha224) support

On Mon, Mar 19, 2018 at 09:21:12AM +0100, Antoine Tenart wrote: > Hi Herbert, > > This series brings hmac(sha256) and hmac(sha224) support to the Inside > Secure cryptographic engine driver. > > The first 7 patches are fixes and reworks needed for the hmac(sha256) > and hmac(224) support to land

Re: [PATCH 1/1] crypto:chelsio - Remove declaration of static function from header

On Mon, Mar 19, 2018 at 07:06:22PM +0530, Harsh Jain wrote: > It fixes compilation warning introduced in commit > > Introduced by commit > > 5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter > gather list") > > Reported-by: Stephen Rothwell >

Re: [PATCH] crypto: rsa - remove unneeded initializations

On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote: > Remove useless assignment of ret to -ENOMEM in rsa_verify. > Remove useless initialization of ret to zero at declaration in > rsa_enc/dec/sign/verify. > > Benefit of the power of undefined values and set ret in branches in >

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote: > Enable CryptoCell support for hardware keys. > > Hardware keys are regular AES keys loaded into CryptoCell internal memory > via firmware, often from secure boot ROM or hardware fuses at boot time. > > As such, they can be used

Re: [PATCH v2 1/9] crypto: authenc - don't leak pointers to authenc keys

On Fri, Mar 23, 2018 at 12:42:16PM +0200, Tudor Ambarus wrote: > In crypto_authenc_setkey we save pointers to the authenc keys in > a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by:

Re: [PATCH] omap-crypto - fix kernel oops and output buffer update

Francis Le Bourse wrote: > Hi Tero, > >> I have a couple of additional comments, but can't add them as the patch >> content is an attachment (like, I would not add the WARN_ON.) Overall, >> the issue you have found is a legitimate problem, and should be fixed. > > I

Re: [RESEND PATCH] crypto: Add zstd support

On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote: > On (03/21/18 15:49), Nick Terrell wrote: > > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in > > Yikes! How come I missed that... :) > > > [0] > >

[PATCH v2] crypto/ecc: Actually remove stack VLA usage

On the quest to remove all VLAs from the kernel[1], this avoids VLAs by just using the maximum allocation size (4 bytes) for stack arrays. All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just make it 4 bytes all the time. Initialization routines are adjusted to check that ndigits

Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition

On Friday, March 03/30/18, 2018 at 00:38:06 +0530, Atul Gupta wrote: > > > On 3/29/2018 9:56 PM, Sabrina Dubroca wrote: > > 2018-03-29, 21:27:50 +0530, Atul Gupta wrote: > > ... > >> +static void chtls_pass_accept_request(struct sock *sk, > >> +struct sk_buff

[v3] crypto: ctr - avoid VLA use

All ciphers implemented in Linux have a block size less than or equal to 16 bytes and the most demanding hw require 16 bytes alignment for the block buffer. We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bytes alignment, unless the architecture supports efficient unaligned accesses. We