Re: [PATCH v2 2/4] crypto: aesni - Enable one-sided zero copy for gcm(aes) request buffers

[Stephan Mueller]

Am Dienstag, 23. Januar 2018, 21:19:14 CET schrieb Junaid Shahid:

Hi Junaid,

> gcmaes_encrypt/decrypt perform zero-copy crypto if both the source and
> destination satisfy certain conditions (single sglist entry located in
> low-mem or within a single high-mem page). But two copies are done
> otherwise, even if one of source or destination still satisfies the
> zero-copy conditions. This optimization is now extended to avoid the
> copy on the side that does satisfy the zero-copy conditions.

The patch I pointed you and you nicely integrated was accepted by Herbert into 
the current tree. This implies that your patch will not apply cleanly any 
more.

May I suggest to rebase it to the current code?

Ciao
Stephan

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Benjamin Warnke]

Hi,

I modified my code as suggested by Stephan and Eric.

Moving the code from the header files into *.c source files slowed down the 
compression and decompression speed by a factor of up to 20.
I made no changes to the code itself, that would explain, why it is so much 
slower.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>

---
 crypto/Kconfig|   8 +
 crypto/Makefile   |   1 +
 crypto/zbewalgo.c | 208 
 include/linux/zbewalgo.h  |  59 +
 lib/Kconfig   |   3 +
 lib/Makefile  |   1 +
 lib/zbewalgo/BWT.c| 111 +
 lib/zbewalgo/BWT.h|  34 +++
 lib/zbewalgo/JBE.c| 131 ++
 lib/zbewalgo/JBE.h|  26 ++
 lib/zbewalgo/JBE2.c   | 135 +++
 lib/zbewalgo/JBE2.h   |  26 ++
 lib/zbewalgo/MTF.c|  98 
 lib/zbewalgo/MTF.h|  26 ++
 lib/zbewalgo/Makefile |   4 +
 lib/zbewalgo/RLE.c| 130 ++
 lib/zbewalgo/RLE.h|  26 ++
 lib/zbewalgo/bewalgo.c| 369 +
 lib/zbewalgo/bewalgo.h|  26 ++
 lib/zbewalgo/bewalgo2.c   | 385 ++
 lib/zbewalgo/bewalgo2.h   |  26 ++
 lib/zbewalgo/bitshuffle.c | 101 
 lib/zbewalgo/bitshuffle.h |  26 ++
 lib/zbewalgo/huffman.c| 227 ++
 lib/zbewalgo/huffman.h|  26 ++
 lib/zbewalgo/include.h| 106 +
 lib/zbewalgo/zbewalgo.c   | 590 ++
 27 files changed, 2909 insertions(+)
 create mode 100644 crypto/zbewalgo.c
 create mode 100644 include/linux/zbewalgo.h
 create mode 100644 lib/zbewalgo/BWT.c
 create mode 100644 lib/zbewalgo/BWT.h
 create mode 100644 lib/zbewalgo/JBE.c
 create mode 100644 lib/zbewalgo/JBE.h
 create mode 100644 lib/zbewalgo/JBE2.c
 create mode 100644 lib/zbewalgo/JBE2.h
 create mode 100644 lib/zbewalgo/MTF.c
 create mode 100644 lib/zbewalgo/MTF.h
 create mode 100644 lib/zbewalgo/Makefile
 create mode 100644 lib/zbewalgo/RLE.c
 create mode 100644 lib/zbewalgo/RLE.h
 create mode 100644 lib/zbewalgo/bewalgo.c
 create mode 100644 lib/zbewalgo/bewalgo.h
 create mode 100644 lib/zbewalgo/bewalgo2.c
 create mode 100644 lib/zbewalgo/bewalgo2.h
 create mode 100644 lib/zbewalgo/bitshuffle.c
 create mode 100644 lib/zbewalgo/bitshuffle.h
 create mode 100644 lib/zbewalgo/huffman.c
 create mode 100644 lib/zbewalgo/huffman.h
 create mode 100644 lib/zbewalgo/include.h
 create mode 100644 lib/zbewalgo/zbewalgo.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index b44c0ae04..f63f543e9 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1667,6 +1667,14 @@ 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 algorithm.
+
 config CRYPTO_LZ4HC
