Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

2018-04-13 Thread Fabio Estevam 
Hi Horia,

On Fri, Apr 13, 2018 at 3:18 AM, Horia Geantă  wrote:

> Stripping should happen before set_rsa_pub_pdb() is called since the Protocol
> Data Block contains the input length that is used by the accelerator:
> pdb->f_len = req->src_len;
>
> It should probably be moved at the top of rsa_edesc_alloc().

That did the trick, thanks!

> Ideally stripping would avoid copying data (and memory allocation for 
> temporary
> buffers).

I will try to optimize this aspect and will post a proper patch.

Martin,

Before I try to optimize it, I would like to share the patch
(generated against linux-next) so that you can try it in your IMA
usecase:
http://code.bulix.org/n77z3e-318473

Does it work for you?

Thanks

Re: [PATCH 2/2] ARM: bcm283x: Add missing interrupt for RNG block

2018-04-13 Thread Florian Fainelli 
On Sat, 18 Nov 2017 14:04:13 +0100, Stefan Wahren  
wrote:
> This patch adds the missing interrupt property to the RNG block
> of BCM283x.
> 
> Link: https://github.com/raspberrypi/linux/issues/2195
> CC: Florian Fainelli 
> Signed-off-by: Stefan Wahren 
> ---

Applied to devicetree/next, thanks!
--
Florian

Re: [PATCH 1/2] dt-binding: rng: Add interrupt property for BCM2835

2018-04-13 Thread Florian Fainelli 
On 11/18/2017 05:04 AM, Stefan Wahren wrote:
> As Sylvain Garrigues pointed out the BCM2835 RNG block has an
> interrupt. Also in preparation for Florian's upcoming patch series
> add this property to the binding. While we are at it fix the
> indenting of the example.
> 
> Link: https://github.com/raspberrypi/linux/issues/2195
> CC: Florian Fainelli 
> Signed-off-by: Stefan Wahren 

Applied to devicetree/next, thanks!
-- 
Florian

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

2018-04-13 Thread Benjamin Warnke 
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   | 134 
 crypto/zbewalgo.c  | 164 +
 drivers/block/zram/zcomp.c |   3 +
 6 files changed, 324 insertions(+)
 create mode 100644 crypto/zbewalgo.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 76e8c88c..749457a6 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1686,6 +1686,18 @@ config CRYPTO_LZ4
help
  This is the LZ4 algorithm.
 
+config CRYPTO_ZBEWALGO
+   tristate "zBeWalgo compression algorithm"
+   select CRYPTO_ALGAPI
+   select CRYPTO_ACOMP2
+   select ZBEWALGO_COMPRESS
+   help
+ This is the zBeWalgo compression algorithm. This algorithm
+ accepts only input sizes of at most one page at once.
+ To achieve high compression ratios zbewalgo can call multiple
+ transformation and compression algorithms in a row to optimize
+ the compressed size.
+
 config CRYPTO_LZ4HC
tristate "LZ4HC compression algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 4fc69fe9..493cbd65 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -124,6 +124,7 @@ obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif_common.o 
crct10dif_generic.o
 obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
 obj-$(CONFIG_CRYPTO_LZO) += lzo.o
 obj-$(CONFIG_CRYPTO_LZ4) += lz4.o
