Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Hi Philippe, > Am 20.03.2018 um 17:30 schrieb Philippe Ombredanne : > > Hi Benjamin, > > On Tue, Mar 20, 2018 at 7:04 AM, Benjamin Warnke > <4bwar...@informatik.uni-hamburg.de> wrote: >> zBeWalgo is a completely new algorithm - Currently it is not published >> somewhere else right now, googlein

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

On (03/21/18 10:10), Maninder Singh wrote: [..] > +static struct crypto_alg alg_lz4_dyn = { > + .cra_name = "lz4_dyn", > + .cra_flags = CRYPTO_ALG_TYPE_COMPRESS, > + .cra_ctxsize= sizeof(struct lz4_ctx), > + .cra_module = THIS_MODUL

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

CC-ing Nick Nick, can you take a look? Message-IDs: lkml.kernel.org/r/1521607242-3968-1-git-send-email-maninder...@samsung.com lkml.kernel.org/r/1521607242-3968-2-git-send-email-maninder...@samsung.com -ss

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

Hi, Antoine, On 02/23/2018 02:37 PM, Antoine Tenart wrote: Hi Tudor, On Fri, Feb 23, 2018 at 02:04:33PM +0200, Tudor Ambarus wrote: There are few other places in crypto where we extract the authenc keys in the same type of local variable, struct crypto_authenc_keys keys, and we don't zeroize

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

Hi Tudor, On Wed, Mar 21, 2018 at 03:15:27PM +0200, Tudor Ambarus wrote: > On 02/23/2018 02:37 PM, Antoine Tenart wrote: > > On Fri, Feb 23, 2018 at 02:04:33PM +0200, Tudor Ambarus wrote: > > > > > > There are few other places in crypto where we extract the authenc keys > > > in the same type of

Re: [PATCH net-next 5/6] tls: RX path for ktls

On 03/21/18 07:20 AM, Boris Pismenny wrote: > > > On 3/20/2018 7:54 PM, Dave Watson wrote: > > + ctx->control = header[0]; > > + > > + data_len = ((header[4] & 0xFF) | (header[3] << 8)); > > + > > + cipher_overhead = tls_ctx->rx.tag_size + tls_ctx->rx.iv_size; > > + > > + if (data_len > T

[RFC] 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 shash_desc

[PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers

This is v13 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

[PATCH v13 04/10] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by: Michael Ellerman Rev

[PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe

The semantics of the iowriteXXbe() functions are to write a value in CPU endianess to an IO register that is known by the caller to be in Big Endian. The mmio_writeXXbe() macro, which is called by iowriteXXbe(), should therefore use cpu_to_beXX() instead of beXX_to_cpu(). Seeing both beXX_to_cpu()

[PATCH v13 03/10] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan Gun

[PATCH v13 05/10] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions. Signed-off-b

[PATCH v13 07/10] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are enco

[PATCH v13 10/10] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switc

[PATCH v13 02/10] iomap: Fix sparse endian check warnings

Newer version of sparse produce a few warnings of the form: lib/iomap.c:84:9: warning: cast to restricted __be16 when run with: make C=2 CF=-D__CHECK_ENDIAN__ (The kbuild robot has recently started running such checks) The warning is not valid because the __raw_readX() and __raw_writeX() funct

[PATCH v13 08/10] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang Acked-by: Allen Hubbe Acked-by: Jon Mason --- drivers/ntb/hw/

[PATCH v13 06/10] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq a

[PATCH v13 09/10] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

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

Signed-off-by: Tudor Ambarus --- crypto/authenc.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/crypto/authenc.c b/crypto/authenc.c index d3d6d72..480a08b 100644 --- a/crypto/authenc.c +++ b/crypto/authenc.c @@ -87,8 +87,10 @@ static int crypto_authenc_setkey(str

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/chelsio/chcr_algo.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c index 4617c7a..91bc77a 100644 --- a/drivers/crypto/chelsio/chcr_algo.c +++ b/drivers/crypto/chelsio

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/caam/caamalg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c index 584a6c1..7207a53 100644 --- a/drivers/crypto/caam/caamalg.c +++ b/drivers/crypto/caam/caamalg.c @@ -570,9 +570,1

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/caam/caamalg_qi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c index c2b5762..cacda08 100644 --- a/drivers/crypto/caam/caamalg_qi.c +++ b/drivers/crypto/caam/caamalg_qi.c @

[PATCH 0/9] 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. Tudor Ambarus (9): crypto: authenc - don't leak pointers to authenc

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/qat/qat_common/qat_algs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c index baffae8..1138e41 100644 --- a/drivers/crypto/qat/qat_common/qat_algs.c +++ b/

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

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 --- crypto/md4.c | 17 - crypto/md5.c | 17 - include/linux/byteor

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/picoxcell_crypto.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c index 4ef52c9..a4df966 100644 --- a/drivers/crypto/picoxcell_crypto.c +++ b/drivers/crypto/picoxcell_cryp

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

Signed-off-by: Tudor Ambarus --- crypto/authencesn.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/crypto/authencesn.c b/crypto/authencesn.c index 15f91dd..3bed6d1 100644 --- a/crypto/authencesn.c +++ b/crypto/authencesn.c @@ -69,8 +69,10 @@ static int crypto_aut

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/talitos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 447cb8b..c92efc7 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -904,10 +904,12 @@ static int aead_set

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

Signed-off-by: Tudor Ambarus --- drivers/crypto/ixp4xx_crypto.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c index 717a266..27f7dad 100644 --- a/drivers/crypto/ixp4xx_crypto.c +++ b/drivers/crypto/ixp4xx_crypto.c @@ -1167,9

Re: [PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe

On Wed, Mar 21, 2018 at 10:37:36AM -0600, Logan Gunthorpe wrote: > The semantics of the iowriteXXbe() functions are to write a > value in CPU endianess to an IO register that is known by the > caller to be in Big Endian. The mmio_writeXXbe() macro, which > is called by iowriteXXbe(), should therefo

Re: [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers

On Wed, Mar 21, 2018 at 6:37 PM, Logan Gunthorpe wrote: > > This is v13 of my cleanup series to push a number of instances of people > defining their own io{read|write}64 functions into common headers seing > they don't exist in non-64bit systems. This series adds inline functions to > the > io-6

Re: [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers

On 21/03/18 11:40 AM, Andy Shevchenko wrote: > The first patches that I didn't reviewed before makes sense to me, the > rest (at the end) FWIW, > > Reviewed-by: Andy Shevchenko Great, thanks! Logan

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

On (03/21/18 10:10), Maninder Singh wrote: > LZ4 specification defines 2 byte offset length for 64 KB data. > But in case of ZRAM we compress data per page and in most of > architecture PAGE_SIZE is 4KB. So we can decide offset length based > on actual offset value. For this we can reserve 1 bit to

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

On (03/21/18 10:10), Maninder Singh wrote: > diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c > index cc7b6d4..185c358 100644 > --- a/lib/lz4/lz4_compress.c > +++ b/lib/lz4/lz4_compress.c > @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic( > const tableType_t table

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Benjamin, On Wed, Mar 21, 2018 at 12:32 AM, Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> wrote: > Ok, I will use > > /* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (c) 2018 Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> > ... > > at the top of my files instead of that boi

Re: [PATCH v6 05/12] integrity: Introduce integrity_keyring_from_id()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will need to obtain the keyring used to verify file signatures so that > it can verify the module-style signature appended to files. > > Signed-off-by: Thiago Jung Bauermann Signed-off-by: Mimi Zohar > --- > security/integr

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

Re: [PATCH v6 06/12] integrity: Introduce asymmetric_sig_has_known_key()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will only look for a modsig if the xattr sig references a key which is > not in the expected kernel keyring. To that end, introduce > asymmetric_sig_has_known_key(). > > The logic of extracting the key used in the xattr sig is f

Re: [PATCH v6 07/12] integrity: Select CONFIG_KEYS instead of depending on it

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > This avoids a dependency cycle in CONFIG_IMA_APPRAISE_MODSIG (introduced by > a later patch in this series): it will select CONFIG_MODULE_SIG_FORMAT > which in turn selects CONFIG_KEYS. Kconfig then complains that > CONFIG_INTEGRITY_

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

On (03/21/18 19:56), Nick Terrell wrote: [..] > This seems like a reasonable extension to the algorithm, and it looks like > LZ4_DYN is about a 5% improvement to compression ratio on your benchmark. > The biggest question I have is if it is worthwhile to maintain a separate > incompatible variant o

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

CC: Vaneet Narang.   On (03/21/18 10:10), Maninder Singh wrote: > diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c > index cc7b6d4..185c358 100644 > --- a/lib/lz4/lz4_compress.c > +++ b/lib/lz4/lz4_compress.c > @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic( >

Re: [RESEND PATCH] crypto: Add zstd support

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] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com Signed-off-by: Nick Terrell ?

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Hi Philippe, > Actually to be consistent if you want to use GPL-2-0 (and not "or > later") you should use: > > 1. at the top, for a c. file: > // SPDX-License-Identifier: GPL-2.0 > > or for a .h file: > /* SPDX-License-Identifier: GPL-2.0 */ > > The doc explains it all. Including the comment st