tristate "LZ4HC compression algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index cdbc03b35..2a42fb289 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -121,6 +121,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/zbewalgo.c b/crypto/zbewalgo.c
new file mode 100644
index 0..3d12f9cdf
--- /dev/null
+++ b/crypto/zbewalgo.c
@@ -0,0 +1,208 @@
+/*
+ * Cryptographic API.
+ *
+ * Copyright (c) 2018 Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "linux/zbewalgo.h"
+
+
+struct zbewalgo_ctx {
+   void *zbewalgo_comp_mem;
+};
+
+static void *zbewalgo_alloc_ctx(struct crypto_scomp *tfm)
+{
+   void *ctx;
+
+   ctx = vmalloc(zbewalgo_get_wrkmem_size());
+   if (!ctx)
+   return ERR_PTR(-ENOMEM);
+   return ctx;
+}
+
+static int zbewalgo_init(struct crypto_tfm *tfm)
+{
+   struct zbewalgo_ctx *ctx = crypto_tfm_ctx(tfm);
+
+   ctx->zbewalgo_comp_mem = 

Re: [PATCH] tls: Add support for encryption using async offload accelerator

[Gilad Ben-Yossef]

On Wed, Jan 31, 2018 at 8:10 AM, Gilad Ben-Yossef  wrote:
> Hi Vakul,
>
> On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg  wrote:
>> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading
>> GCM operation. If they are enabled, crypto_aead_encrypt() return error
>> code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a
>> completion till the time the response for crypto offload request is
>> received.
>>
>
> Thank you for this patch. I think it is actually a bug fix and should
> probably go into stable

On second though in stable we should probably just disable async tfm
allocations.
It's simpler. But this approach is still good for -next


Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH] tls: Add support for encryption using async offload accelerator

[Gilad Ben-Yossef]

Hi Vakul,

On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg  wrote:
> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading
> GCM operation. If they are enabled, crypto_aead_encrypt() return error
> code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a
> completion till the time the response for crypto offload request is
> received.
>

Thank you for this patch. I think it is actually a bug fix and should
probably go into stable
since I believe current code is broken on machines where any async GCM
transformation
is registered with a high enough priority as it will try to call a
NULL callback.

But, please use the new crypto_wait_req() and friends to implement the waiting.
Take a look at the code example in
Documentation/crypto/api-samples.rst to see how.

Also, maybe add an explanation why  CRYPTO_TFM_REQ_MAY_BACKLOG
flag should not be used here, if this was on purpose?

I mean I'm not sure using backlog here is a good idea but probably
should explain why
not.

Thanks!
Gilad


> Signed-off-by: Vakul Garg 
> ---
>  net/tls/tls_sw.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 73d19210dd49..390e6dc7b135 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -39,6 +39,11 @@
>
>  #include 
>
> +struct crypto_completion {
> +   struct completion comp;
> +   int result;
> +};
> +
>  static void trim_sg(struct sock *sk, struct scatterlist *sg,
> int *sg_num_elem, unsigned int *sg_size, int target_size)
>  {
> @@ -194,6 +199,14 @@ static void tls_free_both_sg(struct sock *sk)
> >sg_plaintext_size);
>  }
>
> +static void crypto_complete(struct crypto_async_request *req, int err)
> +{
> +   struct crypto_completion *x = req->data;
> +
> +   x->result = err;
> +   complete(>comp);
> +}
> +
>  static int tls_do_encryption(struct tls_context *tls_ctx,
>  struct tls_sw_context *ctx, size_t data_len,
>  gfp_t flags)
> @@ -202,6 +215,7 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
> crypto_aead_reqsize(ctx->aead_send);
> struct aead_request *aead_req;
> int rc;
> +   struct crypto_completion crypto_done;
>
> aead_req = kzalloc(req_size, flags);
> if (!aead_req)
> @@ -214,7 +228,15 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
> aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
> aead_request_set_crypt(aead_req, ctx->sg_aead_in, ctx->sg_aead_out,
>data_len, tls_ctx->iv);
> +   aead_request_set_callback(aead_req, 0, crypto_complete, _done);
> +
> +   init_completion(_done.comp);
> +
> rc = crypto_aead_encrypt(aead_req);
> +   if (rc == -EINPROGRESS) {
> +   wait_for_completion(_done.comp);
> +   rc = crypto_done.result;
> +   }
>
> ctx->sg_encrypted_data[0].offset -= tls_ctx->prepend_size;
> ctx->sg_encrypted_data[0].length += tls_ctx->prepend_size;
> --
> 2.13.6
>



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Anand Moon]

Hi Kamil,

On 30 January 2018 at 21:02, Kamil Konieczny
 wrote:
> Hi Anand,
>
> On 24.01.2018 14:04, Anand Moon wrote:
>> Hi Kamil Konieczny,
>>
>> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device.
>> using following encryption method.
>>
>> aes-cbc-essiv:sha256 128
>> aes-cbc-essiv:sha256 256
>>
>> Here is my defconfig I am using. https://pastebin.com/gF5T2stp
>>
>> Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2
>>
>> When I am trying to format the the hard drive I am getting kernel panic.
>> I have tired different option like below.
>>
>> *Please guide me in how to fix this bug*
>> [...]
>
> Sorry for late response, I was on holidays. Try latest kernel 4.15
> and turn off option:
>
> CONFIG_CRYPTO_DEV_EXYNOS_HASH=n
>
> in
>
> Cryptographic API:
> Hardware crypto devices:
> Support for Samsung Exynos HASH accelerator --> turn off
>
> You should also turn on option for software SHA256 (and maybe SHA1)
>
> This is last change in this driver,
> so maybe there is some problem with concurrent access to hardware
> by AES and HASH driver parts.
>

Thanks for your input, but I tried your suggestion on latest kernel.
but the result is the same.

How can I help trace this bug. please guide me.

Best Regards
-Anand
> --
> Best regards,
> Kamil Konieczny
> Samsung R Institute Poland
>

[PATCH] tls: Add support for encryption using async offload accelerator

[Vakul Garg]

Async crypto accelerators (e.g. drivers/crypto/caam) support offloading
GCM operation. If they are enabled, crypto_aead_encrypt() return error
code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a
completion till the time the response for crypto offload request is
received.

Signed-off-by: Vakul Garg 
---
 net/tls/tls_sw.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 73d19210dd49..390e6dc7b135 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -39,6 +39,11 @@
 
 #include 
 
+struct crypto_completion {
+   struct completion comp;
+   int result;
+};
+
 static void trim_sg(struct sock *sk, struct scatterlist *sg,
int *sg_num_elem, unsigned int *sg_size, int target_size)
 {
@@ -194,6 +199,14 @@ static void tls_free_both_sg(struct sock *sk)
>sg_plaintext_size);
 }
 
+static void crypto_complete(struct crypto_async_request *req, int err)
+{
+   struct crypto_completion *x = req->data;
+
+   x->result = err;
+   complete(>comp);
+}
+
 static int tls_do_encryption(struct tls_context *tls_ctx,
 struct tls_sw_context *ctx, size_t data_len,
 gfp_t flags)
@@ -202,6 +215,7 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
crypto_aead_reqsize(ctx->aead_send);
struct aead_request *aead_req;
int rc;
+   struct crypto_completion crypto_done;
 
aead_req = kzalloc(req_size, flags);
if (!aead_req)
@@ -214,7 +228,15 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
aead_request_set_crypt(aead_req, ctx->sg_aead_in, ctx->sg_aead_out,
   data_len, tls_ctx->iv);
+   aead_request_set_callback(aead_req, 0, crypto_complete, _done);
+
+   init_completion(_done.comp);
+
rc = crypto_aead_encrypt(aead_req);
+   if (rc == -EINPROGRESS) {
+   wait_for_completion(_done.comp);
+   rc = crypto_done.result;
+   }
 
ctx->sg_encrypted_data[0].offset -= tls_ctx->prepend_size;
ctx->sg_encrypted_data[0].length += tls_ctx->prepend_size;
-- 
2.13.6

[PATCH v3 1/5] crypto: caam: Fix null dereference at error path

[Bryan O'Donoghue]

From: Rui Miguel Silva 

caam_remove already removes the debugfs entry, so we need to remove the one
immediately before calling caam_remove.

This fix a NULL dereference at error paths is caam_probe fail.

[bod: changed name prefix to "crypto: caam: Fix .."]
[bod: added Fixes tag]

Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend
support")

Tested-by: Ryan Harkin 
Signed-off-by: Rui Miguel Silva 
Cc: "Horia Geantă" 
Cc: Aymen Sghaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: "David S. Miller" 
Cc: Lukas Auer 
Cc:  # 4.12+
Reviewed-by: Horia Geantă 
Signed-off-by: Bryan O'Donoghue 
---
 drivers/crypto/caam/ctrl.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 027e121..98986d3 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -809,9 +809,6 @@ static int caam_probe(struct platform_device *pdev)
return 0;
 
 caam_remove:
-#ifdef CONFIG_DEBUG_FS
-   debugfs_remove_recursive(ctrlpriv->dfs_root);
-#endif
caam_remove(pdev);
return ret;
 
-- 
2.7.4

[PATCH v3 0/5] Enable CAAM on i.MX7s fix TrustZone issues

[Bryan O'Donoghue]

V3:
- Added Cc: clk driver maintainers - Fabio Estevam
- Added Cc: i.MX arch maintainers - Fabio Estevam
- Removed bouncing email address for Herbert Xu

V2-resend:
- Patch 0005 lost in the ether - resending

V2:
- Endian detection is ok with TrustZone enabled Horia.
  Endian detection logic tested with TrustZone enabled. The register that
  this relies on though isn't affected by the lock-down in the first page.
  Assuming set of affected registers is actually just the 'deco' registers
  though there is no formal statement of that, that I am aware of.

- Moving of TrustZone work-around into u-boot
  This set actually doesn't need to deal with TrustZone at all now but, for
  the sake of consistency keeping thread title

  https://patchwork.ozlabs.org/patch/866460/
  https://patchwork.ozlabs.org/patch/866462/
  https://patchwork.ozlabs.org/patch/865890/

- Reworded endless loop fix to read a bit better

- Fixes to DTS additions - Rui

- Fixes to number of clocks declared - Rui

V1:
This patch-set enables CAAM on the i.MX7s and fixes a number of issues
identified with the CAAM driver and hardware when TrustZone mode is
enabled.

The first block of patches are simple bug-fixes, followed by a second block
of patches which are simple enabling patches for the i.MX7Solo - note we
aren't enabling for the i.MX7Dual since we don't have hardware to test that
out but it should be a 1:1 mapping for others to enable when appropriate.

The final block in this series implements a fix for using the CAAM when
OPTEE/TrustZone is enabled. The various details are logged in these
threads.

Link: https://github.com/OP-TEE/optee_os/issues/1408
Link: https://tinyurl.com/yam5gv9a
Link: https://patchwork.ozlabs.org/cover/865042

In simple terms, when TrustZone is active the first page of the CAAM
becomes inaccessible to Linux as it has a special 'TZ bit' associated with
it that software cannot toggle or even view AFAIK.

The patches here then

1. Detect when TrustZone is active
2. Detect if u-boot (or OPTEE) has already initialized the RNG

and loads the CAAM driver in a different way - skipping over the RNG
initialization that Linux now no-longer has permissions to carry out.

Should #1 be true but #2 not be true, driver loading stops (and Rui's patch
for the NULL pointer dereference fixes a cash on this path). If #2 is true
but #1 is not then it's a NOP as Linux has full permission to rewrite the
deco registers in the first page of CAAM registers.

Finally then if #1 and #2 are true, the fixes here allow the CAAM to come
up and for the RNG to be useable again.

Bryan O'Donoghue (1):
  crypto: caam: Fix endless loop when RNG is already initialized

Rui Miguel Silva (4):
  crypto: caam: Fix null dereference at error path
  crypto: caam: do not use mem and emi_slow clock for imx7x
  clk: imx7d: add CAAM clock
  ARM: dts: imx7s: add CAAM device node

 arch/arm/boot/dts/imx7s.dtsi| 31 +++
 drivers/clk/imx/clk-imx7d.c |  1 +
 drivers/crypto/caam/ctrl.c  | 45 -
 include/dt-bindings/clock/imx7d-clock.h |  3 ++-
 4 files changed, 61 insertions(+), 19 deletions(-)

-- 
2.7.4

[PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is already initialized

[Bryan O'Donoghue]

commit 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
handles") introduces a control when incrementing ent_delay which contains
the following comment above it:

/*
 * If either SH were instantiated by somebody else
 * (e.g. u-boot) then it is assumed that the entropy
 * parameters are properly set and thus the function
 * setting these (kick_trng(...)) is skipped.
 * Also, if a handle was instantiated, do not change
 * the TRNG parameters.
 */

This is a problem observed when sec_init() has been run in u-boot and
and TrustZone is enabled. We can fix this by instantiating all rng state
handles in u-boot but, on the Kernel side we should ensure that this
non-terminating path is dealt with.

Fixes: 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state
handles")

Reported-by: Ryan Harkin 
Cc: "Horia Geantă" 
Cc: Aymen Sghaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: "David S. Miller" 
Cc: Lukas Auer 
Cc:  # 4.12+
Signed-off-by: Bryan O'Donoghue 
---
 drivers/crypto/caam/ctrl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 98986d3..0a1e96b 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -704,7 +704,10 @@ static int caam_probe(struct platform_device *pdev)
 ent_delay);
kick_trng(pdev, ent_delay);
ent_delay += 400;
+   } else if (ctrlpriv->rng4_sh_init && inst_handles) {
+   ent_delay += 400;
}
+
/*
 * if instantiate_rng(...) fails, the loop will rerun
 * and the kick_trng(...) function will modfiy the
-- 
2.7.4

[PATCH v3 3/5] crypto: caam: do not use mem and emi_slow clock for imx7x

[Bryan O'Donoghue]

From: Rui Miguel Silva 

I.MX7x only use two clocks for the CAAM module, so make sure we do not try to
use the mem and the emi_slow clock when running in that imx7d and imx7s machine
type.

[bod: fixed minor trailing whitespace issue]

Signed-off-by: Rui Miguel Silva 
Cc: "Horia Geantă" 
Cc: Aymen Sghaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: "David S. Miller" 
Cc: Lukas Auer 
Signed-off-by: Bryan O'Donoghue 
---
 drivers/crypto/caam/ctrl.c | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0a1e96b..1f2dd6a 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -333,7 +333,8 @@ static int caam_remove(struct platform_device *pdev)
 
/* shut clocks off before finalizing shutdown */
clk_disable_unprepare(ctrlpriv->caam_ipg);
-   clk_disable_unprepare(ctrlpriv->caam_mem);
+   if (ctrlpriv->caam_mem)
+   clk_disable_unprepare(ctrlpriv->caam_mem);
clk_disable_unprepare(ctrlpriv->caam_aclk);
if (ctrlpriv->caam_emi_slow)
clk_disable_unprepare(ctrlpriv->caam_emi_slow);
@@ -462,14 +463,17 @@ static int caam_probe(struct platform_device *pdev)
}
ctrlpriv->caam_ipg = clk;
 
-   clk = caam_drv_identify_clk(>dev, "mem");
-   if (IS_ERR(clk)) {
-   ret = PTR_ERR(clk);
-   dev_err(>dev,
-   "can't identify CAAM mem clk: %d\n", ret);
-   return ret;
+   if (!of_machine_is_compatible("fsl,imx7d") &&
+   !of_machine_is_compatible("fsl,imx7s")) {
+   clk = caam_drv_identify_clk(>dev, "mem");
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   dev_err(>dev,
+   "can't identify CAAM mem clk: %d\n", ret);
+   return ret;
+   }
+   ctrlpriv->caam_mem = clk;
}
-   ctrlpriv->caam_mem = clk;
 
