[RESEND] SHASH_DESC_ON_STACK macro

Hi Herbert, There is an ongoing effort to remove all VLAs from the code base [1] and while working on that I came across the following macro at include/crypto/hash.h:154: #define SHASH_DESC_ON_STACK(shash, ctx) \ char __##shash##_desc[sizeof(struct

Re: [PATCH 0/3] crypto: inside-secure: improve clock management

Hi Herbert, On sam., mars 24 2018, Herbert Xu wrote: > On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote: >> Hi, >> >> This short series fixes the way the clocks are used for the SafeXcel >> EIP-197 controller embedded in the Marvell Armada 7K/8K

Re: [PATCH v2 net-next 0/6] TLS Rx

From: Dave Watson Date: Thu, 22 Mar 2018 10:09:44 -0700 > TLS tcp socket RX implementation, to match existing TX code. Looks great Dave. Applied, and once my build tests finish I'll push this out to net-next. In some of the new functions, reverse christmas tree ordering of

Re: [PATCH] crypto: cavium: cpt: Replace mdelay with msleep in cpt_device_init

On Sun, Mar 18, 2018 at 10:50:38PM +0800, Jia-Ju Bai wrote: > cpt_device_init() is never called in atomic context. > > The call chain ending up at cpt_device_init() is: > [1] cpt_device_init() <- cpt_probe() > cpt_probe() is only set as ".probe" in pci_driver structure > "cpt_pci_driver". > >

Re: [PATCH] crypto: arm,arm64 - Fix random regeneration of S_shipped

Leonard Crestez wrote: > The decision to rebuild .S_shipped is made based on the relative > timestamps of .S_shipped and .pl files but git makes this essentially > random. This means that the perl script might run anyway (usually at > most once per checkout), defeating

Re: [PATCH] crypto: doc - Document remaining members in struct crypto_alg

On Wed, Mar 14, 2018 at 05:15:52PM -0500, Gary R Hook wrote: > Add missing comments for union members ablkcipher, blkcipher, > cipher, and compress. This silences complaints when building > the htmldocs. > > Fixes: 0d7f488f0305a (crypto: doc - cipher data structures) > Signed-off-by: Gary R Hook

Re: [PATCH 19/47] crypto: remove blackfin CRC driver

On Wed, Mar 14, 2018 at 04:35:32PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so this > driver won't be used any more. > > Signed-off-by: Arnd Bergmann Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2 0/2] Keystone2 HW random generator

On Tue, Mar 13, 2018 at 01:33:29PM -0400, Vitaly Andrianov wrote: > Keyston2 Security Accelerator has a hardware random generator sub-module. > This series adds the driver for the sub-module. > > Changes in v2: > - Changed subject prefix in 1/2 patch > - renamed dts node > > Vitaly Andrianov

Re: [PATCH 0/3] crypto: inside-secure: improve clock management

On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote: > Hi, > > This short series fixes the way the clocks are used for the SafeXcel > EIP-197 controller embedded in the Marvell Armada 7K/8K SoCs. On these > SoCs a second one is needed in order to clock the registers. It was > not

Re: [PATCH -next] crypto: fix missing unlock on error in safexcel_ahash_send_req()

On Tue, Mar 13, 2018 at 02:54:03PM +, Wei Yongjun wrote: > Add the missing unlock before return from function > safexcel_ahash_send_req() in the error handling case. > > Fixes: cff9a17545a3 ("crypto: inside-secure - move cache result dma mapping > to request") > Signed-off-by: Wei Yongjun

