Re: [PATCH v3] crypto/caam: add backlogging support

[Horia Geantă]

On 9/19/2015 12:02 PM, Alex Porosanu wrote:
> caam_jr_enqueue() function returns -EBUSY once there are no
> more slots available in the JR, but it doesn't actually save
> the current request. This breaks the functionality of users
> that expect that even if there is no more space for the request,
> it is at least queued for later execution. In other words, all
> crypto transformations that request backlogging
> (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such an
> example is dm-crypt.
> The current patch solves this issue by setting a threshold after
> which caam_jr_enqueue() returns -EBUSY, but since the HW job ring
> isn't actually full, the job is enqueued.
> Caveat: if the users of the driver don't obey the API contract which
> states that once -EBUSY is received, no more requests are to be
> sent, eventually the driver will reject the enqueues.
> For well-behaved CryptoAPI users, like dm-crypt, this is not the
> case, since the processing thread will sleep once -EBUSY is
> received.
> 
> Signed-off-by: Alex Porosanu 
> 
> ---
> v3:
> - as per Herbert's observation, allow only # of backlogging slots
>   transformations w/MAY_BACKLOG flag set to be affined to a JR;
>   the total # of transformations that can be thus allocated is equal
>   to the # of JRs times the # of "backlogging slots". In the standard
>   configuration, this means 16 x 4 = 64 transformations.

This won't work, since CRYPTO_TFM_REQ_MAY_BACKLOG is set per request (at
request setup time), not per tfm.

Horia


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
>  static int __init lzo_mod_init(void)
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index e71cb70..31152b1 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -355,6 +355,8 @@ struct compress_alg {
>   unsigned int slen, u8 *dst, unsigned int *dlen);
>   int (*coa_decompress)(struct crypto_tfm *tfm, const u8 *src,
> unsigned int slen, u8 *dst, unsigned int *dlen);
> + int (*coa_decompress_noctx)(const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen);
>  };
>  
>  
> @@ -538,6 +540,9 @@ struct compress_tfm {
>   int (*cot_decompress)(struct crypto_tfm *tfm,
> const u8 *src, unsigned int slen,
> u8 *dst, unsigned int *dlen);
> + int (*cot_decompress_noctx)(struct crypto_tfm *tfm,
> + const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen);
>  };
>  
>  #define crt_ablkcipher   crt_u.ablkcipher
> @@ -1836,6 +1841,14 @@ static inline void crypto_free_comp(struct crypto_comp 
> *tfm)
>   crypto_free_tfm(crypto_comp_tfm(tfm));
>  }
>  
> +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> + u32 type, u32 mask);
> +

this should be EXPORT_SYMBOL_GPL().

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API

[Sergey Senozhatsky]

On (09/18/15 14:19), Joonsoo Kim wrote:
[..]
> + /*
> +  * Prepare to use crypto decompress_noctx API. One tfm is required
> +  * to initialize crypto algorithm properly and fetch corresponding
> +  * function pointer. But, it is sharable for multiple concurrent
> +  * decompress users.
> +  */

if comp algorithm require zstrm for both compression and decompression,
then there seems to be no need in allocating sharable ->tfm_noctx, we
will never use it.

-ss

> + tfm = crypto_alloc_comp_noctx(compress, 0, 0);
> + if (!IS_ERR(tfm))
> + comp->tfm_noctx = tfm;
> +
>   return comp;
>  }
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 4f9df8e..c76d8e4 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -26,6 +26,7 @@ struct zcomp_strm {
>  /* dynamic per-device compression frontend */
>  struct zcomp {
>   void *stream;
> + struct crypto_comp *tfm_noctx;
>   const char *backend;
>  
>   struct zcomp_strm *(*strm_find)(struct zcomp *comp);
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/38] hwrng: fix handling platform_get_irq

[Andrzej Hajda]

The function can return negative value.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda 
---
 drivers/char/hw_random/xgene-rng.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/xgene-rng.c 
b/drivers/char/hw_random/xgene-rng.c
index c37cf75..3c77645 100644
--- a/drivers/char/hw_random/xgene-rng.c
+++ b/drivers/char/hw_random/xgene-rng.c
@@ -344,11 +344,12 @@ static int xgene_rng_probe(struct platform_device *pdev)
if (IS_ERR(ctx->csr_base))
return PTR_ERR(ctx->csr_base);
 
-   ctx->irq = platform_get_irq(pdev, 0);
-   if (ctx->irq < 0) {
+   rc = platform_get_irq(pdev, 0);
+   if (rc < 0) {
dev_err(>dev, "No IRQ resource\n");
-   return ctx->irq;
+   return rc;
}
+   ctx->irq = rc;
 
dev_dbg(>dev, "APM X-Gene RNG BASE %p ALARM IRQ %d",
ctx->csr_base, ctx->irq);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/9] use CRYPTO_ALG_TFM_MAY_SHARE cra flag (full patchset)

[Sergey Senozhatsky]

On (09/21/15 22:13), Sergey Senozhatsky wrote:
> RFC
> 
> resend reason:
> git (2.6.0-rc2) has crashed and spme patches were not sent out.
> 
> 
> Sorry for the noise.
> 
> ===

what a day... really sorry.


(release 2.5.3) git has crashed again

[Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 
1351.
fatal: 'send-email' appears to be a git command, but we were not
able to execute it. Maybe git-send-email is broken?

hm...

-ss

> 
> This patch set implements a bit different approach to shared tfm. It
> defines a new CRYPTO_ALG_TFM_MAY_SHARE ->cra_flag which each algorithm
> setups in its `static struct crypto_alg'. Crypto API provides
> crypto_tfm_may_share() function that returns true if the algorithm
> has CRYPTO_ALG_TFM_MAY_SHARE set and, thus, we can supply a shared
> `struct crypto_comp *tfm'.
> 
> Not properly tested yet.
> 
> 
> Sergey Senozhatsky (9):
>   crypto: introduce CRYPTO_ALG_TFM_MAY_SHARE flag
>   crypto/lzo: set CRYPTO_ALG_TFM_MAY_SHARE
>   crypto/lz4: set CRYPTO_ALG_TFM_MAY_SHARE
>   crypto/lz4hc: set CRYPTO_ALG_TFM_MAY_SHARE
>   crypto/842: set CRYPTO_ALG_TFM_MAY_SHARE
>   zram: make stream find and release functions static
>   zram: pass zstrm down to decompression path
>   zram: use crypto API for compression
>   zram: use crypto CRYPTO_ALG_TFM_MAY_SHARE API
> 
>  crypto/842.c   |   3 +-
>  crypto/lz4.c   |   3 +-
>  crypto/lz4hc.c |   3 +-
>  crypto/lzo.c   |   3 +-
>  drivers/block/zram/Kconfig |   8 ++--
>  drivers/block/zram/Makefile|   4 +-
>  drivers/block/zram/zcomp.c | 103 
> +++--
>  drivers/block/zram/zcomp.h |  42 +++--
>  drivers/block/zram/zcomp_lz4.c |  47 ---
>  drivers/block/zram/zcomp_lz4.h |  17 ---
>  drivers/block/zram/zcomp_lzo.c |  47 ---
>  drivers/block/zram/zcomp_lzo.h |  17 ---
>  drivers/block/zram/zram_drv.c  |  32 +
>  include/linux/crypto.h |  10 
>  14 files changed, 138 insertions(+), 201 deletions(-)
>  delete mode 100644 drivers/block/zram/zcomp_lz4.c
>  delete mode 100644 drivers/block/zram/zcomp_lz4.h
>  delete mode 100644 drivers/block/zram/zcomp_lzo.c
>  delete mode 100644 drivers/block/zram/zcomp_lzo.h
> 
> -- 
> 2.6.0.rc2.10.gf4d9753
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

[David Howells]

Andrzej Hajda  wrote:

> Semantic patch finds comparisons of types:
> unsigned < 0
> unsigned >= 0
> The former is always false, the latter is always true.
> Such comparisons are useless, so theoretically they could be
> safely removed, but their presence quite often indicates bugs.

Or someone has left them in because they don't matter and there's the
possibility that the type being tested might be or become signed under some
circumstances.  If the comparison is useless, I'd expect the compiler to just
discard it - for such cases your patch is pointless.

If I have, for example:

unsigned x;

if (x == 0 || x > 27)
give_a_range_error();

I will write this as:

unsigned x;

if (x <= 0 || x > 27)
give_a_range_error();

because it that gives a way to handle x being changed to signed at some point
in the future for no cost.  In which case, your changing the <= to an ==
"because the < part of the case is useless" is arguably wrong.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 1/9] crypto: introduce CRYPTO_ALG_TFM_MAY_SHARE flag

[Sergey Senozhatsky]

Set CRYPTO_ALG_TFM_MAY_SHARE ->cra_flags when algorithm support
shared tfm.

Signed-off-by: Sergey Senozhatsky 
---
 include/linux/crypto.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index e71cb70..66f10f8 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -102,6 +102,11 @@
 #define CRYPTO_ALG_INTERNAL0x2000
 
 /*
+ * Mark that algorithm can use shared tfm
+ */
+#define CRYPTO_ALG_TFM_MAY_SHARE   0x4000
+
+/*
  * Transform masks and values (for crt_flags).
  */
 #define CRYPTO_TFM_REQ_MASK0x000fff00
@@ -648,6 +653,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm 
*tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
 }
 