clk = caam_drv_identify_clk(>dev, "aclk");
if (IS_ERR(clk)) {
@@ -480,7 +484,9 @@ static int caam_probe(struct platform_device *pdev)
}
ctrlpriv->caam_aclk = clk;
 
-   if (!of_machine_is_compatible("fsl,imx6ul")) {
+   if (!of_machine_is_compatible("fsl,imx6ul") &&
+   !of_machine_is_compatible("fsl,imx7d") &&
+   !of_machine_is_compatible("fsl,imx7s")) {
clk = caam_drv_identify_clk(>dev, "emi_slow");
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
@@ -497,11 +503,13 @@ static int caam_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = clk_prepare_enable(ctrlpriv->caam_mem);
-   if (ret < 0) {
-   dev_err(>dev, "can't enable CAAM secure mem clock: %d\n",
-   ret);
-   goto disable_caam_ipg;
+   if (ctrlpriv->caam_mem) {
+   ret = clk_prepare_enable(ctrlpriv->caam_mem);
+   if (ret < 0) {
+   dev_err(>dev, "can't enable CAAM secure mem 
clock: %d\n",
+   ret);
+   goto disable_caam_ipg;
+   }
}
 
ret = clk_prepare_enable(ctrlpriv->caam_aclk);
@@ -823,7 +831,8 @@ static int caam_probe(struct platform_device *pdev)
 disable_caam_aclk:
clk_disable_unprepare(ctrlpriv->caam_aclk);
 disable_caam_mem:
-   clk_disable_unprepare(ctrlpriv->caam_mem);
+   if (ctrlpriv->caam_mem)
+   clk_disable_unprepare(ctrlpriv->caam_mem);
 disable_caam_ipg:
clk_disable_unprepare(ctrlpriv->caam_ipg);
return ret;
-- 
2.7.4

[PATCH v3 4/5] clk: imx7d: add CAAM clock

[Bryan O'Donoghue]

From: Rui Miguel Silva 

Add CAAM clock so that we could use the Cryptographic Acceleration and
Assurance Module (CAAM) hardware block.

Signed-off-by: Rui Miguel Silva 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: linux-...@vger.kernel.org
Cc: "Horia Geantă" 
Cc: Aymen Sghaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: "David S. Miller" 
Cc: Lukas Auer 
Signed-off-by: Bryan O'Donoghue 
---
 drivers/clk/imx/clk-imx7d.c | 1 +
 include/dt-bindings/clock/imx7d-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..52ab096 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = 
imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 
0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", 
"dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base 
+ 0x4230, 0);
+   clks[IMX7D_CAAM_CLK] = imx_clk_gate4("caam_clk", "ipg_root_clk", base + 
0x4240, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", 
"usb_hsic_post_div", base + 0x4420, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", 
"ahb_root_clk", base + 0x4480, 0);
clks[IMX7D_PCIE_CTRL_ROOT_CLK] = imx_clk_gate4("pcie_ctrl_root_clk", 
"pcie_ctrl_post_div", base + 0x4600, 0);
diff --git a/include/dt-bindings/clock/imx7d-clock.h 
b/include/dt-bindings/clock/imx7d-clock.h
index e2f99ae..2bc5618 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -452,5 +452,6 @@
 #define IMX7D_OCOTP_CLK439
 #define IMX7D_NAND_RAWNAND_CLK 440
 #define IMX7D_NAND_USDHC_BUS_RAWNAND_CLK 441
-#define IMX7D_CLK_END  442
+#define IMX7D_CAAM_CLK 442
+#define IMX7D_CLK_END  443
 #endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
-- 
2.7.4

[PATCH v3 5/5] ARM: dts: imx7s: add CAAM device node

[Bryan O'Donoghue]

From: Rui Miguel Silva 

Add CAAM device node to the i.MX7s device tree.

Signed-off-by: Rui Miguel Silva 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: linux-arm-ker...@lists.infradead.org
Cc: "Horia Geantă" 
Cc: Aymen Sghaier 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: "David S. Miller" 
Cc: Lukas Auer 
Signed-off-by: Bryan O'Donoghue 
---
 arch/arm/boot/dts/imx7s.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 82ad26e..e38c159 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -805,6 +805,37 @@
status = "disabled";
};
 
+   crypto: caam@3090 {
+   compatible = "fsl,sec-v4.0";
+   fsl,sec-era = <4>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x3090 0x4>;
+   ranges = <0 0x3090 0x4>;
+   interrupts = ;
+   clocks = < IMX7D_CAAM_CLK>,
+< IMX7D_AHB_CHANNEL_ROOT_CLK>;
+   clock-names = "ipg", "aclk";
+
+   sec_jr0: jr0@1000 {
+   compatible = "fsl,sec-v4.0-job-ring";
+   reg = <0x1000 0x1000>;
+   interrupts = ;
+   };
+
+   sec_jr1: jr1@2000 {
+   compatible = "fsl,sec-v4.0-job-ring";
+   reg = <0x2000 0x1000>;
+   interrupts = ;
+   };
+
+   sec_jr2: jr1@3000 {
+   compatible = "fsl,sec-v4.0-job-ring";
+   reg = <0x3000 0x1000>;
+   interrupts = ;
+   };
+   };
+
flexcan1: can@30a0 {
compatible = "fsl,imx7d-flexcan", 
"fsl,imx6q-flexcan";
reg = <0x30a0 0x1>;
-- 
2.7.4

Re: BUG: unable to handle kernel NULL pointer dereference in crypto_destroy_tfm

[Eric Biggers]

On Sat, Dec 23, 2017 at 01:58:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at 0188
> IP: crypto_destroy_tfm+0x9f/0xf0 crypto/api.c:577
> PGD 0 P4D 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 21787 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:crypto_destroy_tfm+0x9f/0xf0 crypto/api.c:577
> RSP: 0018:c9df7c40 EFLAGS: 00010293
> RAX: 8801f8518040 RBX:  RCX: 8167415f
> RDX:  RSI: 8801f8586c08 RDI: 8801f8586c00
> RBP: c9df7c60 R08:  R09: 
> R10: c9df7d20 R11: 0002 R12: 8801f8586c08
> R13: 8801f8586c00 R14:  R15: 880213fc0030
> FS:  02991940() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0188 CR3: 0301e002 CR4: 001626f0
> Call Trace:
>  crypto_free_aead include/crypto/aead.h:193 [inline]
>  crypto_rfc4106_exit_tfm+0x1a/0x20 crypto/gcm.c:895
>  crypto_aead_exit_tfm+0x18/0x20 crypto/aead.c:88
>  crypto_exit_ops crypto/api.c:315 [inline]
>  crypto_destroy_tfm+0x49/0xf0 crypto/api.c:579
>  crypto_free_aead include/crypto/aead.h:193 [inline]
>  aead_release+0x19/0x30 crypto/algif_aead.c:511
>  alg_do_release crypto/af_alg.c:119 [inline]
>  alg_sock_destruct+0x2d/0x40 crypto/af_alg.c:360
>  __sk_destruct+0x2e/0x250 net/core/sock.c:1558
>  sk_destruct+0x2f/0x60 net/core/sock.c:1593
>  __sk_free+0xbe/0xf0 net/core/sock.c:1601
>  sk_free+0x2a/0x40 net/core/sock.c:1612
>  sock_put include/net/sock.h:1653 [inline]
>  af_alg_release+0x42/0x50 crypto/af_alg.c:126
>  sock_release+0x2c/0xc0 net/socket.c:600
>  sock_close+0x16/0x20 net/socket.c:1129
>  __fput+0x120/0x270 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:243
>  task_work_run+0xa3/0xe0 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x3e6/0x1050 kernel/exit.c:869
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x18/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a09
> RSP: 002b:00a2fa08 EFLAGS: 0202 ORIG_RAX: 00e7
> RAX: ffda RBX: 0071bec8 RCX: 00452a09
> RDX:  RSI: 00722750 RDI: 
> RBP:  R08:  R09: 0852
> R10: 000c R11: 0202 R12: 00a2f9b0
> R13: 0071bea0 R14: 0519 R15: 000c
> Code: 41 ff d6 e8 04 62 c4 ff 4c 89 e7 e8 4c 8d c0 ff 4c 89 ef e8 54 fa d0
> ff e8 ef 61 c4 ff 5b 41 5c 41 5d 41 5e 5d c3 e8 e1 61 c4 ff <4c> 8b b3 88 01
> 00 00 4d 85 f6 74 32 e8 d0 61 c4 ff 4c 89 e7 41
> RIP: crypto_destroy_tfm+0x9f/0xf0 crypto/api.c:577 RSP: c9df7c40
> CR2: 0188
> ---[ end trace 51087c3b0b04438f ]---

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel paging request in aead_accept_parent_nokey

[Eric Biggers]

On Sun, Dec 17, 2017 at 09:51:01PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 41d8c16909ebda40f7b4982a7f5e2ad102705ade
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> device lo entered promiscuous mode
> BUG: unable to handle kernel paging request at fff0
> Bearer <> rejected, not supported in standalone mode
> IP: aead_accept_parent_nokey+0x2a/0x150 crypto/algif_aead.c:559
> PGD 3021067 P4D 3021067 PUD 3023067 PMD 0
> Oops:  [#1] SMP
> Bearer <> rejected, not supported in standalone mode
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 5971 Comm: syz-executor1 Not tainted 4.15.0-rc3-next-20171213+
> #66
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:aead_accept_parent_nokey+0x2a/0x150 crypto/algif_aead.c:559
> RSP: 0018:c9d7bda8 EFLAGS: 00010216
> RAX:  RBX: 88020ab17540 RCX: 816ca746
> RDX: 014000c0 RSI: 0090 RDI: 8801e2c0e800
> RBP: c9d7bdc8 R08: 0001 R09: 
> R10:  R11:  R12: 8801e2c0e800
> R13: 82a95520 R14: 880213fd5400 R15: 
> FS:  7f60fba0c700() GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: fff0 CR3: 0001e10a4000 CR4: 001426e0
> Call Trace:
>  aead_accept_parent+0x28/0x40 crypto/algif_aead.c:595
>  af_alg_accept+0x9c/0x1f0 crypto/af_alg.c:294
>  alg_accept+0x25/0x30 crypto/af_alg.c:330
>  SYSC_accept4+0x114/0x260 net/socket.c:1551
>  SyS_accept4 net/socket.c:1502 [inline]
>  SYSC_accept net/socket.c:1585 [inline]
>  SyS_accept+0x26/0x30 net/socket.c:1582
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f60fba0bc58 EFLAGS: 0212 ORIG_RAX: 002b
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX:  RSI:  RDI: 0016
> RBP: 001a R08:  R09: 
> R10:  R11: 0212 R12: 006ee310
> R13:  R14: 7f60fba0c6d4 R15: 
> Code: 00 55 48 89 e5 41 56 41 55 41 54 53 48 89 fb 49 89 f4 e8 2a fc be ff
> 48 8b 03 ba c0 00 40 01 be 90 00 00 00 4c 89 e7 48 8b 40 40 <44> 8b 68 f0 e8
> 7d a7 9d 00 48 85 c0 0f 84 ed 00 00 00 48 89 c3
> RIP: aead_accept_parent_nokey+0x2a/0x150 crypto/algif_aead.c:559 RSP:
> c9d7bda8
> CR2: fff0
> ---[ end trace 1608f1470cd99fdb ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel NULL pointer dereference in af_alg_alloc_tsgl

[Eric Biggers]

On Tue, Dec 19, 2017 at 01:03:00PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> device gre0 entered promiscuous mode
> BUG: unable to handle kernel NULL pointer dereference at 0010
> IP: af_alg_alloc_tsgl+0x3f/0x140 crypto/af_alg.c:501
> PGD 1deb48067 P4D 1deb48067 PUD 20c245067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 24829 Comm: syz-executor0 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:af_alg_alloc_tsgl+0x3f/0x140 crypto/af_alg.c:501
> RSP: 0018:c9dd7ca8 EFLAGS: 00010206
> RAX: 0001 RBX: 88021578f000 RCX: 816c6b4f
> RDX: 00b0 RSI: c90001089000 RDI: 8802156c6000
> RBP: c9dd7cc8 R08:  R09: 
> R10:  R11:  R12: 8802156c6000
> R13: 008b R14:  R15: 88021578f000
> FS:  7f9dd3068700() GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0010 CR3: 0001e26ee000 CR4: 001406e0
> Call Trace:
>  af_alg_sendmsg+0x1fa/0x580 crypto/af_alg.c:911
>  skcipher_sendmsg+0x3d/0x50 crypto/algif_skcipher.c:57
>  sock_sendmsg_nosec net/socket.c:636 [inline]
>  sock_sendmsg+0x51/0x70 net/socket.c:646
>  sock_write_iter+0xa4/0x100 net/socket.c:915
>  call_write_iter include/linux/fs.h:1776 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x15b/0x1e0 fs/read_write.c:482
>  vfs_write+0xf0/0x230 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0x57/0xd0 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f9dd3067c58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX: 008b RSI: 20f3cf75 RDI: 0015
> RBP: 001a R08:  R09: 
> R10:  R11: 0212 R12: 006ee310
> R13:  R14: 7f9dd30686d4 R15: 
> Code: 8b 9c 24 60 04 00 00 48 8b 03 4c 8b 73 08 48 39 c3 0f 84 bf 00 00 00
> e8 00 38 bf ff 49 83 fe e8 0f 84 b0 00 00 00 e8 f1 37 bf ff <41> 83 7e 10 7d
> 0f 86 8e 00 00 00 e8 e1 37 bf ff 4c 89 e7 ba c0
> RIP: af_alg_alloc_tsgl+0x3f/0x140 crypto/af_alg.c:501 RSP: c9dd7ca8
> CR2: 0010
> ---[ end trace 374ebf1f5cd68b75 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid

Re: BUG: unable to handle kernel paging request in hmac_init_tfm

[Eric Biggers]

On Mon, Dec 18, 2017 at 11:36:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> BUG: unable to handle kernel paging request at 8802dca4f748
> IP: hmac_init_tfm+0x5d/0x90 crypto/hmac.c:169
> PGD 404e067 P4D 404e067 PUD 0
> Oops: 0002 [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 6418 Comm: syz-executor5 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:hmac_init_tfm+0x5d/0x90 crypto/hmac.c:169
> RSP: 0018:c9f77df8 EFLAGS: 00010202
> RAX: 0068 RBX: 8801dca52308 RCX: 816847d3
> RDX: 05d6 RSI: c90004d7e000 RDI: 8802143cc708
> RBP: c9f77e10 R08: 0002bcf8 R09: 8802143cc700
> R10:  R11:  R12: 8802143cc700
> R13: 8802dca4f748 R14: 8801e0a96c50 R15: c9f77ed0
> FS:  7fecf7c1a700() GS:88021fd0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 8802dca4f748 CR3: 0001e47f4000 CR4: 001406e0
> DR0: 2008 DR1: 2008 DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0600
> Call Trace:
>  crypto_create_tfm+0xb4/0x120 crypto/api.c:466
>  crypto_alloc_tfm+0x82/0x180 crypto/api.c:540
>  crypto_alloc_shash+0x2c/0x40 crypto/shash.c:436
>  sctp_listen_start net/sctp/socket.c:7496 [inline]
>  sctp_inet_listen+0x1c1/0x240 net/sctp/socket.c:7584
>  SYSC_listen net/socket.c:1483 [inline]
>  SyS_listen+0x71/0xb0 net/socket.c:1469
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7fecf7c19c58 EFLAGS: 0212 ORIG_RAX: 0032
> RAX: ffda RBX: 00758020 RCX: 00452a39
> RDX:  RSI: 0ae0 RDI: 001b
> RBP: 00e8 R08:  R09: 
> R10:  R11: 0212 R12: 006ef660
> R13:  R14: 7fecf7c1a6d4 R15: 
> Code: ff 01 c0 4c 8d 6c 02 07 e8 a1 22 ff ff 49 83 e5 f8 48 3d 00 f0 ff ff
> 49 89 c4 77 25 e8 6d 5b c3 ff 41 8b 04 24 83 c0 10 89 43 f8 <4d> 89 65 00 45
> 31 e4 e8 57 5b c3 ff 44 89 e0 5b 41 5c 41 5d 5d
> RIP: hmac_init_tfm+0x5d/0x90 crypto/hmac.c:169 RSP: c9f77df8
> CR2: 8802dca4f748
> ---[ end trace ec6d3df7509d0a3b ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot config due to a change to the
kconfig menus in linux-next (so this crash was probably caused by slab
corruption elsewhere).

#syz invalid

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Benjamin Warnke]

Hi Stephan,


>>> In general: I do not think that having larger C functions in header files
>>> is a proper coding style.
>> 
>> How should I solve this?
>> 
>> Option 1:
>> Move everything in the lib/zbewalgo folder into a single source file.
>> This way there is no function defined in a header file.
>> I separated the code into different files because the different partial
>> compression algorithms are independent from each other.
>> 
>> Option 2:
>> Move each header file in its own *.c file, while keeping the
>> function-declarations in the header. If the code is scattered in multiple
>> source files each of the partial algorithms would show up as an independent
>> module. All these modules would load simultaneously with the module
>> zbewalgo_compress The module zbewalgo_compress requires an array of all
>> partial algorithms. This would spam the 'lsmod' list with unneccessary
>> details.
> 
> A module may be compiled from multiple C files. So, moving the code into 
> separate C files and link them into one object / KO should be considered.

I will start moving the code into multiple C files by tomorrow.

>>> Why are there __attribute__ ((unused)) function parameters, such as in
>>> compress_bitshuffle and others?
>> 
>> The zbewalgo algorithm is a container-algorithm for compression functions
>> with the ability to concatenate multiple algorithms. To be able to call any
>> compression algorithm the same way, I defined 'struct zbewalgo_alg' as the
>> interface for all those independent compression algorithms. Some of the
>> partial algorithms do not require all parameters. To silence compiler
>> warnings (if additional warning flags are enabled) I explicitly add the
>> 'unused'-parameter
> 
> Linux does not enable the compiler warning about unused parameters.

This is my first patch request.
I read somewhere, that the code should be compiled with additional warnings 
enabled before submission, to ensure, that the patch does not include useless 
code.
I will remove that attribute.

Benjamin

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Benjamin Warnke]

Hi Eric,

>> Currently ZRAM uses the compression-algorithms from the crypto-api.
>> None of the current compression-algorithms in the crypto-api is designed
>> to compress 4KiB chunks of data efficiently.
>> This patch adds a new compression-algorithm especially designed for ZRAM,
>> to compress small pieces of data more efficiently.
> 
> This is some interesting work, and I like the idea of doing transforms
> specialized for in-memory data.  However, where can I find more information
> about this new compression algorithm?  

I invented this algorithm during the last months for an university lecture. I 
have not published it before, that is why you can not find anything at google.

> What does "zbewalgo" even stand for /
> mean?  Googling it turns up nothing.

zbewalgo: z=zram be=Benjamin wa=Warnke algo=Algorithm

> You are going to have to be much more specific what you mean by "efficiently".
> Efficiency usually implies speed, yet even by your own numbers LZ4 is much
> faster than "zbewalgo", both for compression and decompression.

In this context efficient refers to the compression ratio.

> If the goal is to provide an algorithm more tuned for compression ratio than
> speed in comparison to LZ4, then the omission of Zstandard from your 
> benchmarks
> is strange, especially given that Zstandard is available in the kernel now.

I was not aware of Zstandard in the kernel.

#echo zstandard > /sys/block/zram0/comp_algorithm
returns 
"write error: Invalid argument"

#cat /sys/block/zram0/comp_algorithm
does not show Zstandard

I pulled the latest commit from 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
There is no CONFIG_CRYPTO_ZSTD (or similar) flag in my .config file.

How can I enable Zstandard for use within zram?

> The proposed "zbewalgo" decompressor also doesn't handle invalid inputs, which
> means it cannot be used on untrusted data.  
> This isn't acceptable without
> justification (since people may use it on untrusted data, creating security
> vulnerabilities), and it also makes it not really a fair comparison with LZ4
> since the LZ4 decompressor does handle invalid inputs, at least in the mode
> exposed through the crypto API.

Since zbewalgo is intended for use within zram, the data-source for the 
decompression algorithm is the same computer.
I assume, that the data is never corrupted in any way, because it is never 
exposed to untrusted hardware.

To catch all invalid inputs a lot of branches would be required.
Each additional if-branch in the code for handling untrusted data slows down 
the algorithm.
In the zram context only blocks of 4KiB are going to be compressed.
The zbewalgo algorithm executes multiple (de)compression steps in a row.
Each step would need to fully verify, that the data is valid, even if the 
preceding algorithm does not detect an error.
All together, the relative cpu-time cost for invalid data is high.

I could add a comment to the decompression functions, but that would not be 
visible for the final user.

Benjamin

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Stephan Müller]

Am Dienstag, 30. Januar 2018, 20:49:00 CET schrieb Benjamin Warnke:

Hi Benjamin,

> > In general: I do not think that having larger C functions in header files
> > is a proper coding style.
> 
> How should I solve this?
> 
> Option 1:
> Move everything in the lib/zbewalgo folder into a single source file.
> This way there is no function defined in a header file.
> I separated the code into different files because the different partial
> compression algorithms are independent from each other.
> 
> Option 2:
> Move each header file in its own *.c file, while keeping the
> function-declarations in the header. If the code is scattered in multiple
> source files each of the partial algorithms would show up as an independent
> module. All these modules would load simultaneously with the module
> zbewalgo_compress The module zbewalgo_compress requires an array of all
> partial algorithms. This would spam the 'lsmod' list with unneccessary
> details.

A module may be compiled from multiple C files. So, moving the code into 
separate C files and link them into one object / KO should be considered.

> 
> > Why are there __attribute__ ((unused)) function parameters, such as in
> > compress_bitshuffle and others?
> 
> The zbewalgo algorithm is a container-algorithm for compression functions
> with the ability to concatenate multiple algorithms. To be able to call any
> compression algorithm the same way, I defined 'struct zbewalgo_alg' as the
> interface for all those independent compression algorithms. Some of the
> partial algorithms do not require all parameters. To silence compiler
> warnings (if additional warning flags are enabled) I explicitly add the
> 'unused'-parameter

Linux does not enable the compiler warning about unused parameters.

Ciao
Stephan

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Eric Biggers]

Hi Benjamin,

On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote:
> Currently ZRAM uses the compression-algorithms from the crypto-api.
> None of the current compression-algorithms in the crypto-api is designed
> to compress 4KiB chunks of data efficiently.
> This patch adds a new compression-algorithm especially designed for ZRAM,
> to compress small pieces of data more efficiently.
> 

This is some interesting work, and I like the idea of doing transforms
specialized for in-memory data.  However, where can I find more information
about this new compression algorithm?  What does "zbewalgo" even stand for /
mean?  Googling it turns up nothing.

You are going to have to be much more specific what you mean by "efficiently".
Efficiency usually implies speed, yet even by your own numbers LZ4 is much
faster than "zbewalgo", both for compression and decompression.

If the goal is to provide an algorithm more tuned for compression ratio than
speed in comparison to LZ4, then the omission of Zstandard from your benchmarks
is strange, especially given that Zstandard is available in the kernel now.

The proposed "zbewalgo" decompressor also doesn't handle invalid inputs, which
means it cannot be used on untrusted data.  This isn't acceptable without
justification (since people may use it on untrusted data, creating security
vulnerabilities), and it also makes it not really a fair comparison with LZ4
since the LZ4 decompressor does handle invalid inputs, at least in the mode
exposed through the crypto API.

Eric

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Benjamin Warnke]

Hi Stephan,

thanks for your fast response.

> Please run checkpatch.pl on the patch and fix the formatting issues.

I've run checkpatch.pl again and fixed all errors and warnings except the 
warnings about printk.
Compression does not have it's own subsystem, that is why I used 
printk(KERN_INFO ...

> In general: I do not think that having larger C functions in header files is 
> a 
> proper coding style. 

How should I solve this?

Option 1:
Move everything in the lib/zbewalgo folder into a single source file.
This way there is no function defined in a header file.
I separated the code into different files because the different partial 
compression algorithms are independent from each other.

Option 2:
Move each header file in its own *.c file, while keeping the 
function-declarations in the header.
If the code is scattered in multiple source files each of the partial 
algorithms would show up as an independent module.
All these modules would load simultaneously with the module zbewalgo_compress
The module zbewalgo_compress requires an array of all partial algorithms.
This would spam the 'lsmod' list with unneccessary details.

I would prefer option 1, since it adds less overhead.

> Also, having static variables header files is also not 
> nice.

I will remove the static modifier for variables in the header files

> Do not redefine code that already exists. For example, MIN/MAX exists: min_t 
> and max_t.

Ok, I will use min_t and max_t

> Why are there __attribute__ ((unused)) function parameters, such as in 
> compress_bitshuffle and others?

The zbewalgo algorithm is a container-algorithm for compression functions with 
the ability to concatenate multiple algorithms.
To be able to call any compression algorithm the same way, I defined 'struct 
zbewalgo_alg' as the interface for all those independent compression algorithms.
Some of the partial algorithms do not require all parameters. To silence 
compiler warnings (if additional warning flags are enabled) I explicitly add 
the 'unused'-parameter

Best regards,
Benjamin

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Stephan Mueller]

Am Dienstag, 30. Januar 2018, 16:08:57 CET schrieb Benjamin Warnke:

Hi Benjamin,

Please run checkpatch.pl on the patch and fix the formatting issues.

In general: I do not think that having larger C functions in header files is a 
proper coding style. Also, having static variables header files is also not 
nice.

Do not redefine code that already exists. For example, MIN/MAX exists: min_t 
and max_t.

Why are there __attribute__ ((unused)) function parameters, such as in 
compress_bitshuffle and others?

Ciao
Stephan

Re: [RFC crypto v3 8/9] chtls: Register the ULP

[Dave Watson]

On 01/30/18 06:51 AM, Atul Gupta wrote:

> What I was referring is that passing "tls" ulp type in setsockopt
> may be insufficient to make the decision when multi HW assist Inline
> TLS solution exists.

Setting the ULP doesn't choose HW or SW implementation, I think that
should be done later when setting up crypto with 

setsockopt(SOL_TLS, TLS_TX, struct crypto_info).

Any reason we can't use ethtool to choose HW vs SW implementation, if
available on the device?

> Some HW may go beyond defining sendmsg/sendpage of the prot and
> require additional info to setup the env? Also, we need to keep
> vendor specific code out of tls_main.c i.e anything other than
> base/sw_tx prot perhaps go to hw driver.

Sure, but I think we can add hooks to tls_main to do this without a
new ULP.

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

[Jonathan Cameron]

On Tue, 30 Jan 2018 09:27:04 +0100
Stephan Müller  wrote:

> Hi Harsh,
> 
> may I as you to try the attached patch on your Chelsio driver? Please invoke 
> the following command from libkcapi:
> 
> kcapi  -d 2 -x 9  -e -c "cbc(aes)" -k 
> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i 
> 7fbc02ebf5b93322329df9bfccb635af -p 48981da18e4bb9ef7e2e3162d16b1910
> 
> The result should now be a fully block-chained result.
> 
> Note, the patch goes on top of the inline IV patch.
> 
> Thanks
> 
> ---8<---
> 
> In case of AIO where multiple IOCBs are sent to the kernel and inline IV
> is not used, the ctx->iv is used for each IOCB. The ctx->iv is read for
> the crypto operation and written back after the crypto operation. Thus,
> processing of multiple IOCBs must be serialized.
> 
> As the AF_ALG interface is used by user space, a mutex provides the
> serialization which puts the caller to sleep in case a previous IOCB
> processing is not yet finished.
> 
> If multiple IOCBs arrive that all are blocked, the mutex' FIFO operation
> of processing arriving requests ensures that the blocked IOCBs are
> unblocked in the right order.
> 
> Signed-off-by: Stephan Mueller 

As a reference point, holding outside the kernel (in at least
the case of our hardware with 8K CBC) drops us down to around 30%
of performance with separate IVs.  Putting a queue in kernel
(and hence allowing most setup of descriptors / DMA etc) gets us
up to 50% of raw non chained performance.

So whilst this will work in principle I suspect anyone who
cares about the cost will be looking at adding their own
software queuing and dependency handling in driver.  How
much that matters will depend on just how quick the hardware
is vs overheads.

Anyhow, just posted the driver as an RFC. There are a few corners
that need resolving and the outcome of this thread effects whether
we need to play games with IVs or not.

https://marc.info/?l=linux-crypto-vger=151732626428206=2
grep for softqueue.

We have a number of processing units that will grab requests
from the HW queues in parallel.  So 'lots' of requests
from a given HW queue may be in flight at the same time (the problem
case).

Logic is fairly simple.
1. Only create a softqueue if the encryption mode requires chaining.
   Currently in this driver that is CBC and CTR modes only.
   Otherwise put everything straight in the hardware monitored queues.
2. If we have an IV embedded within the request it will have a different
   address to the one used previously (guaranteed if that one is still
   in flight and it doesn't matter if it isn't).  If that occurs we
   can safely add it to the hardware queue. To avoid DoS issues against
   and earlier set of messages using the a chained IV we actually make
   sure nothing is in the software queue (not needed for correctness)
3. If IV matches previous IV and there are existing elements in SW or HW
   queues we need to hold it in the SW queue.
4. On receiving a response from the hardware and if the hardware queue
   is empty, we can release an element from the software queue into the
   hardware queue.

This maintains chaining when needed and gets a good chunk of the lost
performance back.  I believe (though yet to verify) the remaining lost
performance is mostly down to the fact we can't coalesce interrupts if
chaining.

Note the driver is deliberately a touch 'simplistic' so there may be other
optimization opportunities to get some of the lost performance back or
it may be fundamental due to the fact the raw processing can't be in
parallel.

> ---
>  crypto/af_alg.c | 22 ++
>  crypto/algif_aead.c |  2 ++
>  crypto/algif_skcipher.c |  2 ++
>  include/crypto/if_alg.h |  3 +++
>  4 files changed, 29 insertions(+)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 87394dc90ac0..3007c9d899da 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -1059,6 +1059,8 @@ void af_alg_async_cb(struct crypto_async_request *_req, 
> int err)
>   struct kiocb *iocb = areq->iocb;
>   unsigned int resultlen;
>  
> + af_alg_put_iv(sk);
> +
>   /* Buffer size written by crypto operation. */
>   resultlen = areq->outlen;
>  
> @@ -1227,6 +1229,11 @@ int af_alg_get_iv(struct sock *sk, struct 
> af_alg_async_req *areq)
>  
>   /* No inline IV or cipher has no IV, use ctx IV buffer. */
>   if (!ctx->iiv || !ctx->ivlen) {
> + int ret = mutex_lock_interruptible(>ivlock);
> +
> + if (ret)
> + return ret;
> +
>   areq->iv = ctx->iv;
>   areq->ivlen = 0;// areq->iv will not be freed
>   return 0;
> @@ -1252,6 +1259,21 @@ int af_alg_get_iv(struct sock *sk, struct 
> af_alg_async_req *areq)
>  }
>  EXPORT_SYMBOL_GPL(af_alg_get_iv);
>  
> +/**
> + * af_alg_put_iv - release lock on IV in case CTX IV is used
> + *
> + * @sk [in] AF_ALG socket
> + */
> +void af_alg_put_iv(struct 

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Kamil Konieczny]

Hi Anand,

On 24.01.2018 14:04, Anand Moon wrote:
> Hi Kamil Konieczny,
> 
> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device.
> using following encryption method.
> 
> aes-cbc-essiv:sha256 128
> aes-cbc-essiv:sha256 256
> 
> Here is my defconfig I am using. https://pastebin.com/gF5T2stp
> 
> Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2
> 
> When I am trying to format the the hard drive I am getting kernel panic.
> I have tired different option like below.
> 
> *Please guide me in how to fix this bug*
> [...]

Sorry for late response, I was on holidays. Try latest kernel 4.15
and turn off option:

CONFIG_CRYPTO_DEV_EXYNOS_HASH=n

in 

Cryptographic API: 
Hardware crypto devices:
Support for Samsung Exynos HASH accelerator --> turn off

You should also turn on option for software SHA256 (and maybe SHA1)

This is last change in this driver,
so maybe there is some problem with concurrent access to hardware
by AES and HASH driver parts.

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

[RFC PATCH 2/3] crypto: hisilicon hacv1 driver

[Jonathan Cameron]

From: Jonathan Cameron 

This accelerator is found inside hisilicon hip06 and hip07 SoCs.
Each instance provides a number of queues which feed a different number of
backend accleration units.

The queues are operating in an out of order mode in the interests of
throughput. The silicon does not do tracking of dependencies between
multiple 'messages' or update of the IVs as appropriate for training.
Hence where relevant we need to do this in software.

Signed-off-by: Jonathan Cameron 
---
 drivers/crypto/Kconfig  |2 +
 drivers/crypto/Makefile |1 +
 drivers/crypto/hisilicon/Kconfig|   16 +
 drivers/crypto/hisilicon/Makefile   |2 +
 drivers/crypto/hisilicon/sec/Makefile   |3 +
 drivers/crypto/hisilicon/sec/sec_algs.c | 1082 +++
 drivers/crypto/hisilicon/sec/sec_drv.c  | 1418 +++
 drivers/crypto/hisilicon/sec/sec_drv.h  |  282 ++
 8 files changed, 2806 insertions(+)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 47ec920d5b71..ea85924427e9 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -731,4 +731,6 @@ config CRYPTO_DEV_ARTPEC6
 
  To compile this driver as a module, choose M here.
 
+source "drivers/crypto/hisilicon/Kconfig"
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 2513d13ea2c4..ed237414ca1b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
 obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
 obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/
+obj-$(CONFIG_CRYPTO_DEV_HISILICON) += hisilicon/
diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
new file mode 100644
index ..cd9296687235
--- /dev/null
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config CRYPTO_DEV_HISILICON
+   bool
+
+config CRYPTO_DEV_HISI_SEC
+   tristate "Support for Hisilicon SEC crypto block cipher accelerator"
+   select CRYPTO_DEV_HISILICON
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_ALGAPI
+   depends on ARM64
+   help
+ Support for Hisilicon SEC Engine in Hip06 and Hip07
+
+ To compile this as a module, choose M here: the module
+ will be called hisi_sec.
diff --git a/drivers/crypto/hisilicon/Makefile 
b/drivers/crypto/hisilicon/Makefile
new file mode 100644
index ..463f46ace182
--- /dev/null
+++ b/drivers/crypto/hisilicon/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CRYPTO_DEV_HISI_SEC) += sec/
diff --git a/drivers/crypto/hisilicon/sec/Makefile 
b/drivers/crypto/hisilicon/sec/Makefile
new file mode 100644
index ..a55b698e0c27
--- /dev/null
+++ b/drivers/crypto/hisilicon/sec/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CRYPTO_DEV_HISI_SEC) += hisi_sec.o
+hisi_sec-y = sec_algs.o sec_drv.o
diff --git a/drivers/crypto/hisilicon/sec/sec_algs.c 
b/drivers/crypto/hisilicon/sec/sec_algs.c
new file mode 100644
index ..6b82636f7979
--- /dev/null
+++ b/drivers/crypto/hisilicon/sec/sec_algs.c
@@ -0,0 +1,1082 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016-2017 Hisilicon Limited. */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sec_drv.h"
+
+enum sec_cipher_type {
+   SEC_CIPHER_NULL,
+   SEC_CIPHER_ENCRYPT,
+   SEC_CIPHER_DECRYPT,
+   SEC_CIPHER_PASS,
+   SEC_CIPHER_INVALID,
+};
+
+#define SEC_C_ALG_DES  0
+#define SEC_C_ALG_3DES 1
+#define SEC_C_ALG_AES  2
+
+#define SEC_C_MODE_ECB 0
+#define SEC_C_MODE_CBC 1
+#define SEC_C_MODE_CTR 4
+#define SEC_C_MODE_CCM 5
+#define SEC_C_MODE_GCM 6
+#define SEC_C_MODE_XTS 7
+
+#define SEC_KEY_LEN_AES_1280
+#define SEC_KEY_LEN_AES_1921
+#define SEC_KEY_LEN_AES_2562
+#define SEC_KEY_LEN_DES1
+#define SEC_KEY_LEN_3DES_3_KEY 1
+#define SEC_KEY_LEN_3DES_2_KEY 3
+
+#define SEC_C_WIDTH_AES_128BIT 0
+#define SEC_C_WIDTH_AES_8BIT   1
+#define SEC_C_WIDTH_AES_1BIT   2
+#define SEC_C_WIDTH_DES_64BIT  0
+#define SEC_C_WIDTH_DES_8BIT   1
+#define SEC_C_WIDTH_DES_1BIT   2
+
+enum sec_cipher_alg {
+   SEC_DES_ECB_64,
+   SEC_DES_CBC_64,
+
+   SEC_3DES_ECB_192_3KEY,
+   SEC_3DES_ECB_192_2KEY,
+
+   SEC_3DES_CBC_192_3KEY,
+   SEC_3DES_CBC_192_2KEY,
+
+   SEC_AES_ECB_128,
+   SEC_AES_ECB_192,
+   SEC_AES_ECB_256,
+
+   SEC_AES_CBC_128,
+   SEC_AES_CBC_192,
+   SEC_AES_CBC_256,
+
+   

[RFC PATCH 3/3] arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

[Jonathan Cameron]

From: Jonathan Cameron 

Enable all 4 SEC units available on d05 boards.

Signed-off-by: Jonathan Cameron 
---
 arch/arm64/boot/dts/hisilicon/hip07.dtsi | 293 +++
 1 file changed, 293 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21c3665..81b57c8ce720 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1049,7 +1049,74 @@
num-pins = <2>;
};
};
+   p0_mbigen_alg_a:interrupt-controller@d008 {
+   compatible = "hisilicon,mbigen-v2";
+   reg = <0x0 0xd008 0x0 0x1>;
 
+   p0_mbigen_sec_a: intc_sec {
+   msi-parent = <_its_dsa_a 0x40400>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <33>;
+   };
+   p0_mbigen_smmu_alg_a: intc_smmu_alg {
+   msi-parent = <_its_dsa_a 0x40b1b>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <3>;
+   };
+   };
+   p0_mbigen_alg_b:interrupt-controller@8,d008 {
+   compatible = "hisilicon,mbigen-v2";
+   reg = <0x8 0xd008 0x0 0x1>;
+
+   p0_mbigen_sec_b: intc_sec {
+   msi-parent = <_its_dsa_b 0x42400>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <33>;
+   };
+   p0_mbigen_smmu_alg_b: intc_smmu_alg {
+   msi-parent = <_its_dsa_b 0x42b1b>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <3>;
+   };
+   };
+   p1_mbigen_alg_a:interrupt-controller@400,d008 {
+   compatible = "hisilicon,mbigen-v2";
+   reg = <0x400 0xd008 0x0 0x1>;
+
+   p1_mbigen_sec_a: intc_sec {
+   msi-parent = <_its_dsa_a 0x44400>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <33>;
+   };
+   p1_mbigen_smmu_alg_a: intc_smmu_alg {
+   msi-parent = <_its_dsa_a 0x44b1b>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <3>;
+   };
+   };
+   p1_mbigen_alg_b:interrupt-controller@408,d008 {
+   compatible = "hisilicon,mbigen-v2";
+   reg = <0x408 0xd008 0x0 0x1>;
+
+   p1_mbigen_sec_b: intc_sec {
+   msi-parent = <_its_dsa_b 0x46400>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <33>;
+   };
+   p1_mbigen_smmu_alg_b: intc_smmu_alg {
+   msi-parent = <_its_dsa_b 0x46b1b>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   num-pins = <3>;
+   };
+   };
p0_mbigen_dsa_a: interrupt-controller@c008 {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
@@ -1083,6 +1150,58 @@
};
};
 