Re: [PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

On Mon, Mar 12, 2018 at 02:32:58PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 12 Mar 2018 14:18:23 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

Re: [PATCH v2] crypto: ctr - avoid VLA use

On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote: > > +#define MAX_BLOCKSIZE 16 > + > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > +#define MAX_ALIGNMASK 15 > +#else > +#define MAX_ALIGNMASK 0 > +#endif > + Hmm, this won't work. Just because you have efficient unaligned

Re: [PATCH] X.509: unpack RSA signatureValue field from BIT STRING

On 07.03.2018 18:56, Maciej S. Szmigiero wrote: > On 07.03.2018 16:44, David Howells wrote: >> Maciej S. Szmigiero wrote: >> >>> + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) { >> >> I'm going to change this to '== 0' rather than '!'. > > No problem. I cannot

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

Hi Nick / Sergey, We have compared LZ4 Dyn with Original LZ4 using some samples of realtime application data(4Kb) compressed/decompressed by ZRAM. For comparison we have used lzbench (https://github.com/inikep/lzbench) we have implemented dedicated LZ4 Dyn API & kept last literal length as 6

Re: [PATCH] omap-aes - fix crypto cleanup and IV reporting

Hi Francis, This has similar checkpatch issues + being split into multipart message as your other patch. Also, I think this patch should be split up in two, as there are two issues you are fixing; the bad pointer issue (which I think you only fixed partially, also the in->sgl has similar

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

On 23/03/18 15:50, Tero Kristo wrote: Hi Francis, Your email program is still messing up things, the patch was sent as a multipart message. Use git-send-email tool or something similar if possible. Also, there are at least two checkpatch issues (run scripts/checkpatch.pl -strict ), in

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

Hi Francis, Your email program is still messing up things, the patch was sent as a multipart message. Use git-send-email tool or something similar if possible. Also, there are at least two checkpatch issues (run scripts/checkpatch.pl -strict ), in addition to the UTF-8 formatted message

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

Hi Nick, Thanks for your comments, Please check my reply to few of your comments. I will be sharing benchmarking figures separately. > >> +if (curr_offset > 127) { >> +curr_offset = (curr_offset << 1) | DYN_BIT; >> +

[RFC PATCH v5 2/5] crypto: add zBeWalgo to crypto-api

This patch adds zBeWalgo to the crypto api so that zBeWalgo can be used by zram. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/Kconfig| 12 crypto/Makefile | 1 + crypto/testmgr.c | 10 +++ crypto/testmgr.h

[RFC PATCH v5 0/5] add compression algorithm zBeWalgo

This patch series adds a new compression algorithm to the kernel and to the crypto api. Changes since v4: - Fix mismatching function-prototypes - Fix mismatching license errors - Add static to variables and functions where possible - Add ULL to long constants Changes since v3: - Split patch into

[RFC PATCH v5 4/5] crypto: configurable compression level

Most compression algorithms published by the crypto api are supporting multiple different compression levels. The crypto api currently just calls these algorithms with their default compression level. This patch enables the caller to specify the compression level. Signed-off-by: Benjamin Warnke

[RFC PATCH v5 3/5] crypto: add unsafe decompression to api

Up to Version 3 of this patch the decompressor of zbewalgo did not verify that there is no overflow in the output buffer. Now zbewalgo includes a safe decompressor which does check for buffer overflows and heap-error. ZBewalgo and other Algorithms like lz4 include an unsafe decompressor version,

[RFC PATCH v5 1/5] add compression algorithm zBeWalgo

zBeWalgo is a completely new algorithm - Currently it is not published somewhere else right now, googleing it would not show up any results. The following section describes how the algorithm works. zBeWalgo itself is a container compression algorithm, which can execute multiple different

[RFC PATCH v5 5/5] crypto: add flag for unstable encoding

The data-format of zBeWalgo, and some other algorithms is unstable. To identify such unstable algorithms this patch adds a new flag to the crypto-api. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/zbewalgo.c | 2 +- include/linux/crypto.h | 6 ++ 2 files

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

In qat_alg_aead_init_sessions 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: Tudor Ambarus ---

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

In talitos's aead_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: Tudor Ambarus Reviewed-by: Christophe Leroy

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

In caam's aead_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: Tudor Ambarus --- drivers/crypto/caam/caamalg.c

[PATCH v2 4/9] crypto: caam/qi - don't leak pointers to authenc keys

In caam/qi's aead_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: Tudor Ambarus ---

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

In spacc_aead_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: Tudor Ambarus Reviewed-by: Jamie Iles

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

In chcr_authenc_setkey and chcr_aead_digest_null_setkey we save pointers to the authenc keys in local variables of type struct crypto_authenc_keys and we don't zeroize them after use. Fix this and don't leak pointers to the authenc keys. Signed-off-by: Tudor Ambarus

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

In ixp4xx's aead_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: Tudor Ambarus ---

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

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: Tudor Ambarus --- crypto/authenc.c | 11

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

In crypto_authenc_esn_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: Tudor Ambarus --- crypto/authencesn.c |

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

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 keys. -- Changes in v2: - add commit message on each patch - add Jamie's

Re: [PATCH 2/5 v4] crypto: add zBeWalgo to crypto-api

://github.com/0day-ci/linux/commits/Benjamin-Warnke/add-compression-algorithm-zBeWalgo/20180323-155925 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> lib/zbewalgo/z

[RFC PATCH] crypto: zbewalgo_stat_combination[] can be static

Fixes: 7ba8785b6091 ("crypto: add zBeWalgo to crypto-api") Signed-off-by: Fengguang Wu --- zbewalgo.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/zbewalgo/zbewalgo.c b/lib/zbewalgo/zbewalgo.c index ef922bc2..323dce4 100644

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

On 3/22/2018 12:04 PM, Christophe LEROY wrote: > Le 16/03/2018 à 15:07, Horia Geantă a écrit : >> On 3/16/2018 2:42 PM, Christophe LEROY wrote: >>> Le 16/03/2018 à 09:48, Horia Geantă a écrit : For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using