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
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
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
>
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
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
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
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
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
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
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
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
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
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
+++
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
+++
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
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
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
---
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
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
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
+++
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
---
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
+++
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
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
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
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
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()
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
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
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.
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
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
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
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
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
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
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 =
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
On (03/21/18 10:10), Maninder Singh wrote:
> (Added cover letter to avoid much text in patch description)
>
> 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
39 matches
Mail list logo