+   p0_smmu_alg_a: smmu_alg@d004 {
+   compatible = "arm,smmu-v3";
+   reg = <0x0 0xd004 0x0 0x2>;
+   interrupt-parent = <_mbigen_smmu_alg_a>;
+   interrupts = <733 1>,
+   <734 1>,
+   <735 1>;
+   interrupt-names = "eventq", "gerror", "priq";
+   #iommu-cells = <1>;
+   dma-coherent;
+   hisilicon,broken-prefetch-cmd;
+   /* smmu-cb-memtype = <0x0 0x1>;*/
+   };
+   p0_smmu_alg_b: smmu_alg@8,d004 {
+   compatible = "arm,smmu-v3";
+   reg = <0x8 0xd004 0x0 0x2>;
+   interrupt-parent = <_mbigen_smmu_alg_b>;
+   interrupts = <733 1>,
+   <734 1>,
+   <735 1>;
+   interrupt-names = "eventq", "gerror", "priq";
+   #iommu-cells = <1>;
+   dma-coherent;
+   hisilicon,broken-prefetch-cmd;
+   /* smmu-cb-memtype = <0x0 0x1>;*/
+   };
+   p1_smmu_alg_a: smmu_alg@400,d004 {
+   compatible = "arm,smmu-v3";
+   reg = <0x400 0xd004 0x0 0x2>;
+   interrupt-parent = <_mbigen_smmu_alg_a>;
+   interrupts = <733 1>,
+   <734 1>,
+   <735 1>;
+   interrupt-names = 

[RFC PATCH 0/3] Hisilicon SEC accelerator driver

[Jonathan Cameron]

From: Jonathan Cameron 

This an RFC for a couple of reasons:
1) There is some ongoing discussion on how to handle IVs in the AF_ALG
   interface when doing async IO.  There are a few corners of handling
   in here that are performance enhancements based on Stephan's recent
   set.