+static inline u32 crypto_tfm_may_share(struct crypto_tfm *tfm)
+{
+   return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TFM_MAY_SHARE;
+}
+
 static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
 {
return tfm->__crt_alg->cra_blocksize;
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 6/9] zram: make stream find and release functions static

[Sergey Senozhatsky]

Hide (make static) zstrm find and release function and introduce
zcomp_compress_begin()/zcomp_compress_end(). We will have begin
and end functions around compression (this patch) and decompression
(next patch). So the work flow is evolving to:

zstrm = foo_begin();
foo(zstrm);
foo_end(zstrm);

where foo is compress or decompress zcomp functions.

This patch is a preparation to make crypto API-powered zcomp
possible. The reasoning is that some crypto compression backends
require zstrm for decompression.

Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zcomp.c| 27 +--
 drivers/block/zram/zcomp.h|  8 ++--
 drivers/block/zram/zram_drv.c |  6 +++---
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 5cb13ca..52d5b04 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -296,16 +296,39 @@ bool zcomp_set_max_streams(struct zcomp *comp, int 
num_strm)
return comp->set_max_streams(comp, num_strm);
 }
 
-struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
+static struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
 {
return comp->strm_find(comp);
 }
 
-void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm)
+static void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm)
 {
comp->strm_release(comp, zstrm);
 }
 
+/* Never return NULL, may sleep */
+struct zcomp_strm *zcomp_compress_begin(struct zcomp *comp)
+{
+   return zcomp_strm_find(comp);
+}
+
+void zcomp_compress_end(struct zcomp *comp, struct zcomp_strm *zstrm)
+{
+   zcomp_strm_release(comp, zstrm);
+}
+
+/* May return NULL, may sleep */
+struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
+{
+   return NULL;
+}
+
+void zcomp_decompress_end(struct zcomp *comp, struct zcomp_strm *zstrm)
+{
+   if (zstrm)
+   zcomp_strm_release(comp, zstrm);
+}
+
 int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
const unsigned char *src, size_t *dst_len)
 {
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 46e2b9f..616e013 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -56,12 +56,16 @@ bool zcomp_available_algorithm(const char *comp);
 struct zcomp *zcomp_create(const char *comp, int max_strm);
 void zcomp_destroy(struct zcomp *comp);
 
-struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
-void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
+
+struct zcomp_strm *zcomp_compress_begin(struct zcomp *comp);
+void zcomp_compress_end(struct zcomp *comp, struct zcomp_strm *zstrm);
 
 int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
const unsigned char *src, size_t *dst_len);
 
+struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp);
+void zcomp_decompress_end(struct zcomp *comp, struct zcomp_strm *zstrm);
+
 int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
size_t src_len, unsigned char *dst);
 
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c93aeb8..7dda8a5 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -673,7 +673,7 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
goto out;
}
 
-   zstrm = zcomp_strm_find(zram->comp);
+   zstrm = zcomp_compress_begin(zram->comp);
user_mem = kmap_atomic(page);
 
if (is_partial_io(bvec)) {
@@ -744,7 +744,7 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
memcpy(cmem, src, clen);
}
 
-   zcomp_strm_release(zram->comp, zstrm);
+   zcomp_compress_end(zram->comp, zstrm);
zstrm = NULL;
zs_unmap_object(meta->mem_pool, handle);
 
@@ -764,7 +764,7 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
atomic64_inc(>stats.pages_stored);
 out:
if (zstrm)
-   zcomp_strm_release(zram->comp, zstrm);
+   zcomp_compress_end(zram->comp, zstrm);
if (is_partial_io(bvec))
kfree(uncmem);
return ret;
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 5/9] crypto/842: set CRYPTO_ALG_TFM_MAY_SHARE

[Sergey Senozhatsky]

Signed-off-by: Sergey Senozhatsky 
---
 crypto/842.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/842.c b/crypto/842.c
index 98e387e..579be68 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -56,7 +56,8 @@ static struct crypto_alg alg = {
.cra_name   = "842",
.cra_driver_name= "842-generic",
.cra_priority   = 100,
-   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS |
+   CRYPTO_ALG_TFM_MAY_SHARE,
.cra_ctxsize= sizeof(struct crypto842_ctx),
.cra_module = THIS_MODULE,
.cra_u  = { .compress = {
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 0/9] use CRYPTO_ALG_TFM_MAY_SHARE cra flag (full patchset)

[Sergey Senozhatsky]

RFC

resend reason:
git (2.6.0-rc2) has crashed and spme patches were not sent out.


Sorry for the noise.

===


This patch set implements a bit different approach to shared tfm. It
defines a new CRYPTO_ALG_TFM_MAY_SHARE ->cra_flag which each algorithm
setups in its `static struct crypto_alg'. Crypto API provides
crypto_tfm_may_share() function that returns true if the algorithm
has CRYPTO_ALG_TFM_MAY_SHARE set and, thus, we can supply a shared
`struct crypto_comp *tfm'.

Not properly tested yet.


Sergey Senozhatsky (9):
  crypto: introduce CRYPTO_ALG_TFM_MAY_SHARE flag
  crypto/lzo: set CRYPTO_ALG_TFM_MAY_SHARE
  crypto/lz4: set CRYPTO_ALG_TFM_MAY_SHARE
  crypto/lz4hc: set CRYPTO_ALG_TFM_MAY_SHARE
  crypto/842: set CRYPTO_ALG_TFM_MAY_SHARE
  zram: make stream find and release functions static
  zram: pass zstrm down to decompression path
  zram: use crypto API for compression
  zram: use crypto CRYPTO_ALG_TFM_MAY_SHARE API

 crypto/842.c   |   3 +-
 crypto/lz4.c   |   3 +-
 crypto/lz4hc.c |   3 +-
 crypto/lzo.c   |   3 +-
 drivers/block/zram/Kconfig |   8 ++--
 drivers/block/zram/Makefile|   4 +-
 drivers/block/zram/zcomp.c | 103 +++--
 drivers/block/zram/zcomp.h |  42 +++--
 drivers/block/zram/zcomp_lz4.c |  47 ---
 drivers/block/zram/zcomp_lz4.h |  17 ---
 drivers/block/zram/zcomp_lzo.c |  47 ---
 drivers/block/zram/zcomp_lzo.h |  17 ---
 drivers/block/zram/zram_drv.c  |  32 +
 include/linux/crypto.h |  10 
 14 files changed, 138 insertions(+), 201 deletions(-)
 delete mode 100644 drivers/block/zram/zcomp_lz4.c
 delete mode 100644 drivers/block/zram/zcomp_lz4.h
 delete mode 100644 drivers/block/zram/zcomp_lzo.c
 delete mode 100644 drivers/block/zram/zcomp_lzo.h

-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 2/9] crypto/lzo: set CRYPTO_ALG_TFM_MAY_SHARE

[Sergey Senozhatsky]

Signed-off-by: Sergey Senozhatsky 
---
 crypto/lzo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/lzo.c b/crypto/lzo.c
index 4b3e925..994667e 100644
--- a/crypto/lzo.c
+++ b/crypto/lzo.c
@@ -82,7 +82,8 @@ static int lzo_decompress(struct crypto_tfm *tfm, const u8 
*src,
 
 static struct crypto_alg alg = {
.cra_name   = "lzo",
-   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS |
+   CRYPTO_ALG_TFM_MAY_SHARE,
.cra_ctxsize= sizeof(struct lzo_ctx),
.cra_module = THIS_MODULE,
.cra_init   = lzo_init,
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 3/9] crypto/lz4: set CRYPTO_ALG_TFM_MAY_SHARE

[Sergey Senozhatsky]

Signed-off-by: Sergey Senozhatsky 
---
 crypto/lz4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/lz4.c b/crypto/lz4.c
index aefbcea..ca48de1 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -78,7 +78,8 @@ static int lz4_decompress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 
 static struct crypto_alg alg_lz4 = {
.cra_name   = "lz4",
-   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS |
+   CRYPTO_ALG_TFM_MAY_SHARE,
.cra_ctxsize= sizeof(struct lz4_ctx),
.cra_module = THIS_MODULE,
.cra_list   = LIST_HEAD_INIT(alg_lz4.cra_list),
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 4/9] crypto/lz4hc: set CRYPTO_ALG_TFM_MAY_SHARE

[Sergey Senozhatsky]

Signed-off-by: Sergey Senozhatsky 
---
 crypto/lz4hc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index a1d3b5b..34ef3de 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -78,7 +78,8 @@ static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, 
const u8 *src,
 
 static struct crypto_alg alg_lz4hc = {
.cra_name   = "lz4hc",
-   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS |
+   CRYPTO_ALG_TFM_MAY_SHARE,
.cra_ctxsize= sizeof(struct lz4hc_ctx),
.cra_module = THIS_MODULE,
.cra_list   = LIST_HEAD_INIT(alg_lz4hc.cra_list),
-- 
2.6.0.rc2.10.gf4d9753

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 7/9] zram: pass zstrm down to decompression path

[Sergey Senozhatsky]

Introduce zcomp_decompress_begin()/zcomp_decompress_end() as a
preparation for crypto API-powered zcomp.

Change zcomp_decompress() signature to require zstrm parameter.

Unlike zcomp_compress_begin(), zcomp_decompress_begin() may return
zstrm if currently selected compression backend require zstrm for
decompression or NULL if it does not.

Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zcomp.c|  3 ++-
 drivers/block/zram/zcomp.h|  3 ++-
 drivers/block/zram/zram_drv.c | 20 
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 52d5b04..e3016da 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -336,7 +336,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
*zstrm,
zstrm->private);
 }
 