+obj-$(CONFIG_CRYPTO_ZBEWALGO) += zbewalgo.o
 obj-$(CONFIG_CRYPTO_LZ4HC) += lz4hc.o
 obj-$(CONFIG_CRYPTO_842) += 842.o
 obj-$(CONFIG_CRYPTO_RNG2) += rng.o
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index af4a01c5..53fd43d1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3611,6 +3611,16 @@ static const struct alg_test_desc alg_test_descs[] = {
.dec = __VECS(tf_xts_dec_tv_template)
}
}
+   }, {
+   .alg = "zbewalgo",
+   .test = alg_test_comp,
+   .fips_allowed = 1,
+   .suite = {
+   .comp = {
+   .comp = __VECS(zbewalgo_comp_tv_template),
+   .decomp = __VECS(zbewalgo_decomp_tv_template)
+   }
+   }
}, {
.alg = "zlib-deflate",
.test = alg_test_comp,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 004c0a0f..960bfbcf 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -37009,6 +37009,140 @@ static const struct hash_testvec 
bfin_crc_tv_template[] = {
 
 };
 
+static const struct comp_testvec zbewalgo_comp_tv_template[] = {
+   {
+   .inlen  = 512,
+   .outlen = 402,
+   .input  =
+   
"\x8a\x3a\xf3\xbe\x33\xf9\xab\x3d\xa1\x51\x9f\x7f\xad\xf6\xab\x3d"
+   
"\xad\x29\x8f\x3c\x27\xf4\xab\x3d\x06\x19\xc3\xf5\xa0\xf1\xab\x3d"
+   
"\xfb\x75\x3b\xab\x1a\xef\xab\x3d\xe3\x96\xf8\x5c\x94\xec\xab\x3d"
+   
"\x13\xd2\xfa\x0a\x0e\xea\xab\x3d\xe0\x7d\x42\xb5\x87\xe7\xab\x3d"
+   
"\xa1\xf0\xcf\x5b\x01\xe5\xab\x3d\xad\x80\xa3\xfe\x7a\xe2\xab\x3d"
+   
"\x59\x84\xbd\x9d\xf4\xdf\xab\x3d\xff\x51\x1e\x39\x6e\xdd\xab\x3d"
+   
"\xf5\x3f\xc6\xd0\xe7\xda\xab\x3d\x96\xa4\xb5\x64\x61\xd8\xab\x3d"
+   
"\x3b\xd6\xec\xf4\xda\xd5\xab\x3d\x3b\x2b\x6c\x81\x54\xd3\xab\x3d"
+   
"\xf2\xf9\x33\x0a\xce\xd0\xab\x3d\xbb\x98\x44\x8f\x47\xce\xab\x3d"
+   
"\xed\x5d\x9e\x10\xc1\xcb\xab\x3d\xe7\x9f\x41\x8e\x3a\xc9\xab\x3d"
+   
"\x07\xb5\x2e\x08\xb4\xc6\xab\x3d\xa9\xf3\x65\x7e\x2d\xc4\xab\x3d"
+   
"\x28\xb2\xe7\xf0\xa6\xc1\xab\x3d\xe3\x46\xb4\x5f\x20\xbf\xab\x3d"
+   
"\x38\x08\xcc\xca\x99\xbc\xab\x3d\x85\x4c\x2f\x32\x13\xba\xab\x3d"
+   
"\x2a\x6a\xde\x95\x8c\xb7\xab\x3d\x85\xb7\xd9\xf5\x05\xb5\xab\x3d"
+   
"\xf7\x8a\x21\x52\x7f\xb2\xab\x3d\xe2\x3a\xb6\xaa\xf8\xaf\xab\x3d"
+   
"\xa5\x1d\x98\xff\x71\xad\xab\x3d\xa3\x89\xc7\x50\xeb\xaa\xab\x3d"
+   
"\x3d\xd5\x44\x9e\x64\xa8\xab\x3d\xd6\x56\x10\xe8\xdd\xa5\xab\x3d"
+   
"\xce\x64\x2a\x2e\x57\xa3\xab\x3d\x8d\x55\x93\x70\xd0\xa0\xab\x3d"
+   
"\x76\x7f\x4b\xaf\x49\x9e\xab\x3d\xeb\x38\x53\xea\xc2\x9b\xab\x3d"
+   
"\x53\xd8\xaa\x21\x3c\x99\xab\x3d\x13\xb4\x52\x55\xb5\x96\xab\x3d"
+   
"\x92\x22\x4b\x85\x2e\x94\xab\x3d\x35\x7a\x94\xb1\xa7\x91\xab\x3d"
+

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

2018-04-13 Thread Benjamin Warnke 
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,
which is a bit faster, but does no error checking. These unsafe decompressors
can be applied when the datasource and the whole datapath is trusted.

This patch publishes these existing functions in the crypto-api

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 crypto/842.c |  3 ++-
 crypto/compress.c| 10 ++
 crypto/crypto_null.c |  3 ++-
 crypto/deflate.c |  3 ++-
 crypto/lz4.c | 23 ++-
 crypto/lz4hc.c   | 23 ++-
 crypto/lzo.c |  3 ++-
 crypto/testmgr.c | 27 ++-
 crypto/zbewalgo.c| 29 -
 drivers/block/zram/zram_drv.c| 34 +-
 drivers/block/zram/zram_drv.h|  1 +
 drivers/crypto/cavium/zip/zip_main.c |  6 --
 drivers/crypto/nx/nx-842-powernv.c   |  3 ++-
 drivers/crypto/nx/nx-842-pseries.c   |  3 ++-
 include/linux/crypto.h   | 16 
 15 files changed, 174 insertions(+), 13 deletions(-)

diff --git a/crypto/842.c b/crypto/842.c
index bc26dc94..7e74ea26 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -112,7 +112,8 @@ static struct crypto_alg alg = {
.cra_exit   = crypto842_exit,
.cra_u  = { .compress = {
.coa_compress   = crypto842_compress,
-   .coa_decompress = crypto842_decompress } }
+   .coa_decompress = crypto842_decompress,
+   .coa_decompress_unsafe  = crypto842_decompress } }
 };
 
 static struct scomp_alg scomp = {
diff --git a/crypto/compress.c b/crypto/compress.c
index f2d52292..bec79624 100644
--- a/crypto/compress.c
+++ b/crypto/compress.c
@@ -33,12 +33,22 @@ static int crypto_decompress(struct crypto_tfm *tfm,
   dlen);
 }
 
+static int crypto_decompress_unsafe(struct crypto_tfm *tfm,
+   const u8 *src, unsigned int slen,
+u8 *dst, unsigned int *dlen)
+{
+   return tfm->__crt_alg->cra_compress.coa_decompress_unsafe(tfm, src,
+ slen, dst,
+ dlen);
+}
+
 int crypto_init_compress_ops(struct crypto_tfm *tfm)
 {
struct compress_tfm *ops = >crt_compress;
 
ops->cot_compress = crypto_compress;
ops->cot_decompress = crypto_decompress;
+   ops->cot_decompress_unsafe = crypto_decompress_unsafe;
 
return 0;
 }
diff --git a/crypto/crypto_null.c b/crypto/crypto_null.c
index 20ff2c74..6e15e8c0 100644
--- a/crypto/crypto_null.c
+++ b/crypto/crypto_null.c
@@ -146,7 +146,8 @@ static struct crypto_alg null_algs[3] = { {
.cra_module =   THIS_MODULE,
.cra_u  =   { .compress = {
.coa_compress   =   null_compress,
-   .coa_decompress =   null_compress } }
+   .coa_decompress =   null_compress,
+   .coa_decompress_unsafe  =   null_compress } }
 } };
 
 MODULE_ALIAS_CRYPTO("compress_null");
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 94ec3b36..4b681a37 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -286,7 +286,8 @@ static struct crypto_alg alg = {
.cra_exit   = deflate_exit,
.cra_u  = { .compress = {
.coa_compress   = deflate_compress,
-   .coa_decompress = deflate_decompress } }
+   .coa_decompress = deflate_decompress,
+   .coa_decompress_unsafe  = deflate_decompress } }
 };
 
 static struct scomp_alg scomp[] = { {
diff --git a/crypto/lz4.c b/crypto/lz4.c
index 2ce2660d..60a1914b 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -103,6 +103,19 @@ static int __lz4_decompress_crypto(const u8 *src, unsigned 
int slen,
return 0;
 }
 
+static int __lz4_decompress_crypto_unsafe(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen,
+  void *ctx)
+{
+   int out_len = LZ4_decompress_fast(src, dst, *dlen);
+
+   if (out_len < 0)
+   return -EINVAL;
+
+   *dlen = out_len;
+   return 0;
+}
+
 static int lz4_sdecompress(struct crypto_scomp *tfm, const u8 *src,
   unsigned int slen, u8 *dst, unsigned int *dlen,
   void *ctx)
@@ -117,6 +130,13 @@ static int lz4_decompress_crypto(struct crypto_tfm

[PATCH v7 4/5] crypto: configurable compression level

2018-04-13 Thread Benjamin Warnke 
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 <4bwar...@informatik.uni-hamburg.de>
---
 crypto/api.c  | 76 +++
 crypto/deflate.c  | 16 +
 crypto/lz4.c  | 16 +
 crypto/lz4hc.c| 13 +---
 crypto/testmgr.c  |  2 +-
 drivers/block/zram/zcomp.c| 10 +++---
 drivers/block/zram/zcomp.h|  3 +-
 drivers/block/zram/zram_drv.c | 24 --
 drivers/block/zram/zram_drv.h |  1 +
 fs/pstore/platform.c  |  2 +-
 fs/ubifs/compress.c   |  2 +-
 include/linux/crypto.h|  9 +++--
 mm/zswap.c|  2 +-
 net/xfrm/xfrm_ipcomp.c|  3 +-
 14 files changed, 147 insertions(+), 32 deletions(-)

diff --git a/crypto/api.c b/crypto/api.c
index 1d5290c6..81c3d416 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -388,6 +388,47 @@ struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg 
*alg, u32 type,
 }
 EXPORT_SYMBOL_GPL(__crypto_alloc_tfm);
 
+struct crypto_tfm *__crypto_alloc_tfm_compress(struct crypto_alg *alg,
+  u32 type, u32 mask, int level)
+{
+   struct crypto_tfm *tfm = NULL;
+   unsigned int tfm_size;
+   int err = -ENOMEM;
+
+   tfm_size = sizeof(*tfm) + crypto_ctxsize(alg, type, mask);
+   tfm = kzalloc(tfm_size, GFP_KERNEL);
+   if (!tfm)
+   goto out_err;
+
+   tfm->__crt_alg = alg;
+   if (alg->cra_flags & CRYPTO_ALG_TYPE_COMPRESS)
+   tfm->crt_compress.cot_level = level;
+
+   err = crypto_init_ops(tfm, type, mask);
+   if (err)
+   goto out_free_tfm;
+
+   if (!tfm->exit && alg->cra_init) {
+   err = alg->cra_init(tfm);
+   if (err)
+   goto cra_init_failed;
+   }
+
+   goto out;
+
+cra_init_failed:
+   crypto_exit_ops(tfm);
+out_free_tfm:
+   if (err == -EAGAIN)
+   crypto_shoot_alg(alg);
+   kfree(tfm);
+out_err:
+   tfm = ERR_PTR(err);
+out:
+   return tfm;
+}
+EXPORT_SYMBOL_GPL(__crypto_alloc_tfm_compress);
+
 /*
  * crypto_alloc_base - Locate algorithm and allocate transform
  * @alg_name: Name of algorithm
@@ -444,6 +485,41 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name, 
u32 type, u32 mask)
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_base);
 
+struct crypto_tfm *crypto_alloc_base_compress(const char *alg_name, u32 type,
+ u32 mask, int level)
+{
+   struct crypto_tfm *tfm;
+   int err;
+
+   for (;;) {
+   struct crypto_alg *alg;
+
+   alg = crypto_alg_mod_lookup(alg_name, type, mask);
+   if (IS_ERR(alg)) {
+   err = PTR_ERR(alg);
+   goto err;
+   }
+
+   tfm = __crypto_alloc_tfm_compress(alg, type, mask, level);
+   if (!IS_ERR(tfm))
+   return tfm;
+
+   crypto_mod_put(alg);
+   err = PTR_ERR(tfm);
+
+err:
+   if (err != -EAGAIN)
+   break;
+   if (fatal_signal_pending(current)) {
+   err = -EINTR;
+   break;
+   }
+   }
+
+   return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_base_compress);
+
 void *crypto_create_tfm(struct crypto_alg *alg,
const struct crypto_type *frontend)
 {
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 4b681a37..54a2ff21 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -24,6 +24,7 @@
  * it is not needed for IPCOMP and keeps the code simpler.  It can be
  * implemented if someone wants it.
  */
+
 #include 
 #include 
 #include 
@@ -43,7 +44,7 @@ struct deflate_ctx {
struct z_stream_s decomp_stream;
 };
 
-static int deflate_comp_init(struct deflate_ctx *ctx, int format)
+static int deflate_comp_init(struct deflate_ctx *ctx, int format, int level)
 {
int ret = 0;
struct z_stream_s *stream = >comp_stream;
@@ -55,9 +56,9 @@ static int deflate_comp_init(struct deflate_ctx *ctx, int 
format)
goto out;
}
if (format)
-   ret = zlib_deflateInit(stream, 3);
+   ret = zlib_deflateInit(stream, level);
else
-   ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
+   ret = zlib_deflateInit2(stream, level, Z_DEFLATED,
-DEFLATE_DEF_WINBITS,
DEFLATE_DEF_MEMLEVEL,
Z_DEFAULT_STRATEGY);
@@ -109,11 +110,11 @@ static void deflate_decomp_exit(struct deflate_ctx

[PATCH v7 1/5] add compression algorithm zBeWalgo

2018-04-13 Thread Benjamin Warnke 
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 compression and transformation algorithms after each other.
The execution of different compression algorithms after each other will be
called 'combination' in this description and in the code. Additionally to be
able to execute combinations of algorithms, zBeWalgo can try different
combinations on the same input. This allows high compression ratios on
completely different datasets, which would otherwise require its own
algorithm each. Executing all known combinations on each input page would be
very slow. Therefore the data is compressed at first with that combination,
which was already successful on the last input page. If the compressed data
size of the current page is similar to that of the last page, the compressed
data is returned immediately without even trying the other combinations. Even
if there is no guarantee that consecutive calls to the algorithm belong to
each other, the speed improvement is obvious.

ZRAM uses zsmalloc for the management of the compressed pages. The largest
size-class in zsmalloc is 3264 Bytes. If the compressed data is larger than
that threshold, ZRAM ignores the compression and writes the uncompressed page
instead. As a consequence it is useless to continue compression, if the
algorithm detects, that the data can not be compressed using the current
combination. The threshold for aborting compression can be changed via sysfs at
any time, even if the algorithm is currently in use. If a combination fails to
compress the data, zBeWalgo tries the next combination. If no combination is
able to reduce the data in size, zBeWalgo returns a negative value.

Each combination consists of up to 7 compression and transformation steps.
Combinations can be added and removed at any time via sysfs. Already compressed
Data can always be decompressed, even if the combination used to produce it
does not exist anymore. Technically the user could add up to 256 combinations
concurrently, but that would be very time consuming if the data can not be
compressed.

To be able to build combinations and call different algorithms, all those
algorithms are implementing the same interface. This enables the user to
specify additional combinations while ZRAM is running.

Within the combinations many different algorithms can be used. Some of those
algorithms are published. This patch adds the following algorithms to be used
within the combinations:
- bwt: The Burrows-Wheeler-Transformation was published by 'M. Burrows' and
'D. J. Wheeler' in 1994. This implementation uses counting sort for
sorting the data. Their original paper is online available at:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-124.pdf
- mtf: The Move-To-Front algorithm as described by 'M. Burrows' and
'D. J. Wheeler' in the same paper as bwt.
- jbe: j-bit-encoding as proposed by 'I Made Agus Dwi Suarjaya' in 2012.
https://arxiv.org/pdf/1209.1045.pdf
- jbe2: A minor modification of jbe. Swapping groups of 4 Bit in consecutive
Bytes can increase the compression ratio, if for example the first
4 Bits of each Byte are zero. If jbe2 is called after mtf, this
happens ofthen.
- rle: Run Length Encoding
- huffman: Huffman encoding
- bewalgo: I invented this algorithm for my bachelors thesis
'Page-Based compression in the Linux Kernel'. This algorithm is
mainly inspired by lz4, focusing on increasing the speed even more,
with the help of page aligned read an write access. To achieve the
page alignment, the input and output data is accessed only in
blocks of 8 Bytes, therefore the encoding of the compressed data is
changed.

https://wr.informatik.uni-hamburg.de/_media/research:theses:benjamin_warnke_page_based_compression_in_the_linux_kernel.pdf
- bewalgo2: At the beginning of my work to improve ZRAM this was the whole
algorithm. The input is read in blocks of 8 Bytes. These Blocks
are added to an avl-tree. The avl-tree is mapped directly to an
array. The encoding is a variation of Run Length Encoding using the
indices in the avl-tree as data. The reason for using the tree
with indices is, that the indices can be encoded in less then
8 Bytes each.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 include/linux/zbewalgo.h  |  50 
 lib/Kconfig   |   3 +
 lib/Makefile  |   1 +
 lib/zbewalgo/BWT.c| 120 
 lib/zbewalgo/BWT.h|  21 ++
 lib/zbewalgo/JBE.c| 204 +
 lib/zbewalgo/JBE.h|  13 +
 lib/zbewalgo/JBE2.c   | 221 ++
 lib/zbewalgo/JBE2.h   |  13 +
 lib/zbewalgo/MTF.c| 122 
 lib/zbewalgo/MTF.h|  13 +
 lib/zbewalgo/Makefile |   4 +

[PATCH v7 0/5] add compression algorithm zBeWalgo

2018-04-13 Thread Benjamin Warnke 
This patch series adds a new compression algorithm to the kernel and to
the crypto api.

Changes since v6:
- Fixed git apply error due to other recently applied patches

Changes since v5:
- Fixed compile-error due to variable definitions inside #ifdef 
CONFIG_ZRAM_WRITEBACK

Changes since v4:
- Fix mismatching function-prototypes
- Fix mismatching License errors
- Add static to global vars
- Add ULL to long constants

Changes since v3:
- Split patch into patchset
- Add Zstd = Zstandard to the list of benchmarked algorithms
- Added configurable compression levels to crypto-api
- Added multiple compression levels to the benchmarks below
- Added unsafe decompressor functions to crypto-api
- Added flag to mark unstable algorithms to crypto-api
- Test the code using afl-fuzz -> and fix the code
- Added 2 new Benchmark datasets
- checkpatch.pl fixes

Changes since v2:
- added linux-kernel Mailinglist

Changes since v1:
- improved documentation
- improved code style
- replaced numerous casts with get_unaligned*
- added tests in crypto/testmgr.h/c
- added zBeWalgo to the list of algorithms shown by 
/sys/block/zram0/comp_algorithm


Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
compresses each page individually. As a result the compression algorithm is
forced to use a very small sliding window. None of the available compression
algorithms is designed to achieve high compression ratios with small inputs.

This patch-set adds a new compression algorithm 'zBeWalgo' to the crypto api.
This algorithm focusses on increasing the capacity of the compressed
block-device created by ZRAM. The choice of compression algorithms is always
a tradeoff between speed and compression ratio.

If faster algorithms like 'lz4' are chosen the compression ratio is often
lower than the ratio of zBeWalgo as shown in the following benchmarks. Due to
the lower compression ratio, ZRAM needs to fall back to backing_devices
mode often. If backing_devices are required, the effective speed of ZRAM is a
weighted average of de/compression time and writing/reading from the
backing_device. This should be considered when comparing the speeds in the
benchmarks.

There are different kinds of backing_devices, each with its own drawbacks.
1. HDDs: This kind of backing device is very slow. If the compression ratio
of an algorithm is much lower than the ratio of zBeWalgo, it might be faster
to use zBewalgo instead.
2. SSDs: I tested a swap partition on my NVME-SSD. The speed is even higher
than zram with lz4, but after about 5 Minutes the SSD is blocking all
read/write requests due to overheating. This is definitly not an option.


Benchmarks:


To obtain reproducable benchmarks, the datasets were first loaded into a
userspace-program. Than the data is written directly to a clean
zram-partition without any filesystem. Between writing and reading 'sync'
and 'echo 3 > /proc/sys/vm/drop_caches' is called. All time measurements are
wall clock times, and the benchmarks are using only one cpu-core at a time.
The new algorithm is compared to all available compression algorithms from
the crypto-api.

Before loading the datasets to user-space deduplication is applied, since
none Algorithm has deduplication. Duplicated pages are removed to
prevent an algorithm to obtain high/low ratios, just because a single page can
be compressed very well - or not.

All Algorithms marked with '*' are using unsafe decompression.

All Read and Write Speed Measurements are given in MBit/s

zbewalgo' uses per dataset specialized different combinations. These can be
specified at runtime via /sys/kernel/zbewalgo/combinations.


- '/dev/zero' This dataset is used to measure the speed limitations
for ZRAM. ZRAM filters zero-data internally and does not even call the
specified compression algorithm.

Algorithm   writeread
--zram--  2724.08 2828.87


- 'ecoham' This dataset is one of the input files for the scientific
application ECOHAM which runs an ocean simulation. This dataset contains a
lot of zeros - even after deduplication. Where the data is not zero there are
arrays of floating point values, adjacent float values are likely to be
similar to each other, allowing for high compression ratios.

zbewalgo reaches very high compression ratios and is a lot faster than other
algorithms with similar compression ratios.

Algorithmratiowrite read
--hdd--   1.00   134.70   156.62
lz4*_10   6.73  1303.12  1547.17
lz4_106.73  1303.12  1574.51
lzo   6.88  1205.98  1468.09
lz4*_05   7.00  1291.81  1642.41
lz4_057.00  1291.81  1682.81
lz4_077.13  1250.29  1593.89
lz4*_07   7.13  1250.29  1677.08
lz4_067.16  1307.62  1666.66
lz4*_06   7.16  1307.62  1669.42
lz4_037.21  1250.87  1449.48
lz4*_03   7.21  1250.87  1621.97
lz4*_04   7.23  1281.62  1645.56
lz4_047.23  1281.62  1666.81
lz4_027.33  1267.54  1523.11
lz4*_02   7.33  1267.54  1576.54
lz4_097.36

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

2018-04-13 Thread Benjamin Warnke 
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 changed, 7 insertions(+), 1 deletion(-)

diff --git a/crypto/zbewalgo.c b/crypto/zbewalgo.c
index 9db0d43b..e57b5ced 100644
--- a/crypto/zbewalgo.c
+++ b/crypto/zbewalgo.c
@@ -134,7 +134,7 @@ static int zbewalgo_decompress_crypto_unsafe(struct 
crypto_tfm *tfm,
 
 static struct crypto_alg crypto_alg_zbewalgo = {
.cra_name = "zbewalgo",
-   .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags = CRYPTO_ALG_TYPE_COMPRESS | CRYPTO_ALG_UNSTABLE_ENCODING,
.cra_ctxsize = sizeof(struct zbewalgo_ctx),
.cra_module = THIS_MODULE,
.cra_init = zbewalgo_init,
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6bfb1aea..2228dd08 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -112,6 +112,12 @@
  */
 #define CRYPTO_ALG_OPTIONAL_KEY0x4000
 
+/*
+ * Set if the algorithm is new and it is likely that the encoding may
+ * change in near future
+ */
+#define CRYPTO_ALG_UNSTABLE_ENCODING   0x8000
+
 /*
  * Transform masks and values (for crt_flags).
  */
-- 
2.14.1

Re: [PATCH 1/5] random: fix crng_ready() test

2018-04-13 Thread Stephan Mueller 
Am Freitag, 13. April 2018, 14:53:13 CEST schrieb Theodore Y. Ts'o:

Hi Theodore,
> 
> This was always the original design intent, but I screwed up and no
> one noticed until Jann reached out to be and said, "Hey this
> doesn't seem to make much sense".

I disagree, but I guess you would have expected that. But this is not the 
issue.

What I would like to point out that more and more folks change to 
getrandom(2). As this call will now unblock much later in the boot cycle, 
these systems see a significant departure from the current system behavior.

E.g. an sshd using getrandom(2) would be ready shortly after the boot finishes 
as of now. Now it can be a matter minutes before it responds. Thus, is such 
change in the kernel behavior something for stable?

Ciao
Stephan

Re: [PATCH 1/5] random: fix crng_ready() test

2018-04-13 Thread Theodore Y. Ts'o 
On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote:
> > The crng_init variable has three states:
> > 
> > 0: The CRNG is not initialized at all
> > 1: The CRNG has a small amount of entropy, hopefully good enough for
> >early-boot, non-cryptographical use cases
> > 2: The CRNG is fully initialized and we are sure it is safe for
> >cryptographic use cases.
> > 
> > The crng_ready() function should only return true once we are in the
> > last state.
> > 
> Do I see that correctly that getrandom(2) will now unblock after the 
> input_pool has obtained 128 bits of entropy? Similarly for 
> get_random_bytes_wait.

Correct.

> As this seems to be the only real use case for crng_ready (apart from 
> logging), what is the purpose of crng_init == 1?

Immediately after boot (crng_init state 0), we funnel the harvested
entropy from add_interrupt_entropy() directly to the CRNG pool.  The
goal is to get at least some amount of entropy into the CRNG is it's
not blatently predictable.  When we have accomplished this, by mixing
in 2 * CHACHA20_KEY_SIZE bytes of input from add_input_randomness, we
enter state crng_init state 1.

In crng_init state 1, we start funnelling the harvested entropy to the
input_pool.  Once we have accumulated 128 bits of entropy in the input
pool, we then reseed the CRNG from the input_pool, and we consider the
CRNG to be fully intialized.

During crng_init state 1, the CRNG is basically in a "good enough for
government work" state.  It's going to get used by things like initial
TCP sequence numbers, and UUID's by udev, et. al, but I wouldn't want
to use it for anything that has strong cryptographic use cases.

It would be preferable if nothing in the kernel and early systemd
startup used get_random_bytes() or /dev/urandom or getrandom(2) w/
GRND_NONBLOCK.  Unfortunately, (a) there is a lot of legacy code which
still uses /dev/urandom and not getrandom(2) and (b) in some cases,
such as initialization of the Stack Canary, the kernel simply can't
wait for the CRNG to be fully initialized.  Or if the kernel needs
enough of the networking stack to mount an NFS root file system, for
example.

This was always the original design intent, but I screwed up and no
one noticed until Jann reached out to be and said, "Hey this
doesn't seem to make much sense".

Regards,

- Ted

[PATCH] hwrng: via-rng - support new Centaur CPU

2018-04-13 Thread David Wang 
New Centaur CPU(Family > 6) supprt Random Number Generator, but can't
support MSR_VIA_RNG. Just like VIA Nano.

Signed-off-by: David Wang 
---
 drivers/char/hw_random/via-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index d1f5bb5..d9448b1 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -135,7 +135,7 @@ static int via_rng_init(struct hwrng *rng)
 * is always enabled if CPUID rng_en is set.  There is no
 * RNG configuration like it used to be the case in this
 * register */
-   if ((c->x86 == 6) && (c->x86_model >= 0x0f)) {
+   if (((c->x86 == 6) && (c->x86_model >= 0x0f))  || (c->x86 > 6)){
if (!boot_cpu_has(X86_FEATURE_XSTORE_EN)) {
pr_err(PFX "can't enable hardware RNG "
"if XSTORE is not enabled\n");
-- 
1.9.1

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

2018-04-13 Thread Horia Geantă 
On 4/13/2018 3:12 AM, Fabio Estevam wrote:
> Hi Horia,
> 
> On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă  wrote:
> 
>> Yes, driver needs to strip off leading zeros from input data before feeding 
>> it
>> to the accelerator.
>> I am working at a fix.
> 
> I was able to to strip off the leading zeros from input data as you suggested.
> 
> My changes are like this at the moment:
> 
[snip]
> but still get the original error as shown below.
> 
> Any ideas?
> 
Stripping should happen before set_rsa_pub_pdb() is called since the Protocol
Data Block contains the input length that is used by the accelerator:
pdb->f_len = req->src_len;

It should probably be moved at the top of rsa_edesc_alloc().

Ideally stripping would avoid copying data (and memory allocation for temporary
buffers).

Horia