2) The handling of iommu presence is ugly.  I need to discuss this with
   iommu maintainer and interested parties.
3) The hardware is limited to 32MB per queued job. We need to handle
   splitting this up into multiple jobs and related IV chaining.

This driver provides in kernel support for the Hisilicon SEC
accelerators found on the hip06 and hip07 SoCs.  There are 4 such
units on the D05 board for which DT bindings are provided.  ACPI
configuration also works with an appropriate UEFI build.

The hardware does not update the IV in chaining or counting modes.
This is done in the driver on completion of the cipher operation.

If we are relying on IV chaining with current AF_ALG it is necessary
to ensure we do not stream the elements directly into the hardware
queues.  For modes where this necessary we use a front end software
queue.

The driver currently supports AES, DES and 3DES block ciphers.
Hash support and AAED support to follow.

Jonathan Cameron (3):
  dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.
  crypto: hisilicon hacv1 driver
  arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

 .../bindings/crypto/hisilicon,hip07-sec.txt|   71 +
 arch/arm64/boot/dts/hisilicon/hip07.dtsi   |  293 
 drivers/crypto/Kconfig |2 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/hisilicon/Kconfig   |   16 +
 drivers/crypto/hisilicon/Makefile  |2 +
 drivers/crypto/hisilicon/sec/Makefile  |3 +
 drivers/crypto/hisilicon/sec/sec_algs.c| 1082 +++
 drivers/crypto/hisilicon/sec/sec_drv.c | 1418 
 drivers/crypto/hisilicon/sec/sec_drv.h |  282 
 10 files changed, 3170 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt
 create mode 100644 drivers/crypto/hisilicon/Kconfig
 create mode 100644 drivers/crypto/hisilicon/Makefile
 create mode 100644 drivers/crypto/hisilicon/sec/Makefile
 create mode 100644 drivers/crypto/hisilicon/sec/sec_algs.c
 create mode 100644 drivers/crypto/hisilicon/sec/sec_drv.c
 create mode 100644 drivers/crypto/hisilicon/sec/sec_drv.h