-int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
+int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
+   const unsigned char *src,
size_t src_len, unsigned char *dst)
 {
return comp->backend->decompress(src, src_len, dst);
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 616e013..4c09c01 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -66,7 +66,8 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
*zstrm,
 struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp);
 void zcomp_decompress_end(struct zcomp *comp, struct zcomp_strm *zstrm);
 
-int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
+int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
+   const unsigned char *src,
size_t src_len, unsigned char *dst);
 
 bool zcomp_set_max_streams(struct zcomp *comp, int num_strm);
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 7dda8a5..74cbb81 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -560,7 +560,8 @@ static void zram_free_page(struct zram *zram, size_t index)
zram_set_obj_size(meta, index, 0);
 }
 
-static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
+static int zram_decompress_page(struct zram *zram, struct zcomp_strm *zstrm,
+   char *mem, u32 index)
 {
int ret = 0;
unsigned char *cmem;
@@ -582,7 +583,7 @@ static int zram_decompress_page(struct zram *zram, char 
*mem, u32 index)
if (size == PAGE_SIZE)
copy_page(mem, cmem);
else
-   ret = zcomp_decompress(zram->comp, cmem, size, mem);
+   ret = zcomp_decompress(zram->comp, zstrm, cmem, size, mem);
zs_unmap_object(meta->mem_pool, handle);
bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
 
@@ -602,6 +603,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec 
*bvec,
struct page *page;
unsigned char *user_mem, *uncmem = NULL;
struct zram_meta *meta = zram->meta;
+   struct zcomp_strm *zstrm;
page = bvec->bv_page;
 
bit_spin_lock(ZRAM_ACCESS, >table[index].value);
@@ -617,6 +619,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec 
*bvec,
/* Use  a temporary buffer to decompress the page */
uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
 
+   zstrm = zcomp_decompress_begin(zram->comp);
user_mem = kmap_atomic(page);
if (!is_partial_io(bvec))
uncmem = user_mem;
@@ -627,7 +630,7 @@ static int zram_bvec_read(struct zram *zram, struct bio_vec 
*bvec,
goto out_cleanup;
}
 
-   ret = zram_decompress_page(zram, uncmem, index);
+   ret = zram_decompress_page(zram, zstrm, uncmem, index);
/* Should NEVER happen. Return bio error if it does. */
if (unlikely(ret))
goto out_cleanup;
@@ -636,10 +639,14 @@ static int zram_bvec_read(struct zram *zram, struct 
bio_vec *bvec,
memcpy(user_mem + bvec->bv_offset, uncmem + offset,
bvec->bv_len);
 
+   zcomp_decompress_end(zram->comp, zstrm);
+   zstrm = NULL;
+
flush_dcache_page(page);
ret = 0;
 out_cleanup:
kunmap_atomic(user_mem);
+   zcomp_decompress_end(zram->comp, zstrm);
if (is_partial_io(bvec))
kfree(uncmem);
return ret;
@@ -659,6 +666,7 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
 
page = bvec->bv_page;
if (is_partial_io(bvec)) {
+   struct zcomp_strm *zstrm;
/*
 * This is a partial IO. We need to read the full page
 * before to write the changes.
@@ -668,7 +676,11 @@ static int zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index,
ret = -ENOMEM;
goto out;
}
-

[PATCH v4] crypto/caam: add backlogging support

[Alex Porosanu]

caam_jr_enqueue() function returns -EBUSY once there are no
more slots available in the JR, but it doesn't actually save
the current request. This breaks the functionality of users
that expect that even if there is no more space for the request,
it is at least queued for later execution. In other words, all
crypto transformations that request backlogging
(i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such an
example is dm-crypt.
The current patch solves this issue by setting a threshold after
which caam_jr_enqueue() returns -EBUSY, but since the HW job ring
isn't actually full, the job is enqueued.
The API contract which states that a CRYPTO_TFM_REQ_MAY_BACKLOG
transformation must be able to enqueue at least 1 entry is
assured by allowing only a number of transformations to be
affined to one JR, equal to half the number of JR slots minus
one.

Signed-off-by: Alex Porosanu 

---
v4:
- as per Horia's observation, now the JR is split in two and no
  more than half of the JR - 1 entry transformations can be
  affined to a JR. This leads to a total # of 511 x 4 = 1020
  transformations that can be affined on the SEC device, using
  the current default configuration.
v3:
- as per Herbert's observation, allow only # of backlogging slots
  transformations w/MAY_BACKLOG flag set to be affined to a JR;
  the total # of transformations that can be thus allocated is equal
  to the # of JRs times the # of "backlogging slots". In the standard
  configuration, this means 16 x 4 = 64 transformations.

v2:
- added backlogging support for hash as well (caamhash)
- simplfied some convoluted logic in *_done_* callbacks
- simplified backlogging entries addition in jr.c
- made the # of backlogging entries depend on the JR size
- fixed wrong function call for abklcipher (backlogging instead of 'normal')
---
 drivers/crypto/caam/caamalg.c  |  97 +---
 drivers/crypto/caam/caamhash.c | 103 ++---
 drivers/crypto/caam/intern.h   |   7 ++
 drivers/crypto/caam/jr.c   | 198 +
 drivers/crypto/caam/jr.h   |   5 ++
 5 files changed, 346 insertions(+), 64 deletions(-)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index ba79d63..c211aa8 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1815,6 +1815,9 @@ static void aead_encrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
edesc = container_of(desc, struct aead_edesc, hw_desc[0]);
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1822,6 +1825,7 @@ static void aead_encrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
kfree(edesc);
 
+out_bklogged:
aead_request_complete(req, err);
 }
 
@@ -1837,6 +1841,9 @@ static void aead_decrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
edesc = container_of(desc, struct aead_edesc, hw_desc[0]);
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1850,6 +1857,7 @@ static void aead_decrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
kfree(edesc);
 
+out_bklogged:
aead_request_complete(req, err);
 }
 
@@ -1864,10 +1872,12 @@ static void ablkcipher_encrypt_done(struct device 
*jrdev, u32 *desc, u32 err,
 
dev_err(jrdev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
 #endif
-
edesc = (struct ablkcipher_edesc *)((char *)desc -
 offsetof(struct ablkcipher_edesc, hw_desc));
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1883,6 +1893,7 @@ static void ablkcipher_encrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
ablkcipher_unmap(jrdev, edesc, req);
kfree(edesc);
 
+out_bklogged:
ablkcipher_request_complete(req, err);
 }
 
@@ -1900,6 +1911,9 @@ static void ablkcipher_decrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
 
edesc = (struct ablkcipher_edesc *)((char *)desc -
 offsetof(struct ablkcipher_edesc, hw_desc));
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1915,6 +1929,7 @@ static void ablkcipher_decrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
ablkcipher_unmap(jrdev, edesc, req);
kfree(edesc);
 
+out_bklogged:
ablkcipher_request_complete(req, err);
 }
 
@@ -2294,7 +2309,15 @@ static int gcm_encrypt(struct aead_request *req)
 #endif
 
desc = edesc->hw_desc;
-   ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req);
+   if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) {
+   ret = caam_jr_enqueue_bklog(jrdev, desc, aead_encrypt_done,
+   req);
+   

[RFC][PATCH 8/9] zram: use crypto API for compression

[Sergey Senozhatsky]

Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram if needed. Without this work,
we cannot utilize various compression algorithms in the system.
Moreover, to add new compression algorithm, we need to know how to use it
and this is somewhat time-consuming.

When I tested new algorithms such as zlib, these problems make me hard
to test them. To prevent these problem in the future, I think that
using crypto API for compression is better approach and this patch
implements it.

The reason we need to support vairous compression algorithms is that
zram's performance is highly depend on workload and compression algorithm
and architecture. Every compression algorithm has it's own strong point.
For example, zlib is the best for compression ratio, but, it's
(de)compression speed is rather slow. Against my expectation, in my kernel
build test with zram swap, in low-memory condition on x86, zlib shows best
performance than others. In this case, I guess that compression ratio is
the most important factor. Unlike this situation, on ARM, maybe fast
(de)compression speed is the most important because it's computation speed
is slower than x86.

We can't expect what algorithm is the best fit for one's system, because
it needs too complex calculation. We need to test it in case by case and
easy to use new compression algorithm by this patch will help
that situation.

There is one problem that crypto API requires tfm object to (de)compress
something and zram abstract it on zstrm which is very limited resource.
If number of zstrm is set to low and is contended, zram's performace could
be down-graded due to this change. But, following patch support to use
crypto decompress_noctx API and would restore the performance as is.

Signed-off-by: Joonsoo Kim 
---
 drivers/block/zram/Kconfig |  8 +++
 drivers/block/zram/Makefile|  4 +---
 drivers/block/zram/zcomp.c | 54 +++---
 drivers/block/zram/zcomp.h | 30 ++-
 drivers/block/zram/zcomp_lz4.c | 47 
 drivers/block/zram/zcomp_lz4.h | 17 -
 drivers/block/zram/zcomp_lzo.c | 47 
 drivers/block/zram/zcomp_lzo.h | 17 -
 drivers/block/zram/zram_drv.c  |  6 ++---
 9 files changed, 44 insertions(+), 186 deletions(-)
 delete mode 100644 drivers/block/zram/zcomp_lz4.c
 delete mode 100644 drivers/block/zram/zcomp_lz4.h
 delete mode 100644 drivers/block/zram/zcomp_lzo.c
 delete mode 100644 drivers/block/zram/zcomp_lzo.h

diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index 386ba3d..7619bed 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -1,8 +1,7 @@
 config ZRAM
tristate "Compressed RAM block device support"
depends on BLOCK && SYSFS && ZSMALLOC
-   select LZO_COMPRESS
-   select LZO_DECOMPRESS
+   select CRYPTO_LZO
default n
help
  Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
@@ -18,9 +17,8 @@ config ZRAM
 config ZRAM_LZ4_COMPRESS
bool "Enable LZ4 algorithm support"
depends on ZRAM
-   select LZ4_COMPRESS
-   select LZ4_DECOMPRESS
+   select CRYPTO_LZ4
default n
help
  This option enables LZ4 compression algorithm support. Compression
- algorithm can be changed using `comp_algorithm' device attribute.
\ No newline at end of file
+ algorithm can be changed using `comp_algorithm' device attribute.
diff --git a/drivers/block/zram/Makefile b/drivers/block/zram/Makefile
index be0763f..9e2b79e 100644
--- a/drivers/block/zram/Makefile
+++ b/drivers/block/zram/Makefile
@@ -1,5 +1,3 @@
-zram-y :=  zcomp_lzo.o zcomp.o zram_drv.o
-
-zram-$(CONFIG_ZRAM_LZ4_COMPRESS) += zcomp_lz4.o
+zram-y :=  zcomp.o zram_drv.o
 
 obj-$(CONFIG_ZRAM) +=  zram.o
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index e3016da..6219d4d 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -15,10 +15,6 @@
 #include 
 
 #include "zcomp.h"
-#include "zcomp_lzo.h"
-#ifdef CONFIG_ZRAM_LZ4_COMPRESS
-#include "zcomp_lz4.h"
-#endif
 
 /*
  * single zcomp_strm backend
@@ -43,19 +39,20 @@ struct zcomp_strm_multi {
wait_queue_head_t strm_wait;
 };
 
-static struct zcomp_backend *backends[] = {
-   _lzo,
+static const char * const backends[] = {
+   "lzo",
 #ifdef CONFIG_ZRAM_LZ4_COMPRESS
-   _lz4,
+   "lz4",
 #endif
NULL
 };
 
-static struct zcomp_backend *find_backend(const char *compress)
+static const char *find_backend(const char *compress)
 {
int i = 0;
while (backends[i]) {
-   if (sysfs_streq(compress, backends[i]->name))
+   if (sysfs_streq(compress, backends[i]) &&
+   

[PATCH v2 2/2] crypto: akcipher - Changes to asymmetric key API

[Tadeusz Struk]

Setkey function has been split into set_priv_key and set_pub_key.
Akcipher requests takes sgl for src and dst instead of void *.
Users of the API i.e. two existing RSA implementation and
test mgr code have been updated accordingly.

Signed-off-by: Tadeusz Struk 
---
 crypto/Makefile   |9 +
 crypto/rsa.c  |  188 ++
 crypto/rsa_helper.c   |   42 +++-
 crypto/rsakey.asn1|5 
 crypto/rsaprivkey.asn1|   11 +
 crypto/rsapubkey.asn1 |4 
 crypto/testmgr.c  |   40 ++--
 crypto/testmgr.h  |   36 +++
 drivers/crypto/qat/qat_common/Makefile|   12 +
 drivers/crypto/qat/qat_common/qat_asym_algs.c |  225 +++--
 drivers/crypto/qat/qat_common/qat_rsakey.asn1 |5 
 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1 |   11 +
 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1  |4 
 include/crypto/akcipher.h |   99 ++---
 include/crypto/internal/rsa.h |7 -
 15 files changed, 519 insertions(+), 179 deletions(-)
 delete mode 100644 crypto/rsakey.asn1
 create mode 100644 crypto/rsaprivkey.asn1
 create mode 100644 crypto/rsapubkey.asn1
 delete mode 100644 drivers/crypto/qat/qat_common/qat_rsakey.asn1
 create mode 100644 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1
 create mode 100644 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1

diff --git a/crypto/Makefile b/crypto/Makefile
index e2c5981..d897e0b 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -31,10 +31,13 @@ obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
 obj-$(CONFIG_CRYPTO_PCOMP2) += pcompress.o
 obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o
 
-$(obj)/rsakey-asn1.o: $(obj)/rsakey-asn1.c $(obj)/rsakey-asn1.h
-clean-files += rsakey-asn1.c rsakey-asn1.h
+$(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
+$(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
+clean-files += rsapubkey-asn1.c rsapubkey-asn1.h
+clean-files += rsaprivkey-asn1.c rsaprivkey-asn1.h
 
-rsa_generic-y := rsakey-asn1.o
+rsa_generic-y := rsapubkey-asn1.o
+rsa_generic-y += rsaprivkey-asn1.o
 rsa_generic-y += rsa.o
 rsa_generic-y += rsa_helper.o
 obj-$(CONFIG_CRYPTO_RSA) += rsa_generic.o
diff --git a/crypto/rsa.c b/crypto/rsa.c
index 466003e..fdf837b 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * RSAEP function [RFC3447 sec 5.1.1]
@@ -80,34 +81,57 @@ static int rsa_enc(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const struct rsa_key *pkey = rsa_get_key(tfm);
MPI m, c = mpi_alloc(0);
+   int src_len = sg_len(req->src), dst_len = sg_len(req->dst);
int ret = 0;
int sign;
 
if (!c)
return -ENOMEM;
 
-   if (unlikely(!pkey->n || !pkey->e)) {
+   if (unlikely(!pkey->n || !pkey->e || !src_len)) {
ret = -EINVAL;
goto err_free_c;
}
 
-   if (req->dst_len < mpi_get_size(pkey->n)) {
-   req->dst_len = mpi_get_size(pkey->n);
+   if (dst_len < mpi_get_size(pkey->n)) {
+   req->out_len = mpi_get_size(pkey->n);
ret = -EOVERFLOW;
goto err_free_c;
}
 
-   m = mpi_read_raw_data(req->src, req->src_len);
-   if (!m) {
-   ret = -ENOMEM;
-   goto err_free_c;
+   ret = -ENOMEM;
+   if (sg_is_last(req->src)) {
+   m = mpi_read_raw_data(sg_virt(req->src), src_len);
+   } else {
+   void *ptr = kmalloc(src_len, GFP_KERNEL);
+
+   if (!ptr)
+   goto err_free_c;
+
+   scatterwalk_map_and_copy(ptr, req->src, 0, src_len, 0);
+   m = mpi_read_raw_data(ptr, src_len);
+   kfree(ptr);
}
+   if (!m)
+   goto err_free_c;
 
ret = _rsa_enc(pkey, c, m);
if (ret)
goto err_free_m;
 
-   ret = mpi_read_buffer(c, req->dst, req->dst_len, >dst_len, );
+   if (sg_is_last(req->dst)) {
+   ret = mpi_read_buffer(c, sg_virt(req->dst), dst_len,
+ >out_len, );
+   } else {
+   void *ptr = kmalloc(dst_len, GFP_KERNEL);
+
+   if (!ptr)
+   goto err_free_m;
+
+   ret = mpi_read_buffer(c, ptr, dst_len, >out_len, );
+   scatterwalk_map_and_copy(ptr, req->dst, 0, dst_len, 1);
+   kfree(ptr);
+   }
if (ret)
goto err_free_m;
 
@@ -128,34 +152,57 @@ static int rsa_dec(struct akcipher_request *req)
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
const 

[PATCH v2 1/2] lib/scatterlist: Add sg_len helper

[Tadeusz Struk]

Add sg_len function which returns the total number of bytes in sg.

Signed-off-by: Tadeusz Struk 
---
 include/linux/scatterlist.h |1 +
 lib/scatterlist.c   |   18 ++
 2 files changed, 19 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..1ca63bd 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -242,6 +242,7 @@ static inline void *sg_virt(struct scatterlist *sg)
 }
 
 int sg_nents(struct scatterlist *sg);
+int sg_len(struct scatterlist *sg);
 int sg_nents_for_len(struct scatterlist *sg, u64 len);
 struct scatterlist *sg_next(struct scatterlist *);
 struct scatterlist *sg_last(struct scatterlist *s, unsigned int);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index bafa993..dc71f27 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -57,6 +57,24 @@ int sg_nents(struct scatterlist *sg)
 EXPORT_SYMBOL(sg_nents);
 
 /**
+  * sg_len - return total size of bytes in the scatterlist
+  * @sg: The scatterlist
+  *
+  * Description:
+  * Allows to know how the total size of bytes in sg, taking into acount
+  * chaining as well
+  **/
+int sg_len(struct scatterlist *sg)
+{
+   int len;
+
+   for (len = 0; sg; sg = sg_next(sg))
+   len += sg->length;
+   return len;
+}
+EXPORT_SYMBOL(sg_len);
+
+/**
  * sg_nents_for_len - return total count of entries in scatterlist
  *needed to satisfy the supplied length
  * @sg:The scatterlist

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] crypto: akcipher - Changes to asymmetric key API

[Tadeusz Struk]

This series updates the asymmetric key API.
The changes include
 - setkey function has been split into set_priv_key and set_pub_key.
 - akcipher requests takes sgl for src and dst instead of void *.
Users of the API i.e. two existing RSA implementation and
test mgr code have been updated accordingly.

First patch adds sg_len helper that returns the full length
of an sgl.
Second patch implements the API changes 

Changes in v2:
- dropped patches that checked value returned by crypto_unregister_alg
- flatten patches 4 and 6-8 from v1 into one patch.  

---

Tadeusz Struk (2):
  lib/scatterlist: Add sg_len helper
  crypto: akcipher - Changes to asymmetric key API


 crypto/Makefile   |9 +
 crypto/rsa.c  |  188 ++
 crypto/rsa_helper.c   |   42 +++-
 crypto/rsakey.asn1|5 
 crypto/rsaprivkey.asn1|   11 +
 crypto/rsapubkey.asn1 |4 
 crypto/testmgr.c  |   40 ++--
 crypto/testmgr.h  |   36 +++
 drivers/crypto/qat/qat_common/Makefile|   12 +
 drivers/crypto/qat/qat_common/qat_asym_algs.c |  225 +++--
 drivers/crypto/qat/qat_common/qat_rsakey.asn1 |5 
 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1 |   11 +
 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1  |4 
 include/crypto/akcipher.h |   99 ++---
 include/crypto/internal/rsa.h |7 -
 include/linux/scatterlist.h   |1 
 lib/scatterlist.c |   18 ++
 17 files changed, 538 insertions(+), 179 deletions(-)
 delete mode 100644 crypto/rsakey.asn1
 create mode 100644 crypto/rsaprivkey.asn1
 create mode 100644 crypto/rsapubkey.asn1
 delete mode 100644 drivers/crypto/qat/qat_common/qat_rsakey.asn1
 create mode 100644 drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1
 create mode 100644 drivers/crypto/qat/qat_common/qat_rsapubkey.asn1

--
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [cryptodev:master 10/29] arch/x86/crypto/sha256_ssse3_glue.c:172:19: error: 'X86_FEATURE_SHA_NI' undeclared

[Herbert Xu]

On Mon, Sep 21, 2015 at 02:01:30PM -0700, Tim Chen wrote:
>
> Thanks.  Will this patch series go in the 4.3 or 4.4 time frame?

It's for 4.4.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] lib/scatterlist: Add sg_len helper

[Stephan Mueller]

Am Montag, 21. September 2015, 16:44:14 schrieb Tadeusz Struk:

Hi Tadeusz,

>Add sg_len function which returns the total number of bytes in sg.
>
>Signed-off-by: Tadeusz Struk 
>---
> include/linux/scatterlist.h |1 +
> lib/scatterlist.c   |   18 ++
> 2 files changed, 19 insertions(+)
>
>diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
>index 556ec1e..1ca63bd 100644
>--- a/include/linux/scatterlist.h
>+++ b/include/linux/scatterlist.h
>@@ -242,6 +242,7 @@ static inline void *sg_virt(struct scatterlist *sg)
> }
>
> int sg_nents(struct scatterlist *sg);
>+int sg_len(struct scatterlist *sg);
> int sg_nents_for_len(struct scatterlist *sg, u64 len);
> struct scatterlist *sg_next(struct scatterlist *);
> struct scatterlist *sg_last(struct scatterlist *s, unsigned int);
>diff --git a/lib/scatterlist.c b/lib/scatterlist.c
>index bafa993..dc71f27 100644
>--- a/lib/scatterlist.c
>+++ b/lib/scatterlist.c
>@@ -57,6 +57,24 @@ int sg_nents(struct scatterlist *sg)
> EXPORT_SYMBOL(sg_nents);
>
> /**
>+  * sg_len - return total size of bytes in the scatterlist
>+  * @sg: The scatterlist
>+  *
>+  * Description:
>+  * Allows to know how the total size of bytes in sg, taking into acount
>+  * chaining as well
>+  **/
>+int sg_len(struct scatterlist *sg)
>+{
>+  int len;

Is there a reason why unsigned int is not used? Note, this applies to the 
users of that function too.

>+
>+  for (len = 0; sg; sg = sg_next(sg))
>+  len += sg->length;
>+  return len;
>+}
>+EXPORT_SYMBOL(sg_len);
>+
>+/**
>  * sg_nents_for_len - return total count of entries in scatterlist
>  *needed to satisfy the supplied length
>  * @sg:   The scatterlist
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: qat - VF should never trigger SBR on PH

[Tadeusz Struk]

On 09/21/2015 08:04 AM, Herbert Xu wrote:
>> Don't allow to trigger SBR from a VF running in VMM context.
>> > 
>> > Signed-off-by: Conor McLoughlin 
>> > Signed-off-by: Tadeusz Struk 
> Applied to crypto.

Thanks Herbert. Actually it's only needed for 4.3 when VF support was added.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

[Dan Streetman]

On Mon, Sep 21, 2015 at 10:26 AM, Herbert Xu
 wrote:
> On Sat, Sep 19, 2015 at 05:02:42PM -0700, Haren Myneni wrote:
>> Hi,
>>
>> This patch allows nx842 coprocessor to add CRC for compression and
>> check the computed CRC value for uncompression. Please let me know
>> if you have any comments.
>>
>> Thanks
>> Haren
>>
>> commit d0b34d2e3ed41e7ec2afdbd654f0dd7716e4d4c0
>> Author: Haren Myneni 
>> Date:   Sat Sep 12 01:20:51 2015 -0700
>>
>> crypto/nx842: Add CRC and validation support
>>
>> This patch adds CRC generation and validation support for nx-842.
>> Add CRC flag so that nx842 coprocessor includes CRC during
>> compression and validates during uncompression.
>>
>> Signed-off-by: Haren Myneni 
>
> In future please post the patch without all the metadata.  You
> can use the helper git format-patch to help you prepare the patch
> for submission.
>
> As to the CRC itself what is the purpose of this and wouldn't it
> fail our test vectors if we had any? Remember that we also have a
> software implementation now and the hardware should produce exactly
> the same output as the software version.

As far as the hw and sw drivers producing the exact same output, I
don't think that's possible with the current hw and sw drivers,
because the hw driver may have to add a header to the actual byte
stream that the hw creates, depending on buffer alignment and size
(the hw has specific restrictions).  Currently, the sw driver doesn't
understand that header that the 842 hw driver creates, although that
could be added to the sw driver.  And, the hw driver skips adding the
header if the buffers are correctly aligned/sized, which would result
in a test vector failure if it doesn't align the buffer the same way
each time.

However, you're right that if the hw driver is doing crc checking, the
sw driver needs to be updated to make sure to add the crc to anything
it encodes, otherwise the hw driver will fail decompressing it; Haren,
you'll need to update the lib/842 code to also include crc
creation/checking.

Also, it might be a good time to add what we talked about a while ago,
to push the alignment/size restrictions into the crypto compression
layer, by adding cra_alignmask and cra_blocksize support to
crypto/compress.c.  Since the 842 hw has requirements not only for
specific alignment and min/max sizes, but also a requirement for
specific length multiple (i.e. must be !(len % 8)) it might be
worthwhile to also add a cra_sizemodulo or something like that.
However, if the common crypto alignment/size handling code allows any
alignment/size buffers (instead of just returning error for mis-sized
buffers), I think a common crypto header would need to be added in
cases of mis-sizing, which may not be appropriate for common code.
Alternately, the common crypto code could just return error for
mis-sized buffers; users of the crypto comp api would just have to
check crypto_tfm_alg_blocksize() before calling.

In case I haven't said it before, I really hate how the 842 hw
requires specific alignment and sizing.  How hard is it to add support
for any alignment/size in the hw?!?


>
> Thanks,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: qat - VF should never trigger SBR on PH

[Herbert Xu]

On Fri, Sep 18, 2015 at 08:59:47AM -0700, Tadeusz Struk wrote:
> From: Conor McLoughlin 
> 
> Don't allow to trigger SBR from a VF running in VMM context.
> 
> Signed-off-by: Conor McLoughlin 
> Signed-off-by: Tadeusz Struk 

Applied to crypto.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: crc32c-pclmul: use .rodata instead of .rotata

[Herbert Xu]

On Sun, Sep 20, 2015 at 04:42:36PM +0200, Nicolas Iooss wrote:
> Module crc32c-intel uses a special read-only data section named .rotata.
> This section is defined for K_table, and its name seems to be a spelling
> mistake for .rodata.
> 
> Fixes: 473946e674eb ("crypto: crc32c-pclmul - Shrink K_table to 32-bit words")
> Signed-off-by: Nicolas Iooss 

Patch applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/38] hwrng: fix handling platform_get_irq

[Herbert Xu]

On Mon, Sep 21, 2015 at 03:33:42PM +0200, Andrzej Hajda wrote:
> The function can return negative value.
> 
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> 
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> 
> Signed-off-by: Andrzej Hajda 

Applied to crypto.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: marvell: properly handle CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests

[Herbert Xu]

On Fri, Sep 18, 2015 at 05:25:36PM +0200, Thomas Petazzoni wrote:
> The mv_cesa_queue_req() function calls crypto_enqueue_request() to
> enqueue a request. In the normal case (i.e the queue isn't full), this
> function returns -EINPROGRESS. The current Marvell CESA crypto driver
> takes this into account and cleans up the request only if an error
> occured, i.e if the return value is not -EINPROGRESS.
> 
> Unfortunately this causes problems with
> CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests. When such a request is
> passed to crypto_enqueue_request() and the queue is full,
> crypto_enqueue_request() will return -EBUSY, but will keep the request
> enqueued nonetheless. This situation was not properly handled by the
> Marvell CESA driver, which was anyway cleaning up the request in such
> a situation. When later on the request was taken out of the backlog
> and actually processed, a kernel crash occured due to the internal
> driver data structures for this structure having been cleaned up.
> 
> To avoid this situation, this commit adds a
> mv_cesa_req_needs_cleanup() helper function which indicates if the
> request needs to be cleaned up or not after a call to
> crypto_enqueue_request(). This helper allows to do the cleanup only in
> the appropriate cases, and all call sites of mv_cesa_queue_req() are
> fixed to use this new helper function.
> 
> Reported-by: Vincent Donnefort 
> Fixes: db509a45339fd ("crypto: marvell/cesa - add TDMA support")
> Cc:  # v4.2+
> Signed-off-by: Thomas Petazzoni 

Applied to crypto.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto: Remove duplicate code of SG helpers functions

[Herbert Xu]

On Fri, Sep 18, 2015 at 02:57:08PM +0200, LABBE Corentin wrote:
> Hello
> 
> This patch series try to remove some duplicate code of some SG helpers 
> functions.
> The first four patch replace custom functions by already in-tree helper 
> functions.

Patches 1-3 applied.  Patch 4 should go through the s390 tree.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/8] lib: introduce sg_nents_len_chained

[Herbert Xu]

On Fri, Sep 18, 2015 at 05:25:47PM -0400, Tony Battersby wrote:
>
> So instead of adding a new function sg_nents_len_chained(), a better
> cleanup would be:
> 1) replace the driver-specific functions with calls to sg_nents_for_len()
> 2) get rid of the "chained" variables
> 3) always call dma_map_sg()/dma_unmap_sg() for the entire scatterlist
> regardless of whether or not the scatterlist is chained
> 
> Would someone more familiar with the crypto API please confirm that my
> suggestions are correct?

Yes I think you're absolutely right Tony.  Corentin, could you
please take this opportunity to clean up those drivers so that
they simply use dma_map_sg a single time rather than over and
over again for chained SG lists?

You only have to redo patches 5-8.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/8] lib: introduce sg_nents_len_chained

[LABBE Corentin]

On Mon, Sep 21, 2015 at 10:19:17PM +0800, Herbert Xu wrote:
> On Fri, Sep 18, 2015 at 05:25:47PM -0400, Tony Battersby wrote:
> >
> > So instead of adding a new function sg_nents_len_chained(), a better
> > cleanup would be:
> > 1) replace the driver-specific functions with calls to sg_nents_for_len()
> > 2) get rid of the "chained" variables
> > 3) always call dma_map_sg()/dma_unmap_sg() for the entire scatterlist
> > regardless of whether or not the scatterlist is chained
> > 
> > Would someone more familiar with the crypto API please confirm that my
> > suggestions are correct?
> 
> Yes I think you're absolutely right Tony.  Corentin, could you
> please take this opportunity to clean up those drivers so that
> they simply use dma_map_sg a single time rather than over and
> over again for chained SG lists?

Yes I will

> 
> You only have to redo patches 5-8.
> 
> Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/crypto/nx: Add CRC and validation support for nx842

[Herbert Xu]

On Sat, Sep 19, 2015 at 05:02:42PM -0700, Haren Myneni wrote:
> Hi, 
> 
> This patch allows nx842 coprocessor to add CRC for compression and
> check the computed CRC value for uncompression. Please let me know 
> if you have any comments.
> 
> Thanks
> Haren
> 
> commit d0b34d2e3ed41e7ec2afdbd654f0dd7716e4d4c0
> Author: Haren Myneni 
> Date:   Sat Sep 12 01:20:51 2015 -0700
> 
> crypto/nx842: Add CRC and validation support
> 
> This patch adds CRC generation and validation support for nx-842. 
> Add CRC flag so that nx842 coprocessor includes CRC during 
> compression and validates during uncompression. 
> 
> Signed-off-by: Haren Myneni 

In future please post the patch without all the metadata.  You
can use the helper git format-patch to help you prepare the patch
for submission.

As to the CRC itself what is the purpose of this and wouldn't it
fail our test vectors if we had any? Remember that we also have a
software implementation now and the hardware should produce exactly
the same output as the software version.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [cryptodev:master 10/29] arch/x86/crypto/sha256_ssse3_glue.c:172:19: error: 'X86_FEATURE_SHA_NI' undeclared

[Herbert Xu]

Hi Tim:

On Fri, Sep 18, 2015 at 09:12:01AM -0700, Tim Chen wrote:
>
> It seems like Thomas has already merged the cpu id patch upstream.
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=488ca7d72d974e3c00ae73ed9f947590680bdf00
> 
> Can you merge that patch into cryptodev and re-apply?

Thanks for the heads up.  I have rebased on rc2 and reapplied your
seven patches.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC][PATCH 9/9] zram: use crypto CRYPTO_ALG_TFM_MAY_SHARE API

[Sergey Senozhatsky]

Crypto subsystem now supports CRYPTO_ALG_TFM_MAY_SHARE API that
requires special tfm_noctx. This tfm can be shared by multiple
concurrent decompress user because this API doesn't rely on this
tfm object except to fetch decompress function pointer.

Until changing to use crypto API, zram doesn't require any zstrm
on decompress so decompress is parallelized unlimitedly. But, previous
patch make zram to use crypto API and this requires one zstrm on every
decompress users so, in some zstrm contended situations, zram's
performance would be degraded.

This patch makes zram use CRYPTO_ALG_TFM_MAY_SHARE API and
restore zram's performance as the time that zram doesn't use
crypto API.

Following is zram's read performance number.

* iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
* max_stream is set to 1
* Output is in Kbytes/sec

zram-base vs zram-crypto vs zram-crypto-CRYPTO_ALG_TFM_MAY_SHARE

Read10411701.88 6426911.62  9423894.38
Re-read 10017386.62 6428218.88  1163.50

Signed-off-by: Joonsoo Kim 
Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zcomp.c | 27 +--
 drivers/block/zram/zcomp.h |  1 +
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 6219d4d..b768dc9 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -319,9 +319,14 @@ void zcomp_compress_end(struct zcomp *comp, struct 
zcomp_strm *zstrm)
zcomp_strm_release(comp, zstrm);
 }
 
-/* Never return NULL, may sleep */
+/* May return NULL, may sleep */
 struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
 {
+   struct crypto_comp *tfm = comp->tfm_noctx;
+
+   if (tfm && crypto_tfm_may_share(crypto_comp_tfm(tfm)))
+   return NULL;
+
return zcomp_strm_find(comp);
 }
 
@@ -345,12 +350,18 @@ int zcomp_decompress(struct zcomp *comp, struct 
zcomp_strm *zstrm,
unsigned int src_len, unsigned char *dst)
 {
unsigned int size = PAGE_SIZE;
+   struct crypto_comp *tfm = comp->tfm_noctx;
+
+   if (tfm && crypto_tfm_may_share(crypto_comp_tfm(tfm)))
+   return crypto_comp_decompress(tfm, src, src_len, dst, );
 
-   return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
+   return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
 }
 
 void zcomp_destroy(struct zcomp *comp)
 {
+   if (comp->tfm_noctx)
+   crypto_free_comp(comp->tfm_noctx);
comp->destroy(comp);
kfree(comp);
 }
@@ -367,6 +378,7 @@ struct zcomp *zcomp_create(const char *compress, int 
max_strm)
 {
struct zcomp *comp;
const char *backend;
+   struct crypto_comp *tfm;
int error;
 
backend = find_backend(compress);
@@ -386,5 +398,16 @@ struct zcomp *zcomp_create(const char *compress, int 
max_strm)
kfree(comp);
return ERR_PTR(error);
}
+
+   /*
+* Prepare to use crypto decompress_noctx API. One tfm is required
+* to initialize crypto algorithm properly and fetch corresponding
+* function pointer. But, it is sharable for multiple concurrent
+* decompress users.
+*/
+   tfm = crypto_alloc_comp(compress, 0, 0);
+   if (!IS_ERR(tfm))
+   comp->tfm_noctx = tfm;
+
return comp;
 }
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 4f9df8e..c76d8e4 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -26,6 +26,7 @@ struct zcomp_strm {
 /* dynamic per-device compression frontend */
 struct zcomp {
void *stream;
+   struct crypto_comp *tfm_noctx;
const char *backend;
 
struct zcomp_strm *(*strm_find)(struct zcomp *comp);
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] SP800-38F / RFC3394 key wrapping

[Stephan Mueller]

Hi,

note, patch 3 is dependent on patch https://lkml.org/lkml/2015/6/16/342

Changes v3:
* split patch for easier review
* add support for full SGL handling in decrypt by adding a "fast-forward"
function
* significant simplification of code and removal of one memcpy per round
* use of scatterwalk API throughout code and removal of self-written code
* perform a full CAVS test with all AES implementations available on X86
  (C, assembler and AES-NI)

Changes v2:
* Turn kw() into a blkcipher as suggested by Herbert Xu.
* Drop the support for user provided IV to initialize encrypt or
  for performing the verify step during decrypt.

Stephan Mueller (3):
  crypto: add key wrapping block chaining mode
  crypto: keywrap - enable compilation
  crypto: keywrap - add testmgr support

 crypto/Kconfig   |   7 +
 crypto/Makefile  |   1 +
 crypto/keywrap.c | 419 +++
 crypto/testmgr.c |  16 +++
 crypto/testmgr.h |  40 ++
 5 files changed, 483 insertions(+)
 create mode 100644 crypto/keywrap.c

-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] crypto: keywrap - enable compilation

[Stephan Mueller]

Hook keywrap source code into Kconfig and Makefile

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig  | 7 +++
 crypto/Makefile | 1 +
 2 files changed, 8 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index fc93444..7240821 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -348,6 +348,13 @@ config CRYPTO_XTS
  key size 256, 384 or 512 bits. This implementation currently
  can't handle a sectorsize which is not a multiple of 16 bytes.
 
+config CRYPTO_KEYWRAP
+   tristate "Key wrapping support"
+   select CRYPTO_BLKCIPHER
+   help
+ Support for key wrapping (NIST SP800-38F / RFC3394) without
+ padding.
+
 comment "Hash modes"
 
 config CRYPTO_CMAC
diff --git a/crypto/Makefile b/crypto/Makefile
index e2c5981..1f4e13c 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_CRYPTO_CTS) += cts.o
 obj-$(CONFIG_CRYPTO_LRW) += lrw.o
 obj-$(CONFIG_CRYPTO_XTS) += xts.o
 obj-$(CONFIG_CRYPTO_CTR) += ctr.o
+obj-$(CONFIG_CRYPTO_KEYWRAP) += keywrap.o
 obj-$(CONFIG_CRYPTO_GCM) += gcm.o
 obj-$(CONFIG_CRYPTO_CCM) += ccm.o
 obj-$(CONFIG_CRYPTO_CHACHA20POLY1305) += chacha20poly1305.o
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] crypto: keywrap - add testmgr support