-- 
2.11.0

[RFC PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

[Jonathan Cameron]

From: Jonathan Cameron 

The hip06 and hip07 SoCs contain a number of these crypto units which
accelerate AES and DES operations.

Signed-off-by: Jonathan Cameron 
---
 .../bindings/crypto/hisilicon,hip07-sec.txt| 71 ++
 1 file changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt 
b/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt
new file mode 100644
index ..bf81118e560c
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt
@@ -0,0 +1,71 @@
+* Hisilicon hip07 Security Accelerator (SEC)
+
+Required properties:
+- compatible: Must contain one of
+  - "hisilicon,hip06-sec"
+  - "hisilicon,hip07-sec"
+- #address-cells: Must be <2> as 64 bit addresses in reg.
+- #size-cells: Must be <2> as 64 bit lengths in reg.
+- reg: Memory addresses and lengths of the memory regions used by the driver.
+  Region 0 has registers to control the backend processing engines.
+  Region 1 has registers for functionality common to all queues.
+  Regions 2-18 have registers for the individual queues which are isolated
+  both in hardware and within the driver.
+- interrupts: Interrupt specifiers.
+  Refer to interrupt-controller/interrupts.txt for generic interrupt client 
node
+  bindings.
+  Interrupt 0 is for the SEC unit error queue.
+  Interrupt 2N + 1 is the completion interrupt for queue N.
+  Interrupt 2N + 2 is the error interrupt for queue N.
+- dma-coherent:  The driver assumes coherent dma is possible.
+
+Optional properties:
+- iommus: The SEC units are behind smmu-v3 iommus.
+  Refer to iommu/arm,smmu-v3.txt for more information.
+
+Example:
+Second socket, first unit chosen to illustrate need for 64 bit addresses.
+
+p1_sec_a: sec@d200 {
+   compatible = "hisilicon,hip07-sec";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x400 0xd000 0x0 0x1
+  0x400 0xd200 0x0 0x1
+  0x400 0xd201 0x0 0x1
+  0x400 0xd202 0x0 0x1
+  0x400 0xd203 0x0 0x1
+  0x400 0xd204 0x0 0x1
+  0x400 0xd205 0x0 0x1
+  0x400 0xd206 0x0 0x1
+  0x400 0xd207 0x0 0x1
+  0x400 0xd208 0x0 0x1
+  0x400 0xd209 0x0 0x1
+  0x400 0xd20a 0x0 0x1
+  0x400 0xd20b 0x0 0x1
+  0x400 0xd20c 0x0 0x1
+  0x400 0xd20d 0x0 0x1
+  0x400 0xd20e 0x0 0x1
+  0x400 0xd20f 0x0 0x1
+  0x400 0xd210 0x0 0x1>;
+   interrupt-parent = <_mbigen_sec_a>;
+   iommus = <_smmu_alg_a 0x600>;
+   dma-coherent;
+   interrupts = <576 4>,
+<577 1>,<578 4>,
+<579 1>,<580 4>,
+<581 1>,<582 4>,
+<583 1>,<584 4>,
+<585 1>,<586 4>,
+<587 1>,<588 4>,
+<589 1>,<590 4>,
+<591 1>,<592 4>,
+<593 1>,<594 4>,
+<595 1>,<596 4>,
+<597 1>,<598 4>,
+<599 1>,<600 4>,
+<601 1>,<602 4>,
+<603 1>,<604 4>,
+<605 1>,<606 4>,
+<607 1>,<608 4>;
+};
-- 
2.11.0

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

[Jarkko Sakkinen]

On Tue, Jan 30, 2018 at 10:52:13PM +1100, James Morris wrote:
> On Tue, 30 Jan 2018, Jarkko Sakkinen wrote:
> 
> > On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote:
> > > Hi Jarkko,
> > > 
> > > On 17 November 2017 at 19:27, Jarkko Sakkinen
> > >  wrote:
> > > > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote:
> > > >
> > > > At least signed-off-by from PrassanaKumar is missing from the 2nd
> > > > commit. I'll add it.
> > > 
> > > I had the impression that my signed-off-by will be present in this
> > > change. But it is missing in [1]. Is it supposed to be that way?
> > > 
> > > 1. 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6e592a065d51d26f9d62b8b7501a5114076af8b4
> > > 
> > > Thanks,
> > > PrasannaKumar
> > 
> > Yes, it would be senseful.
> > 
> > James, would it still be possible to amend this tag to security tree?
> 
> Nope, it's been pushed to Linus.

Damn. Well, good that Tested-by is there. I'm sorry about this.

/Jarkko

Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

[Benjamin Warnke]

Currently ZRAM uses the compression-algorithms from the crypto-api.
None of the current compression-algorithms in the crypto-api is designed
to compress 4KiB chunks of data efficiently.
This patch adds a new compression-algorithm especially designed for ZRAM,
to compress small pieces of data more efficiently.

Benchmarks:

To obtain reproduceable 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.


- '/dev/zero' (8 GiB) 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 | compression   | decompression
 --zram-- | 2913.92 MiB/s | 3116.38 MiB/s


 - 'ecoham' (100 MiB) 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. Where the data is not zero there are
  arrays of floating point values, neighboring float values are likely
  to be similar to each other, allowing high compression ratios.

algorithm | ratio | compression   | decompression
zbewalgo  | 12.77 |  417.35 MiB/s | 1306.21 MiB/s
deflate   | 12.54 |   73.51 MiB/s |  788.85 MiB/s
842   | 12.26 |  199.22 MiB/s |  675.74 MiB/s
lz4hc | 12.00 |   49.99 MiB/s | 1787.79 MiB/s
lz4   | 10.68 | 1356.77 MiB/s | 1690.34 MiB/s
lzo   |  9.79 | 1363.05 MiB/s | 1640.70 MiB/s


 - 'source-code' (800 MiB) This dataset is a tarball of the source-code
  from a linux-kernel.

algorithm | ratio | compression   | decompression
deflate   |  3.27 |   42.36 MiB/s |  256.22 MiB/s
lz4hc |  2.40 |   99.62 MiB/s | 1187.15 MiB/s
lzo   |  2.27 |  432.95 MiB/s |  944.74 MiB/s
lz4   |  2.18 |  444.07 MiB/s | 1159.49 MiB/s
zbewalgo  |  1.89 |   43.44 MiB/s |   35.73 MiB/s
842   |  1.65 |   62.73 MiB/s |  149.71 MiB/s


 - 'hpcg' (8 GiB) This dataset is a (partial) memory-snapshot of the
  running hpcg-benchmark. At the time of the snapshot, that application
  performed a sparse matrix - vector multiplication.

algorithm | ratio | compression   | decompression
zbewalgo  | 15.88 |  174.49 MiB/s |  372.03 MiB/s
deflate   |  9.52 |   64.47 MiB/s |  705.95 MiB/s
lz4hc |  4.96 |  190.97 MiB/s | 1727.96 MiB/s
842   |  4.20 |  144.33 MiB/s |  284.99 MiB/s
lzo   |  4.14 |  910.92 MiB/s | 1272.87 MiB/s
lz4   |  3.79 |  868.92 MiB/s | 1500.85 MiB/s


 - 'partdiff' (8 GiB) Array of double values. Neighbored values are
  similar, but not equal. This array is produced by an partial
  differential equation solver using a Jakobi-implementation.

algorithm | ratio | compression   | decompression
zbewalgo  |  1.17 |  220.36 MiB/s |  678.05 MiB/s
deflate   |  1.02 |   36.87 MiB/s | 1191.34 MiB/s
lzo   |  1.00 | 1727.67 MiB/s | 2103.98 MiB/s
lz4   |  1.00 | 1417.10 MiB/s | 2127.88 MiB/s
lz4hc |  1.00 |  150.14 MiB/s | 2130.08 MiB/s
842   |  1.00 |   63.99 MiB/s | 2131.95 MiB/s


In the category 'compression ratio', the new algorithm zbewalgo is often
the best choice. The faster algorithms with lower compression ratio are
going to fill the zram-partition faster and finally writing their data
to a backing device - which in turn is much slower than imediately using the
zbewalgo algorithm.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>

---
 crypto/Kconfig   |   8 +
 crypto/Makefile  |   1 +
 crypto/zbewalgo.c| 207 +
 include/linux/zbewalgo.h |  59 ++
 lib/Kconfig  |   3 +
 lib/Makefile |   1 +
 lib/zbewalgo/BWT.h   | 116 
 lib/zbewalgo/JBE.h   | 135 ++
 lib/zbewalgo/JBE2.h  | 139 ++
 lib/zbewalgo/MTF.h   | 102 ++
 lib/zbewalgo/Makefile|   3 +
 lib/zbewalgo/RLE.h   | 134 ++
 lib/zbewalgo/bewalgo.h   | 378 ++
 lib/zbewalgo/bewalgo2.h  | 388 +++
 lib/zbewalgo/bitshuffle.h| 105 +++
 lib/zbewalgo/huffman.h   | 232 +++
 lib/zbewalgo/include.h   | 151 +++
 lib/zbewalgo/settings.h  | 220 ++
 lib/zbewalgo/zbewalgo_compress.c | 372 +
 19 files changed, 2754 insertions(+)
 create mode 100644 crypto/zbewalgo.c
 create mode 100644 include/linux/zbewalgo.h
 create mode 100644 lib/zbewalgo/BWT.h
 create mode 100644 lib/zbewalgo/JBE.h
 create mode 100644 lib/zbewalgo/JBE2.h
 create mode 

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

[Stephan Mueller]

Am Dienstag, 30. Januar 2018, 09:27:04 CET schrieb Stephan Müller:

Hi,

> +/**
> + * af_alg_put_iv - release lock on IV in case CTX IV is used
> + *
> + * @sk [in] AF_ALG socket
> + */
> +void af_alg_put_iv(struct sock *sk)
> +{
> + struct alg_sock *ask = alg_sk(sk);
> + struct af_alg_ctx *ctx = ask->private;
> +
> + if (!ctx->iiv || !ctx->ivlen)
> + mutex_unlock(>ivlock);
> +}
> +EXPORT_SYMBOL_GPL(af_alg_put_iv);

Having this function implies that ctx->iiv must be set once at the beginning 
and cannot be toggled for a CTX thereafter as otherwise the release of the 
mutex is racy. This implies that the inline IV patch needs a slight revision 
to prevent toggling the ctx->iiv value.

I will send a new revision of the inline IV and the lock context IV patch 
covering this issue.

Ciao
Stephan

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

[James Morris]

On Tue, 30 Jan 2018, Jarkko Sakkinen wrote:

> On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote:
> > Hi Jarkko,
> > 
> > On 17 November 2017 at 19:27, Jarkko Sakkinen
> >  wrote:
> > > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote:
> > >
> > > At least signed-off-by from PrassanaKumar is missing from the 2nd
> > > commit. I'll add it.
> > 
> > I had the impression that my signed-off-by will be present in this
> > change. But it is missing in [1]. Is it supposed to be that way?
> > 
> > 1. 
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6e592a065d51d26f9d62b8b7501a5114076af8b4
> > 
> > Thanks,
> > PrasannaKumar
> 
> Yes, it would be senseful.
> 
> James, would it still be possible to amend this tag to security tree?

Nope, it's been pushed to Linus.


-- 
James Morris

[PATCH] crypto: AF_ALG AIO - lock context IV

[Stephan Müller]

Hi Harsh,

may I as you to try the attached patch on your Chelsio driver? Please invoke 
the following command from libkcapi:

kcapi  -d 2 -x 9  -e -c "cbc(aes)" -k 
8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i 
7fbc02ebf5b93322329df9bfccb635af -p 48981da18e4bb9ef7e2e3162d16b1910

The result should now be a fully block-chained result.

Note, the patch goes on top of the inline IV patch.

Thanks

---8<---

In case of AIO where multiple IOCBs are sent to the kernel and inline IV
is not used, the ctx->iv is used for each IOCB. The ctx->iv is read for
the crypto operation and written back after the crypto operation. Thus,
processing of multiple IOCBs must be serialized.

As the AF_ALG interface is used by user space, a mutex provides the
serialization which puts the caller to sleep in case a previous IOCB
processing is not yet finished.

If multiple IOCBs arrive that all are blocked, the mutex' FIFO operation
of processing arriving requests ensures that the blocked IOCBs are
unblocked in the right order.

Signed-off-by: Stephan Mueller 
---
 crypto/af_alg.c | 22 ++
 crypto/algif_aead.c |  2 ++
 crypto/algif_skcipher.c |  2 ++
 include/crypto/if_alg.h |  3 +++
 4 files changed, 29 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 87394dc90ac0..3007c9d899da 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -1059,6 +1059,8 @@ void af_alg_async_cb(struct crypto_async_request *_req, 
int err)
struct kiocb *iocb = areq->iocb;
unsigned int resultlen;
 
+   af_alg_put_iv(sk);
+
/* Buffer size written by crypto operation. */
resultlen = areq->outlen;
 
@@ -1227,6 +1229,11 @@ int af_alg_get_iv(struct sock *sk, struct 
af_alg_async_req *areq)
 
/* No inline IV or cipher has no IV, use ctx IV buffer. */
if (!ctx->iiv || !ctx->ivlen) {
+   int ret = mutex_lock_interruptible(>ivlock);
+
+   if (ret)
+   return ret;
+
areq->iv = ctx->iv;
areq->ivlen = 0;// areq->iv will not be freed
return 0;
@@ -1252,6 +1259,21 @@ int af_alg_get_iv(struct sock *sk, struct 
af_alg_async_req *areq)
 }
 EXPORT_SYMBOL_GPL(af_alg_get_iv);
 
+/**
+ * af_alg_put_iv - release lock on IV in case CTX IV is used
+ *
+ * @sk [in] AF_ALG socket
+ */
+void af_alg_put_iv(struct sock *sk)
+{
+   struct alg_sock *ask = alg_sk(sk);
+   struct af_alg_ctx *ctx = ask->private;
+
+   if (!ctx->iiv || !ctx->ivlen)
+   mutex_unlock(>ivlock);
+}
+EXPORT_SYMBOL_GPL(af_alg_put_iv);
+
 static int __init af_alg_init(void)
 {
int err = proto_register(_proto, 0);
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 7eb7cb132c09..165b2ca82e51 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -309,6 +309,7 @@ static int _aead_recvmsg(struct socket *sock, struct 
msghdr *msg,
>wait);
}
 
+   af_alg_put_iv(sk);
 
 free:
af_alg_free_resources(areq);
@@ -555,6 +556,7 @@ static int aead_accept_parent_nokey(void *private, struct 
sock *sk)
return -ENOMEM;
}
memset(ctx->iv, 0, ctx->ivlen);
+   mutex_init(>ivlock);
 