[Stephan Mueller]

The testmanager code for symmetric ciphers is extended to allow
verification of the IV after a cipher operation.

In addition, test vectors for kw(aes) for encryption and decryption are
added.

Signed-off-by: Stephan Mueller 
---
 crypto/testmgr.c | 16 
 crypto/testmgr.h | 40 
 2 files changed, 56 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index fa18753..7d7bf13 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3292,6 +3292,22 @@ static const struct alg_test_desc alg_test_descs[] = {
.fips_allowed = 1,
.test = alg_test_null,
}, {
+   .alg = "kw(aes)",
+   .test = alg_test_skcipher,
+   .fips_allowed = 1,
+   .suite = {
+   .cipher = {
+   .enc = {
+   .vecs = aes_kw_enc_tv_template,
+   .count = 
ARRAY_SIZE(aes_kw_enc_tv_template)
+   },
+   .dec = {
+   .vecs = aes_kw_dec_tv_template,
+   .count = 
ARRAY_SIZE(aes_kw_dec_tv_template)
+   }
+   }
+   }
+   }, {
.alg = "lrw(aes)",
.test = alg_test_skcipher,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 64b8a80..907d409 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -23814,6 +23814,46 @@ static struct aead_testvec 
rfc7539esp_dec_tv_template[] = {
 };
 
 /*
+ * All key wrapping test vectors taken from
+ * http://csrc.nist.gov/groups/STM/cavp/documents/mac/kwtestvectors.zip
+ *
+ * Note: as documented in keywrap.c, the ivout for encryption is the first
+ * semiblock of the ciphertext from the test vector. For decryption, iv is
+ * the first semiblock of the ciphertext.
+ */
+static struct cipher_testvec aes_kw_enc_tv_template[] = {
+   {
+   .key= "\x75\x75\xda\x3a\x93\x60\x7c\xc2"
+ "\xbf\xd8\xce\xc7\xaa\xdf\xd9\xa6",
+   .klen   = 16,
+   .input  = "\x42\x13\x6d\x3c\x38\x4a\x3e\xea"
+ "\xc9\x5a\x06\x6f\xd2\x8f\xed\x3f",
+   .ilen   = 16,
+   .result = "\xf6\x85\x94\x81\x6f\x64\xca\xa3"
+ "\xf5\x6f\xab\xea\x25\x48\xf5\xfb",
+   .rlen   = 16,
+   .iv_out = "\x03\x1f\x6b\xd7\xe6\x1e\x64\x3d",
+   },
+};
+
+static struct cipher_testvec aes_kw_dec_tv_template[] = {
+   {
+   .key= "\x80\xaa\x99\x73\x27\xa4\x80\x6b"
+ "\x6a\x7a\x41\xa5\x2b\x86\xc3\x71"
+ "\x03\x86\xf9\x32\x78\x6e\xf7\x96"
+ "\x76\xfa\xfb\x90\xb8\x26\x3c\x5f",
+   .klen   = 32,
+   .input  = "\xd3\x3d\x3d\x97\x7b\xf0\xa9\x15"
+ "\x59\xf9\x9c\x8a\xcd\x29\x3d\x43",
+   .ilen   = 16,
+   .result = "\x0a\x25\x6b\xa7\x5c\xfa\x03\xaa"
+ "\xa0\x2b\xa9\x42\x03\xf1\x5b\xaa",
+   .rlen   = 16,
+   .iv = "\x42\x3c\x96\x0d\x8a\x2a\xc4\xc1",
+   },
+};
+
+/*
  * ANSI X9.31 Continuous Pseudo-Random Number Generator (AES mode)
  * test vectors, taken from Appendix B.2.9 and B.2.10:
  * http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf
-- 
2.4.3


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] crypto: add key wrapping block chaining mode

[Stephan Mueller]

This patch implements the AES key wrapping as specified in
NIST SP800-38F and RFC3394.

The implementation covers key wrapping without padding.

IV handling: The caller does not provide an IV for encryption,
but must obtain the IV after encryption which would serve as the first
semblock in the ciphertext structure defined by SP800-38F. Conversely,
for decryption, the caller must provide the first semiblock of the data
as the IV and the following blocks as ciphertext.

The key wrapping is an authenticated decryption operation. The caller
will receive EBADMSG during decryption if the authentication failed.

Albeit the standards define the key wrapping for AES only, the template
can be used with any other block cipher that has a block size of 16
bytes. During initialization of the template, that condition is checked.
Any cipher not having a block size of 16 bytes will cause the
initialization to fail.

Signed-off-by: Stephan Mueller 
---
 crypto/keywrap.c | 419 +++
 1 file changed, 419 insertions(+)
 create mode 100644 crypto/keywrap.c

diff --git a/crypto/keywrap.c b/crypto/keywrap.c
new file mode 100644
index 000..b1d106c
--- /dev/null
+++ b/crypto/keywrap.c
@@ -0,0 +1,419 @@
+/*
+ * Key Wrapping: RFC3394 / NIST SP800-38F
+ *
+ * Copyright (C) 2015, Stephan Mueller 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions.  (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+/*
+ * Note for using key wrapping:
+ *
+ * * The result of the encryption operation is the ciphertext starting
+ *   with the 2nd semiblock. The first semiblock is provided as the IV.
+ *   The IV used to start the encryption operation is the default IV.
+ *
+ * * The input for the decryption is the first semiblock handed in as an
+ *   IV. The ciphertext is the data starting with the 2nd semiblock. The
+ *   return code of the decryption operation will be EBADMSG in case an
+ *   integrity error occurs.
+ *
+ * To obtain the full result of an encryption as expected by SP800-38F, the
+ * caller must allocate a buffer of plaintext + 8 bytes:
+ *
+ * unsigned int datalen = ptlen + crypto_skcipher_ivsize(tfm);
+ * u8 data[datalen];
+ * u8 *iv = data;
+ * u8 *pt = data + crypto_skcipher_ivsize(tfm);
+ * 
+ * sg_init_one(, ptdata, ptlen);
+ * skcipher_request_set_crypt(req, , , ptlen, iv);
+ *
+ * ==> After encryption, data now contains full KW result as per SP800-38F.
+ *
+ * In case of decryption, ciphertext now already has the expected length
+ * and must be segmented appropriately:
+ *
+ * unsigned int datalen = CTLEN;
+ * u8 data[datalen];
+ * 
+ * u8 *iv = data;
+ * u8 *ct = data + crypto_skcipher_ivsize(tfm);
+ * unsigned int ctlen = datalen - crypto_skcipher_ivsize(tfm);
+ * sg_init_one(, ctdata, ctlen);
+ * skcipher_request_set_crypt(req, , , ptlen, iv);
+ *
+ * ==> After decryption (which hopefully does not return EBADMSG), the ct
+ * pointer now points to the plaintext of size ctlen.
+ *
+ * Note 2: KWP is not implemented as this would defy in-place operation.
+ *If somebody wants to wrap non-aligned data, 

Re: [cryptodev:master 10/29] arch/x86/crypto/sha256_ssse3_glue.c:172:19: error: 'X86_FEATURE_SHA_NI' undeclared

[Tim Chen]

On Mon, 2015-09-21 at 22:02 +0800, Herbert Xu wrote:
> Hi Tim:
> 
> On Fri, Sep 18, 2015 at 09:12:01AM -0700, Tim Chen wrote:
> >
> > It seems like Thomas has already merged the cpu id patch upstream.
> > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=488ca7d72d974e3c00ae73ed9f947590680bdf00
> > 
> > Can you merge that patch into cryptodev and re-apply?
> 
> Thanks for the heads up.  I have rebased on rc2 and reapplied your
> seven patches.

Herbert,

Thanks.  Will this patch series go in the 4.3 or 4.4 time frame?

Tim

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: marvell: properly handle CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests

[Vincent Donnefort]

Hi Thomas,

Your patch fixes the problem on my side.

Tested-by: Vincent Donnefort 

On Fri, Sep 18, 2015 at 05:25:36PM +0200, Thomas Petazzoni wrote:
> The mv_cesa_queue_req() function calls crypto_enqueue_request() to
> enqueue a request. In the normal case (i.e the queue isn't full), this
> function returns -EINPROGRESS. The current Marvell CESA crypto driver
> takes this into account and cleans up the request only if an error
> occured, i.e if the return value is not -EINPROGRESS.
> 
> Unfortunately this causes problems with
> CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests. When such a request is
> passed to crypto_enqueue_request() and the queue is full,
> crypto_enqueue_request() will return -EBUSY, but will keep the request
> enqueued nonetheless. This situation was not properly handled by the
> Marvell CESA driver, which was anyway cleaning up the request in such
> a situation. When later on the request was taken out of the backlog
> and actually processed, a kernel crash occured due to the internal
> driver data structures for this structure having been cleaned up.
> 
> To avoid this situation, this commit adds a
> mv_cesa_req_needs_cleanup() helper function which indicates if the
> request needs to be cleaned up or not after a call to
> crypto_enqueue_request(). This helper allows to do the cleanup only in
> the appropriate cases, and all call sites of mv_cesa_queue_req() are
> fixed to use this new helper function.
> 
> Reported-by: Vincent Donnefort 
> Fixes: db509a45339fd ("crypto: marvell/cesa - add TDMA support")
> Cc:  # v4.2+
> Signed-off-by: Thomas Petazzoni 
> ---
>  drivers/crypto/marvell/cesa.h   | 27 +++
>  drivers/crypto/marvell/cipher.c |  7 +++
>  drivers/crypto/marvell/hash.c   |  8 +++-
>  3 files changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
> index b60698b..bc2a55b 100644
> --- a/drivers/crypto/marvell/cesa.h
> +++ b/drivers/crypto/marvell/cesa.h
> @@ -687,6 +687,33 @@ static inline u32 mv_cesa_get_int_mask(struct 
> mv_cesa_engine *engine)
>  
>  int mv_cesa_queue_req(struct crypto_async_request *req);
>  
> +/*
> + * Helper function that indicates whether a crypto request needs to be
> + * cleaned up or not after being enqueued using mv_cesa_queue_req().
> + */
> +static inline int mv_cesa_req_needs_cleanup(struct crypto_async_request *req,
> + int ret)
> +{
> + /*
> +  * The queue still had some space, the request was queued
> +  * normally, so there's no need to clean it up.
> +  */
> + if (ret == -EINPROGRESS)
> + return false;
> +
> + /*
> +  * The queue had not space left, but since the request is
> +  * flagged with CRYPTO_TFM_REQ_MAY_BACKLOG, it was added to
> +  * the backlog and will be processed later. There's no need to
> +  * clean it up.
> +  */
> + if (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)
> + return false;
> +
> + /* Request wasn't queued, we need to clean it up */
> + return true;
> +}
> +
>  /* TDMA functions */
>  
>  static inline void mv_cesa_req_dma_iter_init(struct mv_cesa_dma_iter *iter,
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 0745cf3..3df2f4e 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -189,7 +189,6 @@ static inline void mv_cesa_ablkcipher_prepare(struct 
> crypto_async_request *req,
>  {
>   struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
>   struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
> -
>   creq->req.base.engine = engine;
>  
>   if (creq->req.base.type == CESA_DMA_REQ)
> @@ -431,7 +430,7 @@ static int mv_cesa_des_op(struct ablkcipher_request *req,
>   return ret;
>  
>   ret = mv_cesa_queue_req(>base);
> - if (ret && ret != -EINPROGRESS)
> + if (mv_cesa_req_needs_cleanup(>base, ret))
>   mv_cesa_ablkcipher_cleanup(req);
>  
>   return ret;
> @@ -551,7 +550,7 @@ static int mv_cesa_des3_op(struct ablkcipher_request *req,
>   return ret;
>  
>   ret = mv_cesa_queue_req(>base);
> - if (ret && ret != -EINPROGRESS)
> + if (mv_cesa_req_needs_cleanup(>base, ret))
>   mv_cesa_ablkcipher_cleanup(req);
>  
>   return ret;
> @@ -693,7 +692,7 @@ static int mv_cesa_aes_op(struct ablkcipher_request *req,
>   return ret;
>  
>   ret = mv_cesa_queue_req(>base);
> - if (ret && ret != -EINPROGRESS)
> + if (mv_cesa_req_needs_cleanup(>base, ret))
>   mv_cesa_ablkcipher_cleanup(req);
>  
>   return ret;
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index ae9272e..e8d0d71 100644
> --- a/drivers/crypto/marvell/hash.c
>