INIT_LIST_HEAD(>tsgl_list);
ctx->len = len;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index d40e1d6797d8..a759cec446b4 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -151,6 +151,7 @@ static int _skcipher_recvmsg(struct socket *sock, struct 
msghdr *msg,
 >wait);
}
+   af_alg_put_iv(sk);
 
 free:
af_alg_free_resources(areq);
@@ -358,6 +359,7 @@ static int skcipher_accept_parent_nokey(void *private, 
struct sock *sk)
}
memset(ctx->iv, 0, ctx->ivlen);
+   mutex_init(>ivlock);
 
INIT_LIST_HEAD(>tsgl_list);
ctx->len = len;
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index ebc651ceb54a..666be8ac683c 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -160,6 +161,7 @@ struct af_alg_ctx {
 
void *iv;
unsigned int ivlen;
+   struct mutex ivlock;
size_t aead_assoclen;
 
struct crypto_wait wait;
@@ -268,6 +270,7 @@ int af_alg_get_rsgl(struct sock *sk, struct msghdr *msg, 
int flags,
struct af_alg_async_req *areq, size_t maxsize,
size_t *outlen);
 int af_alg_get_iv(struct sock *sk, struct af_alg_async_req *areq);
+void af_alg_put_iv(struct sock *sk);
 struct scatterlist *af_alg_get_tsgl_sg(struct af_alg_ctx *ctx);
 
 #endif /* _CRYPTO_IF_ALG_H */
--