date:20180724

On 25 July 2018 at 03:29, Eric Biggers  wrote:
> From: Eric Biggers 
>
> The 4-way ChaCha20 NEON code implements 16-bit rotates with vrev32.16,
> but the one-way code (used on remainder blocks) implements it with
> vshl + vsri, which is slower.  Switch the one-way code to vrev32.16 too.
>
> Signed-off-by: Eric Biggers 

Acked-by: Ard Biesheuvel 

> ---
>  arch/arm/crypto/chacha20-neon-core.S | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/crypto/chacha20-neon-core.S 
> b/arch/arm/crypto/chacha20-neon-core.S
> index 3fecb2124c35..451a849ad518 100644
> --- a/arch/arm/crypto/chacha20-neon-core.S
> +++ b/arch/arm/crypto/chacha20-neon-core.S
> @@ -51,9 +51,8 @@ ENTRY(chacha20_block_xor_neon)
>  .Ldoubleround:
> // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
> vadd.i32q0, q0, q1
> -   veorq4, q3, q0
> -   vshl.u32q3, q4, #16
> -   vsri.u32q3, q4, #16
> +   veorq3, q3, q0
> +   vrev32.16   q3, q3
>
> // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
> vadd.i32q2, q2, q3
> @@ -82,9 +81,8 @@ ENTRY(chacha20_block_xor_neon)
>
> // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
> vadd.i32q0, q0, q1
> -   veorq4, q3, q0
> -   vshl.u32q3, q4, #16
> -   vsri.u32q3, q4, #16
> +   veorq3, q3, q0
> +   vrev32.16   q3, q3
>
> // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
> vadd.i32q2, q2, q3
> --
> 2.18.0
>

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Michael Ellerman

Arnd Bergmann  writes:

> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann 
> ---
...
>  drivers/crypto/vmx/ghashp8-ppc.pl |  12 +-
...
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl 
> b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
>le?vperm   $IN,$IN,$IN,$lemask
>   vxor$zero,$zero,$zero
>  
> - vpmsumd $Xl,$IN,$Hl # H.loXi.lo
> - vpmsumd $Xm,$IN,$H  # H.hiXi.lo+H.loXi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hiXi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>  
>   vpmsumd $t2,$Xl,$xC2# 1st phase
>  
> @@ -187,11 +187,11 @@ $code=<<___;
>  .align   5
>  Loop:
>subic  $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.loXi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
>subfe. r0,r0,r0# borrow?-1:0
> - vpmsumd $Xm,$IN,$H  # H.hiXi.lo+H.loXi.hi
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
>andr0,r0,$len
> - vpmsumd $Xh,$IN,$Hh # H.hiXi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>add$inp,$inp,r0
>  
>   vpmsumd $t2,$Xl,$xC2# 1st phase

Acked-by: Michael Ellerman  (powerpc)

cheers

[PATCH] crypto: arm/chacha20 - always use vrev for 16-bit rotates

2018-07-24 Thread Eric Biggers

From: Eric Biggers 

The 4-way ChaCha20 NEON code implements 16-bit rotates with vrev32.16,
but the one-way code (used on remainder blocks) implements it with
vshl + vsri, which is slower.  Switch the one-way code to vrev32.16 too.

Signed-off-by: Eric Biggers 
---
 arch/arm/crypto/chacha20-neon-core.S | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/crypto/chacha20-neon-core.S 
b/arch/arm/crypto/chacha20-neon-core.S
index 3fecb2124c35..451a849ad518 100644
--- a/arch/arm/crypto/chacha20-neon-core.S
+++ b/arch/arm/crypto/chacha20-neon-core.S
@@ -51,9 +51,8 @@ ENTRY(chacha20_block_xor_neon)
 .Ldoubleround:
// x0 += x1, x3 = rotl32(x3 ^ x0, 16)
vadd.i32q0, q0, q1
-   veorq4, q3, q0
-   vshl.u32q3, q4, #16
-   vsri.u32q3, q4, #16
+   veorq3, q3, q0
+   vrev32.16   q3, q3
 
// x2 += x3, x1 = rotl32(x1 ^ x2, 12)
vadd.i32q2, q2, q3
@@ -82,9 +81,8 @@ ENTRY(chacha20_block_xor_neon)
 
// x0 += x1, x3 = rotl32(x3 ^ x0, 16)
vadd.i32q0, q0, q1
-   veorq4, q3, q0
-   vshl.u32q3, q4, #16
-   vsri.u32q3, q4, #16
+   veorq3, q3, q0
+   vrev32.16   q3, q3
 
// x2 += x3, x1 = rotl32(x1 ^ x2, 12)
vadd.i32q2, q2, q3
-- 
2.18.0

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Andrew Morton

On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches  wrote:

> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
> > On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann  wrote:
> > > Almost all files in the kernel are either plain text or UTF-8
> > > encoded. A couple however are ISO_8859-1, usually just a few
> > > characters in a C comments, for historic reasons.
> > > This converts them all to UTF-8 for consistency.
> []
> > Will we be getting a checkpatch rule to keep things this way?
> 
> How would that be done?

I'm using this, seems to work.

if ! file $p | grep -q -P ", ASCII text|, UTF-8 Unicode text"
then
echo $p: weird charset
fi

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Joe Perches

On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
> On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann  wrote:
> > Almost all files in the kernel are either plain text or UTF-8
> > encoded. A couple however are ISO_8859-1, usually just a few
> > characters in a C comments, for historic reasons.
> > This converts them all to UTF-8 for consistency.
[]
> Will we be getting a checkpatch rule to keep things this way?

How would that be done?

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Jonathan Cameron

On Tue, 24 Jul 2018 13:13:25 +0200
Arnd Bergmann  wrote:

> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
> 
> This converts them all to UTF-8 for consistency.
> 
> Signed-off-by: Arnd Bergmann 
For IIO, Acked-by: Jonathan Cameron 

Thanks for tidying this up.

Jonathan

> ---
>  .../devicetree/bindings/net/nfc/pn544.txt |   2 +-
>  arch/arm/boot/dts/sun4i-a10-inet97fv2.dts |   2 +-
>  arch/arm/crypto/sha256_glue.c |   2 +-
>  arch/arm/crypto/sha256_neon_glue.c|   4 +-
>  drivers/crypto/vmx/ghashp8-ppc.pl |  12 +-
>  drivers/iio/dac/ltc2632.c |   2 +-
>  drivers/power/reset/ltc2952-poweroff.c|   4 +-
>  kernel/events/callchain.c |   2 +-
>  net/netfilter/ipvs/Kconfig|   8 +-
>  net/netfilter/ipvs/ip_vs_mh.c |   4 +-
>  tools/power/cpupower/po/de.po |  44 +++
>  tools/power/cpupower/po/fr.po | 120 +-
>  12 files changed, 103 insertions(+), 103 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt 
> b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> index 538a86f7b2b0..72593f056b75 100644
> --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> @@ -2,7 +2,7 @@
>  
>  Required properties:
>  - compatible: Should be "nxp,pn544-i2c".
> -- clock-frequency: I_C work frequency.
> +- clock-frequency: I²C work frequency.
>  - reg: address on the bus
>  - interrupt-parent: phandle for the interrupt gpio controller
>  - interrupts: GPIO interrupt to which the chip is connected
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index 5d096528e75a..71c27ea0b53e 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -1,7 +1,7 @@
>  /*
>   * Copyright 2014 Open Source Support GmbH
>   *
> - * David Lanzend_rfer 
> + * David Lanzendörfer 
>   *
>   * This file is dual-licensed: you can use it either under the terms
>   * of the GPL or the X11 license, at your option. Note that this dual
> diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
> index bf8ccff2c9d0..0ae900e778f3 100644
> --- a/arch/arm/crypto/sha256_glue.c
> +++ b/arch/arm/crypto/sha256_glue.c
> @@ -2,7 +2,7 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using optimized ARM assembler and NEON instructions.
>   *
> - * Copyright _ 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha256_ssse3_glue.c:
>   *   Copyright (C) 2013 Intel Corporation
> diff --git a/arch/arm/crypto/sha256_neon_glue.c 
> b/arch/arm/crypto/sha256_neon_glue.c
> index 9bbee56fbdc8..1d82c6cd31a4 100644
> --- a/arch/arm/crypto/sha256_neon_glue.c
> +++ b/arch/arm/crypto/sha256_neon_glue.c
> @@ -2,10 +2,10 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using NEON instructions.
>   *
> - * Copyright _ 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha512_neon_glue.c:
> - *   Copyright _ 2014 Jussi Kivilinna 
> + *   Copyright © 2014 Jussi Kivilinna 
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License as published by the Free
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl 
> b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
>le?vperm   $IN,$IN,$IN,$lemask
>   vxor$zero,$zero,$zero
>  
> - vpmsumd $Xl,$IN,$Hl # H.lo_Xi.lo
> - vpmsumd $Xm,$IN,$H  # H.hi_Xi.lo+H.lo_Xi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hi_Xi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>  
>   vpmsumd $t2,$Xl,$xC2# 1st phase
>  
> @@ -187,11 +187,11 @@ $code=<<___;
>  .align   5
>  Loop:
>subic  $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.lo_Xi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
>subfe. r0,r0,r0# borrow?-1:0
> - vpmsumd $Xm,$IN,$H  # H.hi_Xi.lo+H.lo_Xi.hi
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
>andr0,r0,$len
> - vpmsumd $Xh,$IN,$Hh # H.hi_Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>add$inp,$inp,r0
>

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Randy Dunlap

On 07/24/2018 02:00 PM, Andrew Morton wrote:
> On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann  wrote:
> 
>> Almost all files in the kernel are either plain text or UTF-8
>> encoded. A couple however are ISO_8859-1, usually just a few
>> characters in a C comments, for historic reasons.
>>
>> This converts them all to UTF-8 for consistency.
> 
> Was "consistency" the only rationale?  The discussion is now outside my
> memory horizon but I thought there were other reasons.

kconfig tools prefer ASCII or utf-8.

email tools probably likewise.

user sanity?

> Will we be getting a checkpatch rule to keep things this way?



-- 
~Randy

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Andrew Morton

On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann  wrote:

> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
> 
> This converts them all to UTF-8 for consistency.

Was "consistency" the only rationale?  The discussion is now outside my
memory horizon but I thought there were other reasons.

Will we be getting a checkpatch rule to keep things this way?

Re: [PATCH v6 18/18] crypto: Remove AHASH_REQUEST_ON_STACK

On Tue, Jul 24, 2018 at 10:31 AM, Joe Perches  wrote:
> On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
>> All users of AHASH_REQUEST_ON_STACK have been removed from the kernel, so
>> drop it entirely so no VLAs get reintroduced by future users.
>
> checkpatch has a test for that.
> It could now be removed as well.
> ---
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 34e4683de7a3..a3517334d661 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -796,7 +796,7 @@ our $declaration_macros = qr{(?x:
> 
> (?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
> (?:$Storage\s+)?[HLP]?LIST_HEAD\s*\(|
> (?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(|
> -   (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
> +   (?:SKCIPHER_REQUEST|SHASH_DESC)_ON_STACK\s*\(
>  )};

Ah! Cool. I've added this now.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v6 17/18] crypto: ccm: Remove VLA usage

On Tue, Jul 24, 2018 at 9:57 AM, Ard Biesheuvel
 wrote:
> On 24 July 2018 at 18:49, Kees Cook  wrote:
>> From: Ard Biesheuvel 
>>
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> drops AHASH_REQUEST_ON_STACK by preallocated the ahash request area
>> with the skcipher area (which are not used at the same time).
>>
>
> -EGRAMMAR

Whoops. Will fix my poor sentence merging. :)

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v6 18/18] crypto: Remove AHASH_REQUEST_ON_STACK

2018-07-24 Thread Joe Perches

On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
> All users of AHASH_REQUEST_ON_STACK have been removed from the kernel, so
> drop it entirely so no VLAs get reintroduced by future users.

checkpatch has a test for that.
It could now be removed as well.
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 34e4683de7a3..a3517334d661 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -796,7 +796,7 @@ our $declaration_macros = qr{(?x:

(?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
(?:$Storage\s+)?[HLP]?LIST_HEAD\s*\(|
(?:$Storage\s+)?${Type}\s+uninitialized_var\s*\(|
-   (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
+   (?:SKCIPHER_REQUEST|SHASH_DESC)_ON_STACK\s*\(
 )};

Re: [PATCH 0/4] crypto/arm64: reduce impact of NEON yield checks

2018-07-24 Thread Sebastian Andrzej Siewior

On 2018-07-24 19:12:20 [+0200], Ard Biesheuvel wrote:
> Vakul reports a considerable performance hit when running the accelerated
> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
> been updated to take the TIF_NEED_RESCHED flag into account.

just in time. I will try to come up with some numbers on RT with the
original patch and with that one. I have it almost working…

Sebastian

[PATCH 1/4] crypto/arm64: ghash - reduce performance impact of NEON yield checks

As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
iteration of the GHASH and AES-GCM core routines is having a considerable
performance impact on cores such as the Cortex-A53 with Crypto Extensions
implemented.

GHASH performance is down by 22% for large block sizes, and AES-GCM is
down by 16% for large block sizes and 128 bit keys. This appears to be
a result of the high performance of the crypto instructions on the one
hand (2.0 cycles per byte for GHASH, 3.0 cpb for AES-GCM), combined with
the relatively poor load/store performance of this simple core.

So let's reduce this performance impact by only doing the yield check
once every 32 blocks for GHASH (or 4 when using the version based on
8-bit polynomial multiplication), and once every 16 blocks for AES-GCM.
This way, we recover most of the performance while still limiting the
duration of scheduling blackouts due to disabling preemption to ~1000
cycles.

Cc: Vakul Garg 
Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/ghash-ce-core.S | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/crypto/ghash-ce-core.S 
b/arch/arm64/crypto/ghash-ce-core.S
index dcffb9e77589..9c14beaabeee 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -212,7 +212,7 @@
ushrXL.2d, XL.2d, #1
.endm
 
-   .macro  __pmull_ghash, pn
+   .macro  __pmull_ghash, pn, yield_count
frame_push  5
 
mov x19, x0
@@ -259,6 +259,9 @@ CPU_LE( rev64   T1.16b, T1.16b  )
eor T2.16b, T2.16b, XH.16b
eor XL.16b, XL.16b, T2.16b
 
+   tst w19, #(\yield_count - 1)
+   b.ne1b
+
cbz w19, 3f
 
if_will_cond_yield_neon
@@ -279,11 +282,11 @@ CPU_LE(   rev64   T1.16b, T1.16b  )
 * struct ghash_key const *k, const char *head)
 */
 ENTRY(pmull_ghash_update_p64)
-   __pmull_ghash   p64
+   __pmull_ghash   p64, 32
 ENDPROC(pmull_ghash_update_p64)
 
 ENTRY(pmull_ghash_update_p8)
-   __pmull_ghash   p8
+   __pmull_ghash   p8, 4
 ENDPROC(pmull_ghash_update_p8)
 
KS  .reqv8
@@ -428,6 +431,9 @@ CPU_LE( rev x28, x28)
st1 {INP.16b}, [x21], #16
.endif
 
+   tst w19, #0xf   // do yield check only
+   b.ne1b  // once every 16 blocks
+
cbz w19, 3f
 
if_will_cond_yield_neon
-- 
2.11.0

[PATCH 0/4] crypto/arm64: reduce impact of NEON yield checks

Vakul reports a considerable performance hit when running the accelerated
arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
been updated to take the TIF_NEED_RESCHED flag into account.

The issue appears to be caused by the fact that Cortex-A53, the core in
question, has a high end implementation of the Crypto Extensions, and
has a shallow pipeline, which means even sequential algorithms that may be
held back by pipeline stalls on high end out of order cores run at maximum
speed. This means SHA-1, SHA-2, GHASH and AES in GCM and CCM modes run at a
speed in the order of 2 to 4 cycles per byte, and are currently implemented
to check the TIF_NEED_RESCHED after each iteration, which may process as
little as 16 bytes (for GHASH).

Obviously, every cycle of overhead hurts in this context, and given that
the A53's load/store unit is not quite high end, any delays caused by
memory accesses that occur in the inner loop of the algorithms are going
to be quite significant, hence the performance regression.

So reduce the frequency at which the NEON yield checks are performed, so
that they occur roughly once every 1000 cycles, which is hopefully a
reasonable tradeoff between throughput and worst case scheduling latency.

Ard Biesheuvel (4):
  crypto/arm64: ghash - reduce performance impact of NEON yield checks
  crypto/arm64: aes-ccm - reduce performance impact of NEON yield checks
  crypto/arm64: sha1 - reduce performance impact of NEON yield checks
  crypto/arm64: sha2 - reduce performance impact of NEON yield checks

 arch/arm64/crypto/aes-ce-ccm-core.S |  3 +++
 arch/arm64/crypto/ghash-ce-core.S   | 12 +---
 arch/arm64/crypto/sha1-ce-core.S|  3 +++
 arch/arm64/crypto/sha2-ce-core.S|  3 +++
 4 files changed, 18 insertions(+), 3 deletions(-)

-- 
2.11.0

[PATCH 3/4] crypto/arm64: sha1 - reduce performance impact of NEON yield checks

Only perform the NEON yield check for every 4 blocks of input, to
prevent taking a considerable performance hit on cores with very
fast crypto instructions and comparatively slow memory accesses,
such as the Cortex-A53.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/sha1-ce-core.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 78eb35fb5056..f592c55218d0 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -129,6 +129,9 @@ CPU_LE( rev32   v11.16b, v11.16b)
add dgbv.2s, dgbv.2s, dg1v.2s
add dgav.4s, dgav.4s, dg0v.4s
 
+   tst w21, #0x3   // yield only every 4 blocks
+   b.ne1b
+
cbz w21, 3f
 
if_will_cond_yield_neon
-- 
2.11.0

[PATCH 4/4] crypto/arm64: sha2 - reduce performance impact of NEON yield checks

Only perform the NEON yield check for every 4 blocks of input, to
prevent taking a considerable performance hit on cores with very
fast crypto instructions and comparatively slow memory accesses,
such as the Cortex-A53.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/sha2-ce-core.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index cd8b36412469..201a33ff6830 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -136,6 +136,9 @@ CPU_LE( rev32   v19.16b, v19.16b)
add dgav.4s, dgav.4s, dg0v.4s
add dgbv.4s, dgbv.4s, dg1v.4s
 
+   tst w21, #0x3   // yield only every 4 blocks
+   b.ne1b
+
/* handled all input blocks? */
cbz w21, 3f
 
-- 
2.11.0

[PATCH 2/4] crypto/arm64: aes-ccm - reduce performance impact of NEON yield checks

Only perform the NEON yield check for every 8 blocks of input, to
prevent taking a considerable performance hit on cores with very
fast crypto instructions and comparatively slow memory accesses,
such as the Cortex-A53.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/aes-ce-ccm-core.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S 
b/arch/arm64/crypto/aes-ce-ccm-core.S
index 88f5aef7934c..627710cdc220 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -208,6 +208,9 @@ CPU_LE( rev x26, x26)   /* keep 
swabbed ctr in reg */
st1 {v1.16b}, [x19], #16/* write output block */
beq 5f
 
+   tst w21, #(0x7 * 16)/* yield every 8 blocks */
+   b.ne0b
+
if_will_cond_yield_neon
st1 {v0.16b}, [x24] /* store mac */
do_cond_yield_neon
-- 
2.11.0

Re: [PATCH v6 17/18] crypto: ccm: Remove VLA usage

On 24 July 2018 at 18:49, Kees Cook  wrote:
> From: Ard Biesheuvel 
>
> In the quest to remove all stack VLA usage from the kernel[1], this
> drops AHASH_REQUEST_ON_STACK by preallocated the ahash request area
> with the skcipher area (which are not used at the same time).
>

-EGRAMMAR

> [1] 
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Kees Cook 
> ---
>  crypto/ccm.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/crypto/ccm.c b/crypto/ccm.c
> index 0a083342ec8c..b242fd0d3262 100644
> --- a/crypto/ccm.c
> +++ b/crypto/ccm.c
> @@ -50,7 +50,10 @@ struct crypto_ccm_req_priv_ctx {
> u32 flags;
> struct scatterlist src[3];
> struct scatterlist dst[3];
> -   struct skcipher_request skreq;
> +   union {
> +   struct ahash_request ahreq;
> +   struct skcipher_request skreq;
> +   };
>  };
>
>  struct cbcmac_tfm_ctx {
> @@ -181,7 +184,7 @@ static int crypto_ccm_auth(struct aead_request *req, 
> struct scatterlist *plain,
> struct crypto_ccm_req_priv_ctx *pctx = crypto_ccm_reqctx(req);
> struct crypto_aead *aead = crypto_aead_reqtfm(req);
> struct crypto_ccm_ctx *ctx = crypto_aead_ctx(aead);
> -   AHASH_REQUEST_ON_STACK(ahreq, ctx->mac);
> +   struct ahash_request *ahreq = &pctx->ahreq;
> unsigned int assoclen = req->assoclen;
> struct scatterlist sg[3];
> u8 *odata = pctx->odata;
> @@ -427,7 +430,7 @@ static int crypto_ccm_init_tfm(struct crypto_aead *tfm)
> crypto_aead_set_reqsize(
> tfm,
> align + sizeof(struct crypto_ccm_req_priv_ctx) +
> -   crypto_skcipher_reqsize(ctr));
> +   max(crypto_ahash_reqsize(mac), crypto_skcipher_reqsize(ctr)));
>
> return 0;
>
> --
> 2.17.1
>

[PATCH v6 16/18] rxrpc: Reuse SKCIPHER_REQUEST_ON_STACK buffer

The use of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
(when less than 2048) once the VLA is no longer hidden from the check:

net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than 
1024 bytes [-Wframe-larger-than=]
net/rxrpc/rxkad.c:242:1: warning: the frame size of 1152 bytes is larger than 
1024 bytes [-Wframe-larger-than=]

This passes the initial SKCIPHER_REQUEST_ON_STACK allocation to the leaf
functions for reuse. Two requests allocated on the stack is not needed
when only one is used at a time.

Signed-off-by: Kees Cook 
Acked-by: Arnd Bergmann 
---
 net/rxrpc/rxkad.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 278ac0807a60..6393391fac86 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -146,10 +146,10 @@ static int rxkad_prime_packet_security(struct 
rxrpc_connection *conn)
 static int rxkad_secure_packet_auth(const struct rxrpc_call *call,
struct sk_buff *skb,
u32 data_size,
-   void *sechdr)
+   void *sechdr,
+   struct skcipher_request *req)
 {
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
-   SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
struct rxkad_level1_hdr hdr;
struct rxrpc_crypt iv;
struct scatterlist sg;
@@ -183,12 +183,12 @@ static int rxkad_secure_packet_auth(const struct 
rxrpc_call *call,
 static int rxkad_secure_packet_encrypt(const struct rxrpc_call *call,
   struct sk_buff *skb,
   u32 data_size,
-  void *sechdr)
+  void *sechdr,
+  struct skcipher_request *req)
 {
const struct rxrpc_key_token *token;
struct rxkad_level2_hdr rxkhdr;
struct rxrpc_skb_priv *sp;
-   SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
struct rxrpc_crypt iv;
struct scatterlist sg[16];
struct sk_buff *trailer;
@@ -296,11 +296,12 @@ static int rxkad_secure_packet(struct rxrpc_call *call,
ret = 0;
break;
case RXRPC_SECURITY_AUTH:
-   ret = rxkad_secure_packet_auth(call, skb, data_size, sechdr);
+   ret = rxkad_secure_packet_auth(call, skb, data_size, sechdr,
+  req);
break;
case RXRPC_SECURITY_ENCRYPT:
ret = rxkad_secure_packet_encrypt(call, skb, data_size,
- sechdr);
+ sechdr, req);
break;
default:
ret = -EPERM;
@@ -316,10 +317,10 @@ static int rxkad_secure_packet(struct rxrpc_call *call,
  */
 static int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb,
 unsigned int offset, unsigned int len,
-rxrpc_seq_t seq)
+rxrpc_seq_t seq,
+struct skcipher_request *req)
 {
struct rxkad_level1_hdr sechdr;
-   SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
struct rxrpc_crypt iv;
struct scatterlist sg[16];
struct sk_buff *trailer;
@@ -402,11 +403,11 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call, 
struct sk_buff *skb,
  */
 static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
 unsigned int offset, unsigned int len,
-rxrpc_seq_t seq)
+rxrpc_seq_t seq,
+struct skcipher_request *req)
 {
const struct rxrpc_key_token *token;
struct rxkad_level2_hdr sechdr;
-   SKCIPHER_REQUEST_ON_STACK(req, call->conn->cipher);
struct rxrpc_crypt iv;
struct scatterlist _sg[4], *sg;
struct sk_buff *trailer;
@@ -549,9 +550,9 @@ static int rxkad_verify_packet(struct rxrpc_call *call, 
struct sk_buff *skb,
case RXRPC_SECURITY_PLAIN:
return 0;
case RXRPC_SECURITY_AUTH:
-   return rxkad_verify_packet_1(call, skb, offset, len, seq);
+   return rxkad_verify_packet_1(call, skb, offset, len, seq, req);
case RXRPC_SECURITY_ENCRYPT:
-   return rxkad_verify_packet_2(call, skb, offset, len, seq);
+   return rxkad_verify_packet_2(call, skb, offset, len, seq, req);
default:
return -ENOANO;
}
-- 
2.17.1

[PATCH v6 17/18] crypto: ccm: Remove VLA usage

From: Ard Biesheuvel 

In the quest to remove all stack VLA usage from the kernel[1], this
drops AHASH_REQUEST_ON_STACK by preallocated the ahash request area
with the skcipher area (which are not used at the same time).

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Kees Cook 
---
 crypto/ccm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/crypto/ccm.c b/crypto/ccm.c
index 0a083342ec8c..b242fd0d3262 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -50,7 +50,10 @@ struct crypto_ccm_req_priv_ctx {
u32 flags;
struct scatterlist src[3];
struct scatterlist dst[3];
-   struct skcipher_request skreq;
+   union {
+   struct ahash_request ahreq;
+   struct skcipher_request skreq;
+   };
 };
 
 struct cbcmac_tfm_ctx {
@@ -181,7 +184,7 @@ static int crypto_ccm_auth(struct aead_request *req, struct 
scatterlist *plain,
struct crypto_ccm_req_priv_ctx *pctx = crypto_ccm_reqctx(req);
struct crypto_aead *aead = crypto_aead_reqtfm(req);
struct crypto_ccm_ctx *ctx = crypto_aead_ctx(aead);
-   AHASH_REQUEST_ON_STACK(ahreq, ctx->mac);
+   struct ahash_request *ahreq = &pctx->ahreq;
unsigned int assoclen = req->assoclen;
struct scatterlist sg[3];
u8 *odata = pctx->odata;
@@ -427,7 +430,7 @@ static int crypto_ccm_init_tfm(struct crypto_aead *tfm)
crypto_aead_set_reqsize(
tfm,
align + sizeof(struct crypto_ccm_req_priv_ctx) +
-   crypto_skcipher_reqsize(ctr));
+   max(crypto_ahash_reqsize(mac), crypto_skcipher_reqsize(ctr)));
 
return 0;
 
-- 
2.17.1

[PATCH v6 18/18] crypto: Remove AHASH_REQUEST_ON_STACK

All users of AHASH_REQUEST_ON_STACK have been removed from the kernel, so
drop it entirely so no VLAs get reintroduced by future users.

Signed-off-by: Kees Cook 
---
 include/crypto/hash.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 21587011ab0f..fca3e28c77a4 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -64,11 +64,6 @@ struct ahash_request {
void *__ctx[] CRYPTO_MINALIGN_ATTR;
 };
 
-#define AHASH_REQUEST_ON_STACK(name, ahash) \
-   char __##name##_desc[sizeof(struct ahash_request) + \
-   crypto_ahash_reqsize(ahash)] CRYPTO_MINALIGN_ATTR; \
-   struct ahash_request *name = (void *)__##name##_desc
-
 /**
  * struct ahash_alg - asynchronous message digest definition
  * @init: **[mandatory]** Initialize the transformation context. Intended only 
to initialize the
-- 
2.17.1

[PATCH v6 03/18] crypto: hash: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this
removes the VLAs in SHASH_DESC_ON_STACK (via crypto_shash_descsize())
by using the maximum allowable size (which is now more clearly captured
in a macro), along with a few other cases. Similar limits are turned into
macros as well.

A review of existing sizes shows that SHA512_DIGEST_SIZE (64) is the
largest digest size and that sizeof(struct sha3_state) (360) is the
largest descriptor size. The corresponding maximums are reduced.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 crypto/ahash.c| 4 ++--
 crypto/algif_hash.c   | 2 +-
 crypto/shash.c| 6 +++---
 include/crypto/hash.h | 6 +-
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index a64c143165b1..78aaf2158c43 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -550,8 +550,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
 {
struct crypto_alg *base = &alg->halg.base;
 
-   if (alg->halg.digestsize > PAGE_SIZE / 8 ||
-   alg->halg.statesize > PAGE_SIZE / 8 ||
+   if (alg->halg.digestsize > HASH_MAX_DIGESTSIZE ||
+   alg->halg.statesize > HASH_MAX_STATESIZE ||
alg->halg.statesize == 0)
return -EINVAL;
 
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index bfcf595fd8f9..d0cde541beb6 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -239,7 +239,7 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags,
struct alg_sock *ask = alg_sk(sk);
struct hash_ctx *ctx = ask->private;
struct ahash_request *req = &ctx->req;
-   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req)) ? : 1];
+   char state[HASH_MAX_STATESIZE];
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
diff --git a/crypto/shash.c b/crypto/shash.c
index 5d732c6bb4b2..86d76b5c626c 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -458,9 +458,9 @@ static int shash_prepare_alg(struct shash_alg *alg)
 {
struct crypto_alg *base = &alg->base;
 
-   if (alg->digestsize > PAGE_SIZE / 8 ||
-   alg->descsize > PAGE_SIZE / 8 ||
-   alg->statesize > PAGE_SIZE / 8)
+   if (alg->digestsize > HASH_MAX_DIGESTSIZE ||
+   alg->descsize > HASH_MAX_DESCSIZE ||
+   alg->statesize > HASH_MAX_STATESIZE)
return -EINVAL;
 
base->cra_type = &crypto_shash_type;
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 76e432cab75d..21587011ab0f 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -151,9 +151,13 @@ struct shash_desc {
void *__ctx[] CRYPTO_MINALIGN_ATTR;
 };
 
+#define HASH_MAX_DIGESTSIZE 64
+#define HASH_MAX_DESCSIZE  360
+#define HASH_MAX_STATESIZE 512
+
 #define SHASH_DESC_ON_STACK(shash, ctx)  \
char __##shash##_desc[sizeof(struct shash_desc) + \
-   crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \
+   HASH_MAX_DESCSIZE] CRYPTO_MINALIGN_ATTR; \
struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
 
 /**
-- 
2.17.1

[PATCH v6 02/18] crypto: cbc: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 include/crypto/cbc.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/crypto/cbc.h b/include/crypto/cbc.h
index f5b8bfc22e6d..47db0aac2ab9 100644
--- a/include/crypto/cbc.h
+++ b/include/crypto/cbc.h
@@ -113,7 +113,9 @@ static inline int crypto_cbc_decrypt_inplace(
unsigned int bsize = crypto_skcipher_blocksize(tfm);
unsigned int nbytes = walk->nbytes;
u8 *src = walk->src.virt.addr;
-   u8 last_iv[bsize];
+   u8 last_iv[MAX_CIPHER_BLOCKSIZE];
+
+   BUG_ON(bsize > sizeof(last_iv));
 
/* Start of the last block. */
src += nbytes - (nbytes & (bsize - 1)) - bsize;
-- 
2.17.1

[PATCH v6 01/18] crypto: xcbc: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check. For xcbc, the blocksize
must always be 16, so use that, since it's already being enforced during
instantiation.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 crypto/xcbc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/crypto/xcbc.c b/crypto/xcbc.c
index 25c75af50d3f..c055f57fab11 100644
--- a/crypto/xcbc.c
+++ b/crypto/xcbc.c
@@ -57,15 +57,17 @@ struct xcbc_desc_ctx {
u8 ctx[];
 };
 
+#define XCBC_BLOCKSIZE 16
+
 static int crypto_xcbc_digest_setkey(struct crypto_shash *parent,
 const u8 *inkey, unsigned int keylen)
 {
unsigned long alignmask = crypto_shash_alignmask(parent);
struct xcbc_tfm_ctx *ctx = crypto_shash_ctx(parent);
-   int bs = crypto_shash_blocksize(parent);
u8 *consts = PTR_ALIGN(&ctx->ctx[0], alignmask + 1);
int err = 0;
-   u8 key1[bs];
+   u8 key1[XCBC_BLOCKSIZE];
+   int bs = sizeof(key1);
 
if ((err = crypto_cipher_setkey(ctx->child, inkey, keylen)))
return err;
@@ -212,7 +214,7 @@ static int xcbc_create(struct crypto_template *tmpl, struct 
rtattr **tb)
return PTR_ERR(alg);
 
switch(alg->cra_blocksize) {
-   case 16:
+   case XCBC_BLOCKSIZE:
break;
default:
goto out_put_alg;
-- 
2.17.1

[PATCH v6 05/18] crypto alg: Introduce generic max blocksize and alignmask

In the quest to remove all stack VLA usage from the kernel[1], this
exposes a new general upper bound on crypto blocksize and alignmask
(higher than for the existing cipher limits) for VLA removal,
and introduces new checks.

At present, the highest cra_alignmask in the kernel is 63. The highest
cra_blocksize is 144 (SHA3_224_BLOCK_SIZE, 18 8-byte words). For the
new blocksize limit, I went with 160 (20 8-byte words).

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 crypto/algapi.c | 7 ++-
 include/crypto/algapi.h | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index c0755cf4f53f..496fc51bf215 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -57,9 +57,14 @@ static int crypto_check_alg(struct crypto_alg *alg)
if (alg->cra_alignmask & (alg->cra_alignmask + 1))
return -EINVAL;
 
-   if (alg->cra_blocksize > PAGE_SIZE / 8)
+   /* General maximums for all algs. */
+   if (alg->cra_alignmask > MAX_ALGAPI_ALIGNMASK)
return -EINVAL;
 
+   if (alg->cra_blocksize > MAX_ALGAPI_BLOCKSIZE)
+   return -EINVAL;
+
+   /* Lower maximums for specific alg types. */
if (!alg->cra_type && (alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
   CRYPTO_ALG_TYPE_CIPHER) {
if (alg->cra_alignmask > MAX_CIPHER_ALIGNMASK)
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index bd5e8ccf1687..21371ac8f355 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -20,8 +20,10 @@
 /*
  * Maximum values for blocksize and alignmask, used to allocate
  * static buffers that are big enough for any combination of
- * ciphers and architectures.
+ * algs and architectures. Ciphers have a lower maximum size.
  */
+#define MAX_ALGAPI_BLOCKSIZE   160
+#define MAX_ALGAPI_ALIGNMASK   63
 #define MAX_CIPHER_BLOCKSIZE   16
 #define MAX_CIPHER_ALIGNMASK   15
 
-- 
2.17.1

[PATCH v6 04/18] dm: Remove VLA usage from hashes

In the quest to remove all stack VLA usage from the kernel[1], this uses
the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
bounds on stack usage.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 drivers/md/dm-integrity.c  | 23 +--
 drivers/md/dm-verity-fec.c |  5 -
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 86438b2f10dd..884edd7cf1d0 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -521,7 +521,12 @@ static void section_mac(struct dm_integrity_c *ic, 
unsigned section, __u8 result
}
memset(result + size, 0, JOURNAL_MAC_SIZE - size);
} else {
-   __u8 digest[size];
+   __u8 digest[HASH_MAX_DIGESTSIZE];
+
+   if (WARN_ON(size > sizeof(digest))) {
+   dm_integrity_io_error(ic, "digest_size", -EINVAL);
+   goto err;
+   }
r = crypto_shash_final(desc, digest);
if (unlikely(r)) {
dm_integrity_io_error(ic, "crypto_shash_final", r);
@@ -1244,7 +1249,7 @@ static void integrity_metadata(struct work_struct *w)
struct bio *bio = dm_bio_from_per_bio_data(dio, sizeof(struct 
dm_integrity_io));
char *checksums;
unsigned extra_space = unlikely(digest_size > ic->tag_size) ? 
digest_size - ic->tag_size : 0;
-   char checksums_onstack[ic->tag_size + extra_space];
+   char checksums_onstack[HASH_MAX_DIGESTSIZE];
unsigned sectors_to_process = dio->range.n_sectors;
sector_t sector = dio->range.logical_sector;
 
@@ -1253,8 +1258,14 @@ static void integrity_metadata(struct work_struct *w)
 
checksums = kmalloc((PAGE_SIZE >> SECTOR_SHIFT >> 
ic->sb->log2_sectors_per_block) * ic->tag_size + extra_space,
GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN);
-   if (!checksums)
+   if (!checksums) {
checksums = checksums_onstack;
+   if (WARN_ON(extra_space &&
+   digest_size > sizeof(checksums_onstack))) {
+   r = -EINVAL;
+   goto error;
+   }
+   }
 
__bio_for_each_segment(bv, bio, iter, dio->orig_bi_iter) {
unsigned pos;
@@ -1466,7 +1477,7 @@ static bool __journal_read_write(struct dm_integrity_io 
*dio, struct bio *bio,
} while (++s < ic->sectors_per_block);
 #ifdef INTERNAL_VERIFY
if (ic->internal_hash) {
-   char 
checksums_onstack[max(crypto_shash_digestsize(ic->internal_hash), 
ic->tag_size)];
+   char 
checksums_onstack[max(HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
 
integrity_sector_checksum(ic, 
logical_sector, mem + bv.bv_offset, checksums_onstack);
if (unlikely(memcmp(checksums_onstack, 
journal_entry_tag(ic, je), ic->tag_size))) {
@@ -1516,7 +1527,7 @@ static bool __journal_read_write(struct dm_integrity_io 
*dio, struct bio *bio,
if (ic->internal_hash) {
unsigned digest_size = 
crypto_shash_digestsize(ic->internal_hash);
if (unlikely(digest_size > 
ic->tag_size)) {
-   char 
checksums_onstack[digest_size];
+   char 
checksums_onstack[HASH_MAX_DIGESTSIZE];
integrity_sector_checksum(ic, 
logical_sector, (char *)js, checksums_onstack);
memcpy(journal_entry_tag(ic, 
je), checksums_onstack, ic->tag_size);
} else
@@ -1937,7 +1948,7 @@ static void do_journal_write(struct dm_integrity_c *ic, 
unsigned write_start,
unlikely(from_replay) &&
 #endif
ic->internal_hash) {
-   char 
test_tag[max(crypto_shash_digestsize(ic->internal_hash), ic->tag_size)];
+   char test_tag[max_t(size_t, 
HASH_MAX_DIGESTSIZE, MAX_TAG_SIZE)];
 
integrity_sector_checksum(ic, sec + ((l 
- j) << ic->sb->log2_sectors_per_block),
  (char 
*)access_journal_data(ic, i, l), test_tag);
diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index 684af08d0747..0ce04e5b4afb 100644
--- a/drivers

[PATCH v6 00/18] crypto: Remove VLA usage

For newly added CCs on this series: your Ack/Review would be very
welcome! Especially for the ahash-to-shash conversion patches.

v6:
- make xcbc blocksize unconditional
- add ahash-to-shash conversion patch series to entirely remove
AHASH_REQUEST_ON_STACK from the kernel

v5:
- limit AHASH_REQUEST_ON_STACK size only to non-async hash wrapping.
- sanity-check ahash reqsize only when doing shash wrapping.
- remove frame_warn changes in favor of shash conversions and other fixes.
- send ahash to shash conversion patches and other fixes separately.

v4:
- add back *_REQUEST_ON_STACK patches.
- programmatically find stack sizes for *_REQUEST_ON_STACK patches.
- whitelist some code that trips FRAME_WARN on 32-bit builds.
- fix alignment patches.

v3:
- drop *_REQUEST_ON_STACK patches. The rest of this series is pretty
straight-forward, and I'd like to get them tested in -next while
we continue to chip away at the *_REQUEST_ON_STACK VLA removal patches
separately. "Part 2" will continue with those.

v2:
- use 512 instead of PAGE_SIZE / 8 to avoid bloat on large-page archs.
- swtich xcbc to "16" max universally.
- fix typo in bounds check for dm buffer size.
- examine actual reqsizes for skcipher and ahash instead of guessing.
- improve names and comments for alg maxes

This is nearly the last of the VLA removals[1], but it's one of the
largest because crypto gets used in lots of places. After looking
through code, usage, reading the threads Gustavo started, and comparing
the use-cases to the other VLA removals that have landed in the kernel,
I think this series is likely the best way forward to shut the door on
VLAs forever.

For background, the crypto stack usage is for callers to do an immediate
bit of work that doesn't allocate new memory. This means that other VLA
removal techniques (like just using kmalloc) aren't workable, and the
next common technique is needed: examination of maximum stack usage and
the addition of sanity checks. This series does that, and in several
cases, these maximums were already implicit in the code.

This series is intended to land via the crypto tree for 4.19, though it
touches dm, networking, and a few other things as well, since there are
dependent patches (new crypto #defines being used, etc).

Thanks!

-Kees

[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Ard Biesheuvel (1):
crypto: ccm: Remove VLA usage

Kees Cook (17):
crypto: xcbc: Remove VLA usage
crypto: cbc: Remove VLA usage
crypto: hash: Remove VLA usage
dm: Remove VLA usage from hashes
crypto alg: Introduce generic max blocksize and alignmask
crypto: qat: Remove VLA usage
crypto: shash: Remove VLA usage in unaligned hashing
crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK
ppp: mppe: Remove VLA usage
x86/power/64: Remove VLA usage
dm crypt: Convert essiv from ahash to shash
drbd: Convert from ahash to shash
wireless/lib80211: Convert from ahash to shash
staging: rtl8192u: ieee80211: Convert from ahash to shash
staging: rtl8192e: ieee80211: Convert from ahash to shash
rxrpc: Reuse SKCIPHER_REQUEST_ON_STACK buffer
crypto: Remove AHASH_REQUEST_ON_STACK

--
2.17.1

[PATCH v6 07/18] crypto: shash: Remove VLA usage in unaligned hashing

In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since this helper was the only user.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 crypto/shash.c   | 27 ---
 include/linux/compiler-gcc.h |  1 -
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/crypto/shash.c b/crypto/shash.c
index 86d76b5c626c..d21f04d70dce 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -73,13 +73,6 @@ int crypto_shash_setkey(struct crypto_shash *tfm, const u8 
*key,
 }
 EXPORT_SYMBOL_GPL(crypto_shash_setkey);
 
-static inline unsigned int shash_align_buffer_size(unsigned len,
-  unsigned long mask)
-{
-   typedef u8 __aligned_largest u8_aligned;
-   return len + (mask & ~(__alignof__(u8_aligned) - 1));
-}
-
 static int shash_update_unaligned(struct shash_desc *desc, const u8 *data,
  unsigned int len)
 {
@@ -88,11 +81,17 @@ static int shash_update_unaligned(struct shash_desc *desc, 
const u8 *data,
unsigned long alignmask = crypto_shash_alignmask(tfm);
unsigned int unaligned_len = alignmask + 1 -
 ((unsigned long)data & alignmask);
-   u8 ubuf[shash_align_buffer_size(unaligned_len, alignmask)]
-   __aligned_largest;
+   /*
+* We cannot count on __aligned() working for large values:
+* https://patchwork.kernel.org/patch/9507697/
+*/
+   u8 ubuf[MAX_ALGAPI_ALIGNMASK * 2];
u8 *buf = PTR_ALIGN(&ubuf[0], alignmask + 1);
int err;
 
+   if (WARN_ON(buf + unaligned_len > ubuf + sizeof(ubuf)))
+   return -EINVAL;
+
if (unaligned_len > len)
unaligned_len = len;
 
@@ -124,11 +123,17 @@ static int shash_final_unaligned(struct shash_desc *desc, 
u8 *out)
unsigned long alignmask = crypto_shash_alignmask(tfm);
struct shash_alg *shash = crypto_shash_alg(tfm);
unsigned int ds = crypto_shash_digestsize(tfm);
-   u8 ubuf[shash_align_buffer_size(ds, alignmask)]
-   __aligned_largest;
+   /*
+* We cannot count on __aligned() working for large values:
+* https://patchwork.kernel.org/patch/9507697/
+*/
+   u8 ubuf[MAX_ALGAPI_ALIGNMASK + HASH_MAX_DIGESTSIZE];
u8 *buf = PTR_ALIGN(&ubuf[0], alignmask + 1);
int err;
 
+   if (WARN_ON(buf + ds > ubuf + sizeof(ubuf)))
+   return -EINVAL;
+
err = shash->final(desc, buf);
if (err)
goto out;
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index f1a7492a5cc8..1f1cdef36a82 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -125,7 +125,6 @@
  */
 #define __pure __attribute__((pure))
 #define __aligned(x)   __attribute__((aligned(x)))
-#define __aligned_largest  __attribute__((aligned))
 #define __printf(a, b) __attribute__((format(printf, a, b)))
 #define __scanf(a, b)  __attribute__((format(scanf, a, b)))
 #define __attribute_const____attribute__((__const__))
-- 
2.17.1

[PATCH v6 09/18] ppp: mppe: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK (and associated
VLA) by switching to shash directly and keeping the associated descriptor
allocated with the regular state on the heap.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
Acked-by: Arnd Bergmann 
---
 drivers/net/ppp/ppp_mppe.c | 56 --
 1 file changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index 6c7fd98cb00a..a205750b431b 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -96,7 +96,7 @@ static inline void sha_pad_init(struct sha_pad *shapad)
  */
 struct ppp_mppe_state {
struct crypto_skcipher *arc4;
-   struct crypto_ahash *sha1;
+   struct shash_desc *sha1;
unsigned char *sha1_digest;
unsigned char master_key[MPPE_MAX_KEY_LEN];
unsigned char session_key[MPPE_MAX_KEY_LEN];
@@ -136,25 +136,16 @@ struct ppp_mppe_state {
  */
 static void get_new_key_from_sha(struct ppp_mppe_state * state)
 {
-   AHASH_REQUEST_ON_STACK(req, state->sha1);
-   struct scatterlist sg[4];
-   unsigned int nbytes;
-
-   sg_init_table(sg, 4);
-
-   nbytes = setup_sg(&sg[0], state->master_key, state->keylen);
-   nbytes += setup_sg(&sg[1], sha_pad->sha_pad1,
-  sizeof(sha_pad->sha_pad1));
-   nbytes += setup_sg(&sg[2], state->session_key, state->keylen);
-   nbytes += setup_sg(&sg[3], sha_pad->sha_pad2,
-  sizeof(sha_pad->sha_pad2));
-
-   ahash_request_set_tfm(req, state->sha1);
-   ahash_request_set_callback(req, 0, NULL, NULL);
-   ahash_request_set_crypt(req, sg, state->sha1_digest, nbytes);
-
-   crypto_ahash_digest(req);
-   ahash_request_zero(req);
+   crypto_shash_init(state->sha1);
+   crypto_shash_update(state->sha1, state->master_key,
+   state->keylen);
+   crypto_shash_update(state->sha1, sha_pad->sha_pad1,
+   sizeof(sha_pad->sha_pad1));
+   crypto_shash_update(state->sha1, state->session_key,
+   state->keylen);
+   crypto_shash_update(state->sha1, sha_pad->sha_pad2,
+   sizeof(sha_pad->sha_pad2));
+   crypto_shash_final(state->sha1, state->sha1_digest);
 }
 
 /*
@@ -200,6 +191,7 @@ static void mppe_rekey(struct ppp_mppe_state * state, int 
initial_key)
 static void *mppe_alloc(unsigned char *options, int optlen)
 {
struct ppp_mppe_state *state;
+   struct crypto_shash *shash;
unsigned int digestsize;
 
if (optlen != CILEN_MPPE + sizeof(state->master_key) ||
@@ -217,13 +209,21 @@ static void *mppe_alloc(unsigned char *options, int 
optlen)
goto out_free;
}
 
-   state->sha1 = crypto_alloc_ahash("sha1", 0, CRYPTO_ALG_ASYNC);
-   if (IS_ERR(state->sha1)) {
-   state->sha1 = NULL;
+   shash = crypto_alloc_shash("sha1", 0, 0);
+   if (IS_ERR(shash))
+   goto out_free;
+
+   state->sha1 = kmalloc(sizeof(*state->sha1) +
+crypto_shash_descsize(shash),
+ GFP_KERNEL);
+   if (!state->sha1) {
+   crypto_free_shash(shash);
goto out_free;
}
+   state->sha1->tfm = shash;
+   state->sha1->flags = 0;
 
-   digestsize = crypto_ahash_digestsize(state->sha1);
+   digestsize = crypto_shash_digestsize(shash);
if (digestsize < MPPE_MAX_KEY_LEN)
goto out_free;
 
@@ -246,7 +246,10 @@ static void *mppe_alloc(unsigned char *options, int optlen)
 
 out_free:
kfree(state->sha1_digest);
-   crypto_free_ahash(state->sha1);
+   if (state->sha1) {
+   crypto_free_shash(state->sha1->tfm);
+   kzfree(state->sha1);
+   }
crypto_free_skcipher(state->arc4);
kfree(state);
 out:
@@ -261,7 +264,8 @@ static void mppe_free(void *arg)
struct ppp_mppe_state *state = (struct ppp_mppe_state *) arg;
if (state) {
kfree(state->sha1_digest);
-   crypto_free_ahash(state->sha1);
+   crypto_free_shash(state->sha1->tfm);
+   kzfree(state->sha1);
crypto_free_skcipher(state->arc4);
kfree(state);
}
-- 
2.17.1

[PATCH v6 06/18] crypto: qat: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this uses
the new upper bound for the stack buffer. Also adds a sanity check.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 drivers/crypto/qat/qat_common/qat_algs.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/qat/qat_common/qat_algs.c 
b/drivers/crypto/qat/qat_common/qat_algs.c
index 1138e41d6805..a28edf7b792f 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -153,8 +153,8 @@ static int qat_alg_do_precomputes(struct 
icp_qat_hw_auth_algo_blk *hash,
struct sha512_state sha512;
int block_size = crypto_shash_blocksize(ctx->hash_tfm);
int digest_size = crypto_shash_digestsize(ctx->hash_tfm);
-   char ipad[block_size];
-   char opad[block_size];
+   char ipad[MAX_ALGAPI_BLOCKSIZE];
+   char opad[MAX_ALGAPI_BLOCKSIZE];
__be32 *hash_state_out;
__be64 *hash512_state_out;
int i, offset;
@@ -164,6 +164,10 @@ static int qat_alg_do_precomputes(struct 
icp_qat_hw_auth_algo_blk *hash,
shash->tfm = ctx->hash_tfm;
shash->flags = 0x0;
 
+   if (WARN_ON(block_size > sizeof(ipad) ||
+   sizeof(ipad) != sizeof(opad)))
+   return -EINVAL;
+
if (auth_keylen > block_size) {
int ret = crypto_shash_digest(shash, auth_key,
  auth_keylen, ipad);
-- 
2.17.1

[PATCH v6 08/18] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK

In the quest to remove all stack VLA usage from the kernel[1], this
caps the skcipher request size similar to other limits and adds a sanity
check at registration. Looking at instrumented tcrypt output, the largest
is for lrw:

crypt: testing lrw(aes)
crypto_skcipher_set_reqsize: 8
crypto_skcipher_set_reqsize: 88
crypto_skcipher_set_reqsize: 472

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 include/crypto/internal/skcipher.h | 1 +
 include/crypto/skcipher.h  | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/crypto/internal/skcipher.h 
b/include/crypto/internal/skcipher.h
index e42f7063f245..5035482cbe68 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -130,6 +130,7 @@ static inline struct crypto_skcipher *crypto_spawn_skcipher(
 static inline void crypto_skcipher_set_reqsize(
struct crypto_skcipher *skcipher, unsigned int reqsize)
 {
+   BUG_ON(reqsize > SKCIPHER_MAX_REQSIZE);
skcipher->reqsize = reqsize;
 }
 
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 2f327f090c3e..c48e194438cf 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -139,9 +139,11 @@ struct skcipher_alg {
struct crypto_alg base;
 };
 
+#define SKCIPHER_MAX_REQSIZE   472
+
 #define SKCIPHER_REQUEST_ON_STACK(name, tfm) \
char __##name##_desc[sizeof(struct skcipher_request) + \
-   crypto_skcipher_reqsize(tfm)] CRYPTO_MINALIGN_ATTR; \
+   SKCIPHER_MAX_REQSIZE] CRYPTO_MINALIGN_ATTR; \
struct skcipher_request *name = (void *)__##name##_desc
 
 /**
-- 
2.17.1

[PATCH v6 14/18] staging: rtl8192u: ieee80211: Convert from ahash to shash

This is an identical change to the wireless/lib80211 of the same name.
In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. By removing a layer of indirection this both improves
performance and reduces stack usage. The stack allocation will be made
a fixed size in a later patch to the crypto subsystem.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 57 +--
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index a7efaae4e25a..1088fa0aee0e 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -54,9 +54,9 @@ struct ieee80211_tkip_data {
int key_idx;
 
struct crypto_skcipher *rx_tfm_arc4;
-   struct crypto_ahash *rx_tfm_michael;
+   struct crypto_shash *rx_tfm_michael;
struct crypto_skcipher *tx_tfm_arc4;
-   struct crypto_ahash *tx_tfm_michael;
+   struct crypto_shash *tx_tfm_michael;
 
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16], tx_hdr[16];
@@ -80,8 +80,7 @@ static void *ieee80211_tkip_init(int key_idx)
goto fail;
}
 
-   priv->tx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
-   CRYPTO_ALG_ASYNC);
+   priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
"crypto API michael_mic\n");
@@ -98,8 +97,7 @@ static void *ieee80211_tkip_init(int key_idx)
goto fail;
}
 
-   priv->rx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
-   CRYPTO_ALG_ASYNC);
+   priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
printk(KERN_DEBUG "ieee80211_crypt_tkip: could not allocate "
"crypto API michael_mic\n");
@@ -111,9 +109,9 @@ static void *ieee80211_tkip_init(int key_idx)
 
 fail:
if (priv) {
-   crypto_free_ahash(priv->tx_tfm_michael);
+   crypto_free_shash(priv->tx_tfm_michael);
crypto_free_skcipher(priv->tx_tfm_arc4);
-   crypto_free_ahash(priv->rx_tfm_michael);
+   crypto_free_shash(priv->rx_tfm_michael);
crypto_free_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -127,9 +125,9 @@ static void ieee80211_tkip_deinit(void *priv)
struct ieee80211_tkip_data *_priv = priv;
 
if (_priv) {
-   crypto_free_ahash(_priv->tx_tfm_michael);
+   crypto_free_shash(_priv->tx_tfm_michael);
crypto_free_skcipher(_priv->tx_tfm_arc4);
-   crypto_free_ahash(_priv->rx_tfm_michael);
+   crypto_free_shash(_priv->rx_tfm_michael);
crypto_free_skcipher(_priv->rx_tfm_arc4);
}
kfree(priv);
@@ -500,30 +498,31 @@ static int ieee80211_tkip_decrypt(struct sk_buff *skb, 
int hdr_len, void *priv)
return keyidx;
 }
 
-static int michael_mic(struct crypto_ahash *tfm_michael, u8 *key, u8 *hdr,
+static int michael_mic(struct crypto_shash *tfm_michael, u8 *key, u8 *hdr,
   u8 *data, size_t data_len, u8 *mic)
 {
-   AHASH_REQUEST_ON_STACK(req, tfm_michael);
-   struct scatterlist sg[2];
+   SHASH_DESC_ON_STACK(desc, tfm_michael);
int err;
 
-   if (tfm_michael == NULL) {
-   printk(KERN_WARNING "michael_mic: tfm_michael == NULL\n");
-   return -1;
-   }
-
-   sg_init_table(sg, 2);
-   sg_set_buf(&sg[0], hdr, 16);
-   sg_set_buf(&sg[1], data, data_len);
+   desc->tfm = tfm_michael;
+   desc->flags = 0;
 
-   if (crypto_ahash_setkey(tfm_michael, key, 8))
+   if (crypto_shash_setkey(tfm_michael, key, 8))
return -1;
 
-   ahash_request_set_tfm(req, tfm_michael);
-   ahash_request_set_callback(req, 0, NULL, NULL);
-   ahash_request_set_crypt(req, sg, mic, data_len + 16);
-   err = crypto_ahash_digest(req);
-   ahash_request_zero(req);
+   err = crypto_shash_init(desc);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, hdr, 16);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, data, data_len);
+   if (err)
+   goto out;
+   err = crypto_shash_final(desc, mic);
+
+out:
+   shash_desc_zero(desc);
return err;
 }
 
@@ -663,9 +662,9 @@ stat

[PATCH v6 13/18] wireless/lib80211: Convert from ahash to shash

In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. By removing a layer of indirection this both improves
performance and reduces stack usage. The stack allocation will be made
a fixed size in a later patch to the crypto subsystem.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 net/wireless/lib80211_crypt_tkip.c | 58 +++---
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/net/wireless/lib80211_crypt_tkip.c 
b/net/wireless/lib80211_crypt_tkip.c
index ba0a1f398ce5..21040aba3a81 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -65,9 +65,9 @@ struct lib80211_tkip_data {
int key_idx;
 
struct crypto_skcipher *rx_tfm_arc4;
-   struct crypto_ahash *rx_tfm_michael;
+   struct crypto_shash *rx_tfm_michael;
struct crypto_skcipher *tx_tfm_arc4;
-   struct crypto_ahash *tx_tfm_michael;
+   struct crypto_shash *tx_tfm_michael;
 
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16], tx_hdr[16];
@@ -106,8 +106,7 @@ static void *lib80211_tkip_init(int key_idx)
goto fail;
}
 
-   priv->tx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
- CRYPTO_ALG_ASYNC);
+   priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
priv->tx_tfm_michael = NULL;
goto fail;
@@ -120,8 +119,7 @@ static void *lib80211_tkip_init(int key_idx)
goto fail;
}
 
-   priv->rx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
- CRYPTO_ALG_ASYNC);
+   priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
priv->rx_tfm_michael = NULL;
goto fail;
@@ -131,9 +129,9 @@ static void *lib80211_tkip_init(int key_idx)
 
   fail:
if (priv) {
-   crypto_free_ahash(priv->tx_tfm_michael);
+   crypto_free_shash(priv->tx_tfm_michael);
crypto_free_skcipher(priv->tx_tfm_arc4);
-   crypto_free_ahash(priv->rx_tfm_michael);
+   crypto_free_shash(priv->rx_tfm_michael);
crypto_free_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -145,9 +143,9 @@ static void lib80211_tkip_deinit(void *priv)
 {
struct lib80211_tkip_data *_priv = priv;
if (_priv) {
-   crypto_free_ahash(_priv->tx_tfm_michael);
+   crypto_free_shash(_priv->tx_tfm_michael);
crypto_free_skcipher(_priv->tx_tfm_arc4);
-   crypto_free_ahash(_priv->rx_tfm_michael);
+   crypto_free_shash(_priv->rx_tfm_michael);
crypto_free_skcipher(_priv->rx_tfm_arc4);
}
kfree(priv);
@@ -510,29 +508,31 @@ static int lib80211_tkip_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
return keyidx;
 }
 
-static int michael_mic(struct crypto_ahash *tfm_michael, u8 * key, u8 * hdr,
-  u8 * data, size_t data_len, u8 * mic)
+static int michael_mic(struct crypto_shash *tfm_michael, u8 *key, u8 *hdr,
+  u8 *data, size_t data_len, u8 *mic)
 {
-   AHASH_REQUEST_ON_STACK(req, tfm_michael);
-   struct scatterlist sg[2];
+   SHASH_DESC_ON_STACK(desc, tfm_michael);
int err;
 
-   if (tfm_michael == NULL) {
-   pr_warn("%s(): tfm_michael == NULL\n", __func__);
-   return -1;
-   }
-   sg_init_table(sg, 2);
-   sg_set_buf(&sg[0], hdr, 16);
-   sg_set_buf(&sg[1], data, data_len);
+   desc->tfm = tfm_michael;
+   desc->flags = 0;
 
-   if (crypto_ahash_setkey(tfm_michael, key, 8))
+   if (crypto_shash_setkey(tfm_michael, key, 8))
return -1;
 
-   ahash_request_set_tfm(req, tfm_michael);
-   ahash_request_set_callback(req, 0, NULL, NULL);
-   ahash_request_set_crypt(req, sg, mic, data_len + 16);
-   err = crypto_ahash_digest(req);
-   ahash_request_zero(req);
+   err = crypto_shash_init(desc);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, hdr, 16);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, data, data_len);
+   if (err)
+   goto out;
+   err = crypto_shash_final(desc, mic);
+
+out:
+   shash_desc_zero(desc);
return err;
 }
 
@@ -654,9 +654,9 @@ static int lib80211_tkip_set_key(void *key, int len, u8 * 
seq, void *priv)
 {
struct lib80211_tkip_data *tkey = priv;
int keyidx;
-   struct crypto_ahash *tfm = tkey->tx_tf

[PATCH v6 12/18] drbd: Convert from ahash to shash

In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. By removing a layer of indirection this both improves
performance and reduces stack usage. The stack allocation will be made
a fixed size in a later patch to the crypto subsystem.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 drivers/block/drbd/drbd_int.h  | 13 +++
 drivers/block/drbd/drbd_main.c | 14 
 drivers/block/drbd/drbd_nl.c   | 39 +++--
 drivers/block/drbd/drbd_receiver.c | 35 ++-
 drivers/block/drbd/drbd_worker.c   | 56 +-
 5 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index bc4ed2ed40a2..97d8e290c2be 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -726,10 +726,10 @@ struct drbd_connection {
struct list_head transfer_log;  /* all requests not yet fully processed 
*/
 
struct crypto_shash *cram_hmac_tfm;
-   struct crypto_ahash *integrity_tfm;  /* checksums we compute, updates 
protected by connection->data->mutex */
-   struct crypto_ahash *peer_integrity_tfm;  /* checksums we verify, only 
accessed from receiver thread  */
-   struct crypto_ahash *csums_tfm;
-   struct crypto_ahash *verify_tfm;
+   struct crypto_shash *integrity_tfm;  /* checksums we compute, updates 
protected by connection->data->mutex */
+   struct crypto_shash *peer_integrity_tfm;  /* checksums we verify, only 
accessed from receiver thread  */
+   struct crypto_shash *csums_tfm;
+   struct crypto_shash *verify_tfm;
void *int_dig_in;
void *int_dig_vv;
 
@@ -1533,8 +1533,9 @@ static inline void ov_out_of_sync_print(struct 
drbd_device *device)
 }
 
 
-extern void drbd_csum_bio(struct crypto_ahash *, struct bio *, void *);
-extern void drbd_csum_ee(struct crypto_ahash *, struct drbd_peer_request *, 
void *);
+extern void drbd_csum_bio(struct crypto_shash *, struct bio *, void *);
+extern void drbd_csum_ee(struct crypto_shash *, struct drbd_peer_request *,
+void *);
 /* worker callbacks */
 extern int w_e_end_data_req(struct drbd_work *, int);
 extern int w_e_end_rsdata_req(struct drbd_work *, int);
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index a80809bd3057..ccb54791d39c 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -1377,7 +1377,7 @@ void drbd_send_ack_dp(struct drbd_peer_device 
*peer_device, enum drbd_packet cmd
  struct p_data *dp, int data_size)
 {
if (peer_device->connection->peer_integrity_tfm)
-   data_size -= 
crypto_ahash_digestsize(peer_device->connection->peer_integrity_tfm);
+   data_size -= 
crypto_shash_digestsize(peer_device->connection->peer_integrity_tfm);
_drbd_send_ack(peer_device, cmd, dp->sector, cpu_to_be32(data_size),
   dp->block_id);
 }
@@ -1690,7 +1690,7 @@ int drbd_send_dblock(struct drbd_peer_device 
*peer_device, struct drbd_request *
sock = &peer_device->connection->data;
p = drbd_prepare_command(peer_device, sock);
digest_size = peer_device->connection->integrity_tfm ?
- 
crypto_ahash_digestsize(peer_device->connection->integrity_tfm) : 0;
+ 
crypto_shash_digestsize(peer_device->connection->integrity_tfm) : 0;
 
if (!p)
return -EIO;
@@ -1796,7 +1796,7 @@ int drbd_send_block(struct drbd_peer_device *peer_device, 
enum drbd_packet cmd,
p = drbd_prepare_command(peer_device, sock);
 
digest_size = peer_device->connection->integrity_tfm ?
- 
crypto_ahash_digestsize(peer_device->connection->integrity_tfm) : 0;
+ 
crypto_shash_digestsize(peer_device->connection->integrity_tfm) : 0;
 
if (!p)
return -EIO;
@@ -2561,11 +2561,11 @@ void conn_free_crypto(struct drbd_connection 
*connection)
 {
drbd_free_sock(connection);
 
-   crypto_free_ahash(connection->csums_tfm);
-   crypto_free_ahash(connection->verify_tfm);
+   crypto_free_shash(connection->csums_tfm);
+   crypto_free_shash(connection->verify_tfm);
crypto_free_shash(connection->cram_hmac_tfm);
-   crypto_free_ahash(connection->integrity_tfm);
-   crypto_free_ahash(connection->peer_integrity_tfm);
+   crypto_free_shash(connection->integrity_tfm);
+   crypto_free_shash(connection->peer_integrity_tfm);
kfree(connection->int_dig_in);
kfree(connection->int_dig_vv);
 
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index b4f02768ba47..d15703b1ffe8 100644
--- a/drivers/blo

[PATCH v6 15/18] staging: rtl8192e: ieee80211: Convert from ahash to shash

This is an identical change to the wireless/lib80211 of the same name.
In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
to direct shash. By removing a layer of indirection this both improves
performance and reduces stack usage. The stack allocation will be made
a fixed size in a later patch to the crypto subsystem.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
---
 drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c 
b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
index ae103b0b7a2a..9f18be14dda6 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_tkip.c
@@ -50,9 +50,9 @@ struct rtllib_tkip_data {
 
int key_idx;
struct crypto_skcipher *rx_tfm_arc4;
-   struct crypto_ahash *rx_tfm_michael;
+   struct crypto_shash *rx_tfm_michael;
struct crypto_skcipher *tx_tfm_arc4;
-   struct crypto_ahash *tx_tfm_michael;
+   struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
u8 rx_hdr[16];
u8 tx_hdr[16];
@@ -74,8 +74,7 @@ static void *rtllib_tkip_init(int key_idx)
goto fail;
}
 
-   priv->tx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
- CRYPTO_ALG_ASYNC);
+   priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
pr_debug("Could not allocate crypto API michael_mic\n");
priv->tx_tfm_michael = NULL;
@@ -90,8 +89,7 @@ static void *rtllib_tkip_init(int key_idx)
goto fail;
}
 
-   priv->rx_tfm_michael = crypto_alloc_ahash("michael_mic", 0,
- CRYPTO_ALG_ASYNC);
+   priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
pr_debug("Could not allocate crypto API michael_mic\n");
priv->rx_tfm_michael = NULL;
@@ -101,9 +99,9 @@ static void *rtllib_tkip_init(int key_idx)
 
 fail:
if (priv) {
-   crypto_free_ahash(priv->tx_tfm_michael);
+   crypto_free_shash(priv->tx_tfm_michael);
crypto_free_skcipher(priv->tx_tfm_arc4);
-   crypto_free_ahash(priv->rx_tfm_michael);
+   crypto_free_shash(priv->rx_tfm_michael);
crypto_free_skcipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -117,9 +115,9 @@ static void rtllib_tkip_deinit(void *priv)
struct rtllib_tkip_data *_priv = priv;
 
if (_priv) {
-   crypto_free_ahash(_priv->tx_tfm_michael);
+   crypto_free_shash(_priv->tx_tfm_michael);
crypto_free_skcipher(_priv->tx_tfm_arc4);
-   crypto_free_ahash(_priv->rx_tfm_michael);
+   crypto_free_shash(_priv->rx_tfm_michael);
crypto_free_skcipher(_priv->rx_tfm_arc4);
}
kfree(priv);
@@ -504,29 +502,31 @@ static int rtllib_tkip_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 }
 
 
-static int michael_mic(struct crypto_ahash *tfm_michael, u8 *key, u8 *hdr,
+static int michael_mic(struct crypto_shash *tfm_michael, u8 *key, u8 *hdr,
   u8 *data, size_t data_len, u8 *mic)
 {
-   AHASH_REQUEST_ON_STACK(req, tfm_michael);
-   struct scatterlist sg[2];
+   SHASH_DESC_ON_STACK(desc, tfm_michael);
int err;
 
-   if (tfm_michael == NULL) {
-   pr_warn("michael_mic: tfm_michael == NULL\n");
-   return -1;
-   }
-   sg_init_table(sg, 2);
-   sg_set_buf(&sg[0], hdr, 16);
-   sg_set_buf(&sg[1], data, data_len);
+   desc->tfm = tfm_michael;
+   desc->flags = 0;
 
-   if (crypto_ahash_setkey(tfm_michael, key, 8))
+   if (crypto_shash_setkey(tfm_michael, key, 8))
return -1;
 
-   ahash_request_set_tfm(req, tfm_michael);
-   ahash_request_set_callback(req, 0, NULL, NULL);
-   ahash_request_set_crypt(req, sg, mic, data_len + 16);
-   err = crypto_ahash_digest(req);
-   ahash_request_zero(req);
+   err = crypto_shash_init(desc);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, hdr, 16);
+   if (err)
+   goto out;
+   err = crypto_shash_update(desc, data, data_len);
+   if (err)
+   goto out;
+   err = crypto_shash_final(desc, mic);
+
+out:
+   shash_desc_zero(desc);
return err;
 }
 
@@ -663,9 +663,9 @@ static int rtllib_tkip_set_key(void *key, int len, u8 *seq, 
void *priv)
 {
struct rtl

[PATCH v6 11/18] dm crypt: Convert essiv from ahash to shash

In preparing to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of the
smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash to
direct shash. By removing a layer of indirection this both improves
performance and reduces stack usage. The stack allocation will be made
a fixed size in a later patch to the crypto subsystem.

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
Reviewed-by: Eric Biggers 
---
 drivers/md/dm-crypt.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index b61b069c33af..c4c922990090 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -99,7 +99,7 @@ struct crypt_iv_operations {
 };
 
 struct iv_essiv_private {
-   struct crypto_ahash *hash_tfm;
+   struct crypto_shash *hash_tfm;
u8 *salt;
 };
 
@@ -327,25 +327,22 @@ static int crypt_iv_plain64be_gen(struct crypt_config 
*cc, u8 *iv,
 static int crypt_iv_essiv_init(struct crypt_config *cc)
 {
struct iv_essiv_private *essiv = &cc->iv_gen_private.essiv;
-   AHASH_REQUEST_ON_STACK(req, essiv->hash_tfm);
-   struct scatterlist sg;
+   SHASH_DESC_ON_STACK(desc, essiv->hash_tfm);
struct crypto_cipher *essiv_tfm;
int err;
 
-   sg_init_one(&sg, cc->key, cc->key_size);
-   ahash_request_set_tfm(req, essiv->hash_tfm);
-   ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
-   ahash_request_set_crypt(req, &sg, essiv->salt, cc->key_size);
+   desc->tfm = essiv->hash_tfm;
+   desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
 
-   err = crypto_ahash_digest(req);
-   ahash_request_zero(req);
+   err = crypto_shash_digest(desc, cc->key, cc->key_size, essiv->salt);
+   shash_desc_zero(desc);
if (err)
return err;
 
essiv_tfm = cc->iv_private;
 
err = crypto_cipher_setkey(essiv_tfm, essiv->salt,
-   crypto_ahash_digestsize(essiv->hash_tfm));
+   crypto_shash_digestsize(essiv->hash_tfm));
if (err)
return err;
 
@@ -356,7 +353,7 @@ static int crypt_iv_essiv_init(struct crypt_config *cc)
 static int crypt_iv_essiv_wipe(struct crypt_config *cc)
 {
struct iv_essiv_private *essiv = &cc->iv_gen_private.essiv;
-   unsigned salt_size = crypto_ahash_digestsize(essiv->hash_tfm);
+   unsigned salt_size = crypto_shash_digestsize(essiv->hash_tfm);
struct crypto_cipher *essiv_tfm;
int r, err = 0;
 
@@ -408,7 +405,7 @@ static void crypt_iv_essiv_dtr(struct crypt_config *cc)
struct crypto_cipher *essiv_tfm;
struct iv_essiv_private *essiv = &cc->iv_gen_private.essiv;
 
-   crypto_free_ahash(essiv->hash_tfm);
+   crypto_free_shash(essiv->hash_tfm);
essiv->hash_tfm = NULL;
 
kzfree(essiv->salt);
@@ -426,7 +423,7 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, 
struct dm_target *ti,
  const char *opts)
 {
struct crypto_cipher *essiv_tfm = NULL;
-   struct crypto_ahash *hash_tfm = NULL;
+   struct crypto_shash *hash_tfm = NULL;
u8 *salt = NULL;
int err;
 
@@ -436,14 +433,14 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, 
struct dm_target *ti,
}
 
/* Allocate hash algorithm */
-   hash_tfm = crypto_alloc_ahash(opts, 0, CRYPTO_ALG_ASYNC);
+   hash_tfm = crypto_alloc_shash(opts, 0, 0);
if (IS_ERR(hash_tfm)) {
ti->error = "Error initializing ESSIV hash";
err = PTR_ERR(hash_tfm);
goto bad;
}
 
-   salt = kzalloc(crypto_ahash_digestsize(hash_tfm), GFP_KERNEL);
+   salt = kzalloc(crypto_shash_digestsize(hash_tfm), GFP_KERNEL);
if (!salt) {
ti->error = "Error kmallocing salt storage in ESSIV";
err = -ENOMEM;
@@ -454,7 +451,7 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, 
struct dm_target *ti,
cc->iv_gen_private.essiv.hash_tfm = hash_tfm;
 
essiv_tfm = alloc_essiv_cipher(cc, ti, salt,
-  crypto_ahash_digestsize(hash_tfm));
+  crypto_shash_digestsize(hash_tfm));
if (IS_ERR(essiv_tfm)) {
crypt_iv_essiv_dtr(cc);
return PTR_ERR(essiv_tfm);
@@ -465,7 +462,7 @@ static int crypt_iv_essiv_ctr(struct crypt_config *cc, 
struct dm_target *ti,
 
 bad:
if (hash_tfm && !IS_ERR(hash_tfm))
-   crypto_free_ahash(hash_tfm);
+   crypto_free_shash(hash_tfm);
kfree(salt);
return err;
 }
-- 
2.17.1

[PATCH v6 10/18] x86/power/64: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this
removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
shash directly and allocating the descriptor in heap memory (which should
be fine: the tfm has already been allocated there too).

[1] 
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

Signed-off-by: Kees Cook 
Acked-by: Pavel Machek 
---
 arch/x86/power/hibernate_64.c | 36 ---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 67ccf64c8bd8..f8e3b668d20b 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -233,29 +233,35 @@ struct restore_data_record {
  */
 static int get_e820_md5(struct e820_table *table, void *buf)
 {
-   struct scatterlist sg;
-   struct crypto_ahash *tfm;
+   struct crypto_shash *tfm;
+   struct shash_desc *desc;
int size;
int ret = 0;
 
-   tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
+   tfm = crypto_alloc_shash("md5", 0, 0);
if (IS_ERR(tfm))
return -ENOMEM;
 
-   {
-   AHASH_REQUEST_ON_STACK(req, tfm);
-   size = offsetof(struct e820_table, entries) + sizeof(struct 
e820_entry) * table->nr_entries;
-   ahash_request_set_tfm(req, tfm);
-   sg_init_one(&sg, (u8 *)table, size);
-   ahash_request_set_callback(req, 0, NULL, NULL);
-   ahash_request_set_crypt(req, &sg, buf, size);
-
-   if (crypto_ahash_digest(req))
-   ret = -EINVAL;
-   ahash_request_zero(req);
+   desc = kmalloc(sizeof(struct shash_desc) + crypto_shash_descsize(tfm),
+  GFP_KERNEL);
+   if (!desc) {
+   ret = -ENOMEM;
+   goto free_tfm;
}
-   crypto_free_ahash(tfm);
 
+   desc->tfm = tfm;
+   desc->flags = 0;
+
+   size = offsetof(struct e820_table, entries) +
+   sizeof(struct e820_entry) * table->nr_entries;
+
+   if (crypto_shash_digest(desc, (u8 *)table, size, buf))
+   ret = -EINVAL;
+
+   kzfree(desc);
+
+free_tfm:
+   crypto_free_shash(tfm);
return ret;
 }
 
-- 
2.17.1

editing for your photos

2018-07-24 Thread Roland


I would like to speak with the person that managing photos for your
company?

We provide image editing like – photos cutting out and retouching.

Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate professional, or an e-Retailer,
we are your personal team
of photo editors that integrate seamlessly with your business.

Our mainly services are:

. Cut out, masking, clipping path, deep etching, transparent background
. Colour correction, black and white, light and shadows etc.
. Dust cleaning, spot cleaning
. Beauty retouching, skin retouching, face retouching, body retouching
. Fashion/Beauty Image Retouching
. Product image Retouching
. Real estate image Retouching
. Wedding & Event Album Design.
. Restoration and repair old images
. Vector Conversion
. Portrait image Retouching

We can provide you editing test on your photos.
Please reply if you are interested.

Thanks,
Roland

Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Simon Horman

On Tue, Jul 24, 2018 at 01:13:25PM +0200, Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
> 
> This converts them all to UTF-8 for consistency.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  .../devicetree/bindings/net/nfc/pn544.txt |   2 +-
>  arch/arm/boot/dts/sun4i-a10-inet97fv2.dts |   2 +-
>  arch/arm/crypto/sha256_glue.c |   2 +-
>  arch/arm/crypto/sha256_neon_glue.c|   4 +-
>  drivers/crypto/vmx/ghashp8-ppc.pl |  12 +-
>  drivers/iio/dac/ltc2632.c |   2 +-
>  drivers/power/reset/ltc2952-poweroff.c|   4 +-
>  kernel/events/callchain.c |   2 +-
>  net/netfilter/ipvs/Kconfig|   8 +-
>  net/netfilter/ipvs/ip_vs_mh.c |   4 +-

IPVS portion:

Acked-by: Simon Horman 


>  tools/power/cpupower/po/de.po |  44 +++
>  tools/power/cpupower/po/fr.po | 120 +-
>  12 files changed, 103 insertions(+), 103 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt 
> b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> index 538a86f7b2b0..72593f056b75 100644
> --- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
> @@ -2,7 +2,7 @@
>  
>  Required properties:
>  - compatible: Should be "nxp,pn544-i2c".
> -- clock-frequency: I�C work frequency.
> +- clock-frequency: I²C work frequency.
>  - reg: address on the bus
>  - interrupt-parent: phandle for the interrupt gpio controller
>  - interrupts: GPIO interrupt to which the chip is connected
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index 5d096528e75a..71c27ea0b53e 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -1,7 +1,7 @@
>  /*
>   * Copyright 2014 Open Source Support GmbH
>   *
> - * David Lanzend�rfer 
> + * David Lanzendörfer 
>   *
>   * This file is dual-licensed: you can use it either under the terms
>   * of the GPL or the X11 license, at your option. Note that this dual
> diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
> index bf8ccff2c9d0..0ae900e778f3 100644
> --- a/arch/arm/crypto/sha256_glue.c
> +++ b/arch/arm/crypto/sha256_glue.c
> @@ -2,7 +2,7 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using optimized ARM assembler and NEON instructions.
>   *
> - * Copyright � 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha256_ssse3_glue.c:
>   *   Copyright (C) 2013 Intel Corporation
> diff --git a/arch/arm/crypto/sha256_neon_glue.c 
> b/arch/arm/crypto/sha256_neon_glue.c
> index 9bbee56fbdc8..1d82c6cd31a4 100644
> --- a/arch/arm/crypto/sha256_neon_glue.c
> +++ b/arch/arm/crypto/sha256_neon_glue.c
> @@ -2,10 +2,10 @@
>   * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
>   * using NEON instructions.
>   *
> - * Copyright � 2015 Google Inc.
> + * Copyright © 2015 Google Inc.
>   *
>   * This file is based on sha512_neon_glue.c:
> - *   Copyright � 2014 Jussi Kivilinna 
> + *   Copyright © 2014 Jussi Kivilinna 
>   *
>   * This program is free software; you can redistribute it and/or modify it
>   * under the terms of the GNU General Public License as published by the Free
> diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl 
> b/drivers/crypto/vmx/ghashp8-ppc.pl
> index f746af271460..38b06503ede0 100644
> --- a/drivers/crypto/vmx/ghashp8-ppc.pl
> +++ b/drivers/crypto/vmx/ghashp8-ppc.pl
> @@ -129,9 +129,9 @@ $code=<<___;
>le?vperm   $IN,$IN,$IN,$lemask
>   vxor$zero,$zero,$zero
>  
> - vpmsumd $Xl,$IN,$Hl # H.lo�Xi.lo
> - vpmsumd $Xm,$IN,$H  # H.hi�Xi.lo+H.lo�Xi.hi
> - vpmsumd $Xh,$IN,$Hh # H.hi�Xi.hi
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>  
>   vpmsumd $t2,$Xl,$xC2# 1st phase
>  
> @@ -187,11 +187,11 @@ $code=<<___;
>  .align   5
>  Loop:
>subic  $len,$len,16
> - vpmsumd $Xl,$IN,$Hl # H.lo�Xi.lo
> + vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
>subfe. r0,r0,r0# borrow?-1:0
> - vpmsumd $Xm,$IN,$H  # H.hi�Xi.lo+H.lo�Xi.hi
> + vpmsumd $Xm,$IN,$H  # H.hi·Xi.lo+H.lo·Xi.hi
>andr0,r0,$len
> - vpmsumd $Xh,$IN,$Hh # H.hi�Xi.hi
> + vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
>add$inp,$inp,r0
>  
>   vpmsumd $t2,$

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

2018-07-24 Thread joeyli

Hi Oliver,

On Mon, Jul 23, 2018 at 01:42:36PM +0200, Oliver Neukum wrote:
> On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote:
> > Hi!
> 
> Hello,
> 
> > > Let me paste the log here:
> > > 
> > > 1. (This is not to compare with uswsusp but other
> > > tools) One advantage is: Users do not have to
> > > encrypt the whole swap partition as other tools.
> > 
> > Well.. encrypting the partition seems like good idea anyway.
> 
> Yes, but it is a policy decision the kernel should not force.
> STD needs to work anyway.
> 
> > > 2. Ideally kernel memory should be encrypted by the
> > >kernel itself. We have uswsusp to support user
> > >space hibernation, however doing the encryption
> > >in kernel space has more advantages:
> > >2.1 Not having to transfer plain text kernel memory to
> > >user space. Per Lee, Chun-Yi, uswsusp is disabled
> > >when the kernel is locked down:
> > >https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
> > >linux-fs.git/commit/?h=lockdown-20180410&
> > >id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612
> > >due to:
> > >"There have some functions be locked-down because
> > >there have no appropriate mechanisms to check the
> > >integrity of writing data."
> > >https://patchwork.kernel.org/patch/10476751/
> > 
> > So your goal is to make hibernation compatible with kernel
> > lockdown? Do your patches provide sufficient security that hibernation
> > can be enabled with kernel lockdown?
> 
> OK, maybe I am dense, but if the key comes from user space, will that
> be enough?
> 
> > >2.2 Not having to copy each page to user space
> > >one by one not in parallel, which might introduce
> > >significant amount of copy_to_user() and it might
> > >not be efficient on servers having large amount of DRAM.
> > 
> > So how big speedup can be attributed by not doing copy_to_user?
> 
> That would be an argument for compression in kernel space.
> Not encrpting would always be faster.
> 
> > >2.3 Distribution has requirement to do snapshot
> > >signature for verification, which can be built
> > >by leveraging this patch set.
> > 
> > Signatures can be done by uswsusp, too, right?
> 
> Not if you want to keep the chain of trust intact. User space
> is not signed.

Yes, any user space key helper must be authenticated for secure boot
(or the kernel locked-down mode).

If user choices the user space helper, then they should awares that
this approach can not be trusted when kernel is in locked-down mode.
The user space helper be protected by IMA/EVM, or the initrd be
authentricated with trusted boot.

The user space key helper is useful when the machine doesn't have
TPM or EFI firmware, but user still wants to use the hibernation
encryption/verification.

For kernel locked-down mode, EFI key or trusted key TPM can be
trusted because they can only be created/visibled in kernel space.

Thanks
Joey Lee

Re: CCREE performance on R-Car H3 + crash

On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
 wrote:
> Hi Gilad,
>
> CC linux-crypto for the crash log.
>
> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef  wrote:
>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
>>  wrote:
>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
>> > performance benchmarks.  The disk is an old 160 GiB SATA hard drive,
>> > connected to either Salvator-XS (R-Car H3 ES2.0) or Koelsch (R-Car M2-W).
>> >
>> > hdparm -t /dev/sda (unencrypted data): 62 MB/s (both systems)
>> >
>> > hdparm -t /dev/dm-0 (encrypted data, LUKS AES):
>> >
>> > salvator-xs (CCREE): 15 MB/s
>> > salvator-xs (SW):62 MB/s
>> > koelsch (SW):47 MB/s
>> >
>> > I'm a bit disappointment by the results when using crypto acceleration.
>> > Apparently the in-kernel optimized arm64 implementation can decrypt at
>> > raw read speed, while CCREE can't keep up.
>>
>> Interesting. What is the encryption sector size used?
>
> crypt_config.sector_size is 512.
>
>> If it is he default of 512 bytes, you might want to try setting the
>> new block_size DM-Crypt option. I believe it will have a large effect
>> on the result.
>
> Where do I specifiy that option? I couldn't find it.

It seems my memory of the config option name failed me,
I was referring to the the sector_size and iv_large_sectors options
of dm-crypt.

> Is that compatible with the encrypted media that's already in use?

No, if you created the media with 512 sector size than obviously trying to mount
with a different sector size will not work.

There is a discussion right now in the MD mailing list about changes
to DM-Crypt so that
you don't have to change the sector size and still work with larger
buffers if the HW supports
auto increment the sector number in the IV, as CryptoCell indeed knows
how to do in a newer
revision of the HW than the one that is found in the R-Car, but that
won't help us here, alas.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

Re: CCREE performance on R-Car H3 + crash

On Tue, Jul 24, 2018 at 10:51 AM, Geert Uytterhoeven
 wrote:
> Hi Gilad,
>
> On Tue, Jul 24, 2018 at 9:32 AM Gilad Ben-Yossef  wrote:
...
>> I've tried booting your tree and see the same behavior - "Unsupported
>> data size" error message but no crash.
>>
>> I'm running on an Savator-X R-Car H3 ES1.0 board.
>>
>> Not really sure how to proceed.
>>
>> Maybe you can send me your exact .config file?
>
> I cannot reproduce the crash using renesas_defconfig + 
> CONFIG_CRYPTO_DEV_CCREE=y
> + CONFIG_CRYPTO_USER_API_SKCIPHER=y.
>
> I can reproduce it on Salvator-X with R-Car H3 ES1.0 and Salvator-XS with
> R-Car H3 ES2.0 using the attached config.
>

OK, found what the problem was (SLAB vs. SLUB is what makes the
problem manifest as a crash, I think).

Just sent fixes to the crypto mailing list. I've spared the Renesas
list since it's not really related to it but CCed you.
I'd be delighted if you can give it a test.

Thank you very much for reporting and assistance!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

[PATCH 1/4] crypto: ccree: drop useless type flag during reg

Drop the explicit setting of CRYPTO_ALG_TYPE_AEAD or
CRYPTO_ALG_TYPE_SKCIPHER flags during alg registration as they are
set anyway by the framework.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/ccree/cc_aead.c   | 16 +---
 drivers/crypto/ccree/cc_cipher.c | 14 --
 drivers/crypto/ccree/cc_driver.h |  1 -
 3 files changed, 1 insertion(+), 30 deletions(-)

diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
index 03f4b9f..01b82b8 100644
--- a/drivers/crypto/ccree/cc_aead.c
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -2344,7 +2344,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha1),cbc(aes))",
.driver_name = "authenc-hmac-sha1-cbc-aes-ccree",
.blocksize = AES_BLOCK_SIZE,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2364,7 +2363,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha1),cbc(des3_ede))",
.driver_name = "authenc-hmac-sha1-cbc-des3-ccree",
.blocksize = DES3_EDE_BLOCK_SIZE,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2384,7 +2382,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha256),cbc(aes))",
.driver_name = "authenc-hmac-sha256-cbc-aes-ccree",
.blocksize = AES_BLOCK_SIZE,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2404,7 +2401,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha256),cbc(des3_ede))",
.driver_name = "authenc-hmac-sha256-cbc-des3-ccree",
.blocksize = DES3_EDE_BLOCK_SIZE,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2424,7 +2420,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(xcbc(aes),cbc(aes))",
.driver_name = "authenc-xcbc-aes-cbc-aes-ccree",
.blocksize = AES_BLOCK_SIZE,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2444,7 +2439,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha1),rfc3686(ctr(aes)))",
.driver_name = "authenc-hmac-sha1-rfc3686-ctr-aes-ccree",
.blocksize = 1,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2464,7 +2458,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(hmac(sha256),rfc3686(ctr(aes)))",
.driver_name = "authenc-hmac-sha256-rfc3686-ctr-aes-ccree",
.blocksize = 1,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2484,7 +2477,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "authenc(xcbc(aes),rfc3686(ctr(aes)))",
.driver_name = "authenc-xcbc-aes-rfc3686-ctr-aes-ccree",
.blocksize = 1,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_aead_setauthsize,
@@ -2504,7 +2496,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "ccm(aes)",
.driver_name = "ccm-aes-ccree",
.blocksize = 1,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_aead_setkey,
.setauthsize = cc_ccm_setauthsize,
@@ -2524,7 +2515,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "rfc4309(ccm(aes))",
.driver_name = "rfc4309-ccm-aes-ccree",
.blocksize = 1,
-   .type = CRYPTO_ALG_TYPE_AEAD,
.template_aead = {
.setkey = cc_rfc4309_ccm_setkey,
.setauthsize = cc_rfc4309_ccm_setauthsize,
@@ -2544,7 +2534,6 @@ static struct cc_alg_template aead_algs[] = {
.name = "gcm(aes)",
.driver_name = "gcm-aes-ccree",
.blocksize = 1,
-

[PATCH 3/4] crypto: ccree: zero all of request ctx before use

In certain error path req_ctx->iv was being freed despite
not being allocated because it was not initialized to NULL.
Rather than play whack a mole with the structure various
field, zero it before use.

This fixes a kernel panic that may occur if an invalid
buffer size was requested triggering the bug above.

Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Reported-by: Geert Uytterhoeven 
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/ccree/cc_cipher.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 64740dd..9da0ecc 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -767,7 +767,7 @@ static int cc_cipher_encrypt(struct skcipher_request *req)
 {
struct cipher_req_ctx *req_ctx = skcipher_request_ctx(req);
 
-   req_ctx->backup_info = NULL;
+   memset(req_ctx, 0, sizeof(*req_ctx));
 
return cc_cipher_process(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
 }
@@ -782,6 +782,8 @@ static int cc_cipher_decrypt(struct skcipher_request *req)
gfp_t flags = cc_gfp_flags(&req->base);
unsigned int len;
 
+   memset(req_ctx, 0, sizeof(*req_ctx));
+
if (ctx_p->cipher_mode == DRV_CIPHER_CBC) {
 
/* Allocate and save the last IV sized bytes of the source,
@@ -794,8 +796,6 @@ static int cc_cipher_decrypt(struct skcipher_request *req)
len = req->cryptlen - ivsize;
scatterwalk_map_and_copy(req_ctx->backup_info, req->src, len,
 ivsize, 0);
-   } else {
-   req_ctx->backup_info = NULL;
}
 
return cc_cipher_process(req, DRV_CRYPTO_DIRECTION_DECRYPT);
-- 
2.7.4

[PATCH 2/4] crypto: ccree: remove cipher ivgen left overs

IV generation is not available via the skcipher interface.
Remove the left over support of it from the ablkcipher days.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/ccree/cc_buffer_mgr.c |  8 ++--
 drivers/crypto/ccree/cc_cipher.c | 11 ---
 drivers/crypto/ccree/cc_cipher.h |  1 -
 3 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c 
b/drivers/crypto/ccree/cc_buffer_mgr.c
index b325774..dd948e1 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -454,9 +454,7 @@ void cc_unmap_cipher_request(struct device *dev, void *ctx,
dev_dbg(dev, "Unmapped iv: iv_dma_addr=%pad iv_size=%u\n",
&req_ctx->gen_ctx.iv_dma_addr, ivsize);
dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr,
-ivsize,
-req_ctx->is_giv ? DMA_BIDIRECTIONAL :
-DMA_TO_DEVICE);
+ivsize, DMA_TO_DEVICE);
}
/* Release pool */
if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI &&
@@ -498,9 +496,7 @@ int cc_map_cipher_request(struct cc_drvdata *drvdata, void 
*ctx,
dump_byte_array("iv", (u8 *)info, ivsize);
req_ctx->gen_ctx.iv_dma_addr =
dma_map_single(dev, (void *)info,
-  ivsize,
-  req_ctx->is_giv ? DMA_BIDIRECTIONAL :
-  DMA_TO_DEVICE);
+  ivsize, DMA_TO_DEVICE);
if (dma_mapping_error(dev, req_ctx->gen_ctx.iv_dma_addr)) {
dev_err(dev, "Mapping iv %u B at va=%pK for DMA 
failed\n",
ivsize, info);
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index eb99633..64740dd 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -743,14 +743,6 @@ static int cc_cipher_process(struct skcipher_request *req,
cc_setup_cipher_data(tfm, req_ctx, dst, src, nbytes, req, desc,
 &seq_len);
 
-   /* do we need to generate IV? */
-   if (req_ctx->is_giv) {
-   cc_req.ivgen_dma_addr[0] = req_ctx->gen_ctx.iv_dma_addr;
-   cc_req.ivgen_dma_addr_len = 1;
-   /* set the IV size (8/16 B long)*/
-   cc_req.ivgen_size = ivsize;
-   }
-
/* STAT_PHASE_3: Lock HW and push sequence */
 
rc = cc_send_request(ctx_p->drvdata, &cc_req, desc, seq_len,
@@ -775,7 +767,6 @@ static int cc_cipher_encrypt(struct skcipher_request *req)
 {
struct cipher_req_ctx *req_ctx = skcipher_request_ctx(req);
 
-   req_ctx->is_giv = false;
req_ctx->backup_info = NULL;
 
return cc_cipher_process(req, DRV_CRYPTO_DIRECTION_ENCRYPT);
@@ -807,8 +798,6 @@ static int cc_cipher_decrypt(struct skcipher_request *req)
req_ctx->backup_info = NULL;
}
 
-   req_ctx->is_giv = false;
-
return cc_cipher_process(req, DRV_CRYPTO_DIRECTION_DECRYPT);
 }
 
diff --git a/drivers/crypto/ccree/cc_cipher.h b/drivers/crypto/ccree/cc_cipher.h
index 68444cf..4dbc0a1 100644
--- a/drivers/crypto/ccree/cc_cipher.h
+++ b/drivers/crypto/ccree/cc_cipher.h
@@ -22,7 +22,6 @@ struct cipher_req_ctx {
u32 out_mlli_nents;
u8 *backup_info; /*store iv for generated IV flow*/
u8 *iv;
-   bool is_giv;
struct mlli_params mlli_params;
 };
 
-- 
2.7.4

[PATCH 0/4] crypto: ccree: fixes and cleanups

Various code clean ups and fix ups.

Gilad Ben-Yossef (4):
  crypto: ccree: drop useless type flag during reg
  crypto: ccree: remove cipher ivgen left overs
  crypto: ccree: zero all of request ctx before use
  crypto: ccree: allow bigger than sector XTS op

 drivers/crypto/ccree/cc_aead.c   | 16 +---
 drivers/crypto/ccree/cc_buffer_mgr.c |  8 ++--
 drivers/crypto/ccree/cc_cipher.c | 36 
 drivers/crypto/ccree/cc_cipher.h |  1 -
 drivers/crypto/ccree/cc_driver.h |  1 -
 5 files changed, 7 insertions(+), 55 deletions(-)

-- 
2.7.4

[PATCH 4/4] crypto: ccree: allow bigger than sector XTS op

The ccree driver had a sanity check that we are not asked
to encrypt an XTS buffer bigger than a sane sector size
since XTS IV needs to include the sector number in the IV
so this is not expected in any real use case.

Unfortunately, this breaks cryptsetup benchmark test which
has a synthetic performance test using 64k buffer of data
with the same IV.

Remove the sanity check and allow the user to hang themselves
and/or run benchmarks if they so wish.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/crypto/ccree/cc_cipher.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 9da0ecc..7623b299 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -19,8 +19,6 @@
 
 #define template_skcipher  template_u.skcipher
 
-#define CC_MIN_AES_XTS_SIZE 0x10
-#define CC_MAX_AES_XTS_SIZE 0x2000
 struct cc_cipher_handle {
struct list_head alg_list;
 };
@@ -98,8 +96,7 @@ static int validate_data_size(struct cc_cipher_ctx *ctx_p,
case S_DIN_to_AES:
switch (ctx_p->cipher_mode) {
case DRV_CIPHER_XTS:
-   if (size >= CC_MIN_AES_XTS_SIZE &&
-   size <= CC_MAX_AES_XTS_SIZE &&
+   if (size >= AES_BLOCK_SIZE &&
IS_ALIGNED(size, AES_BLOCK_SIZE))
return 0;
break;
-- 
2.7.4

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Di, 2018-07-24 at 15:03 +0200, Pavel Machek wrote:
> On Tue 2018-07-24 14:47:54, Oliver Neukum wrote:
> > On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:

Hi,

> > > Safe against what kind of attack? Please describe what kind of
> > > security you are trying to provide.
> > 
> > Unsigned code must not take over the priviledge level of signed code.
> > Hence:
> > 
> > 1. Unsigned code must not allowed to read sensitive parts of signed
> > code's memory space
> > 
> > 2. Unsigned code must not be able to alter the memory space of
> > signed code -> snapshots that are changed must not be able to be
> > resumed
> 
> Ok.
> 
> > > I don't think generating key in userspace is good enough for providing
> > > guarantees for secure-boot.
> > 
> > Why?
> 
> Because then, userpace has both key (now) and encrypted image (after
> reboot), so it can decrypt, modify, re-encrypt...?

Right. I was dense. But if the key is generated in kernel space,
the method works, doesn't it?

Regards
Oliver

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Tue 2018-07-24 13:49:41, Oliver Neukum wrote:
> On Mo, 2018-07-23 at 14:22 +0200, Pavel Machek wrote:
> 
> > > Yes. But you are objecting to encryption in kernel space at all,
> > > aren't you?
> > 
> > I don't particulary love the idea of doing hibernation encryption in
> > the kernel, correct.
> > 
> > But we have this weird thing called secure boot, some people seem to
> > want. So we may need some crypto in the kernel -- but I'd like
> > something that works with uswsusp, too. Plus, it is mandatory that
> > patch explains what security guarantees they want to provide against
> > what kinds of attacks...
> 
> Hi,
> 
> very well, maybe we should state clearly that the goal of these
> patch set is to make Secure Boot and STD coexist. Anything else
> is a nice side effect, but not the primary justification, right?
> 
> And we further agree that the model of Secure Boot requires the
> encryption to be done in kernel space, don't we?
> Furthermore IMHO the key must also be generated in trusted code,
> hence in kernel space. Yu Chen, I really cannot see how
> a symmetrical encryption with a known key can be secure.

Nicely said. Yes, this is the message I was trying to get across.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Tue 2018-07-24 14:47:54, Oliver Neukum wrote:
> On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > > >"There have some functions be locked-down because
> > > > > >there have no appropriate mechanisms to check the
> > > > > >integrity of writing data."
> > > > > >https://patchwork.kernel.org/patch/10476751/
> > > > > 
> > > > > So your goal is to make hibernation compatible with kernel
> > > > > lockdown? Do your patches provide sufficient security that hibernation
> > > > > can be enabled with kernel lockdown?
> > > > 
> > > > OK, maybe I am dense, but if the key comes from user space, will that
> > > > be enough?
> > > > 
> > > 
> > > Good point, we once tried to generate key in kernel, but people
> > > suggest to generate key in userspace and provide it to the
> > > kernel, which is what ecryptfs do currently, so it seems this
> > > should also be safe for encryption in kernel.
> > 
> > Safe against what kind of attack? Please describe what kind of
> > security you are trying to provide.
> 
> Unsigned code must not take over the priviledge level of signed code.
> Hence:
> 
> 1. Unsigned code must not allowed to read sensitive parts of signed
> code's memory space
> 
> 2. Unsigned code must not be able to alter the memory space of
> signed code -> snapshots that are changed must not be able to be
> resumed

Ok.

> > I don't think generating key in userspace is good enough for providing
> > guarantees for secure-boot.
> 
> Why?

Because then, userpace has both key (now) and encrypted image (after
reboot), so it can decrypt, modify, re-encrypt...?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > >"There have some functions be locked-down because
> > > > >there have no appropriate mechanisms to check the
> > > > >integrity of writing data."
> > > > >https://patchwork.kernel.org/patch/10476751/
> > > > 
> > > > So your goal is to make hibernation compatible with kernel
> > > > lockdown? Do your patches provide sufficient security that hibernation
> > > > can be enabled with kernel lockdown?
> > > 
> > > OK, maybe I am dense, but if the key comes from user space, will that
> > > be enough?
> > > 
> > 
> > Good point, we once tried to generate key in kernel, but people
> > suggest to generate key in userspace and provide it to the
> > kernel, which is what ecryptfs do currently, so it seems this
> > should also be safe for encryption in kernel.
> 
> Safe against what kind of attack? Please describe what kind of
> security you are trying to provide.

Unsigned code must not take over the priviledge level of signed code.
Hence:

1. Unsigned code must not allowed to read sensitive parts of signed
code's memory space

2. Unsigned code must not be able to alter the memory space of
signed code -> snapshots that are changed must not be able to be
resumed

> I don't think generating key in userspace is good enough for providing
> guarantees for secure-boot.

Why?

Regards
Oliver

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

Hi!

> > > Yes. But you are objecting to encryption in kernel space at all,
> > > aren't you?
> > 
> > I don't particulary love the idea of doing hibernation encryption in
> > the kernel, correct.
> > 
> > But we have this weird thing called secure boot, some people seem to
> > want. So we may need some crypto in the kernel -- but I'd like
> > something that works with uswsusp, too. Plus, it is mandatory that
> > patch explains what security guarantees they want to provide against
> > what kinds of attacks...
> > 
> > Lee, Chun-Yi's patch seemed more promising. Pavel
> > 
> The only difference between Chun-Yi's hibernation encrytion solution
> and our solution is that his strategy encrypts the snapshot from sratch, 
> and ours encryts each page before them going to block device. The benefit
> of his solution is that the snapshot can be encrypt in kernel first
> thus the uswsusp is allowed  to read it to user space even kernel
> is lock down. And I had a discussion with Chun-Yi that we can use
> his snapshot solution to make uswsusp happy, and we share the crypto
> help code and he can also use our user provided key for his signature.
> >From this point of view, our code are actually the same, except that
> we can help clean up the code and also enhance some encrytion process
> for his solution. I don't know why you don't like encryption in kernel, 
> because from my point of view, without encryption hibernation in kernel,
> uswsusp could not be enabled if kernel is lock down : -) Or do I miss 
> something?

We can do encryption in kernel if really needed, but I don't have to
like it, do I? :-).

I understand what Chun-Yi's code is trying to do. I can't say the same
about yours.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

Hi!

> > > >"There have some functions be locked-down because
> > > >there have no appropriate mechanisms to check the
> > > >integrity of writing data."
> > > >https://patchwork.kernel.org/patch/10476751/
> > > 
> > > So your goal is to make hibernation compatible with kernel
> > > lockdown? Do your patches provide sufficient security that hibernation
> > > can be enabled with kernel lockdown?
> > 
> > OK, maybe I am dense, but if the key comes from user space, will that
> > be enough?
> > 
> Good point, we once tried to generate key in kernel, but people
> suggest to generate key in userspace and provide it to the
> kernel, which is what ecryptfs do currently, so it seems this
> should also be safe for encryption in kernel.

Safe against what kind of attack? Please describe what kind of
security you are trying to provide.

I don't think generating key in userspace is good enough for providing
guarantees for secure-boot.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Mo, 2018-07-23 at 14:22 +0200, Pavel Machek wrote:

> > Yes. But you are objecting to encryption in kernel space at all,
> > aren't you?
> 
> I don't particulary love the idea of doing hibernation encryption in
> the kernel, correct.
> 
> But we have this weird thing called secure boot, some people seem to
> want. So we may need some crypto in the kernel -- but I'd like
> something that works with uswsusp, too. Plus, it is mandatory that
> patch explains what security guarantees they want to provide against
> what kinds of attacks...

Hi,

very well, maybe we should state clearly that the goal of these
patch set is to make Secure Boot and STD coexist. Anything else
is a nice side effect, but not the primary justification, right?

And we further agree that the model of Secure Boot requires the
encryption to be done in kernel space, don't we?
Furthermore IMHO the key must also be generated in trusted code,
hence in kernel space. Yu Chen, I really cannot see how
a symmetrical encryption with a known key can be secure.

Regards
Oliver

Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption

On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote:
> Hi,
> On Mon, Jul 23, 2018 at 01:42:36PM +0200, Oliver Neukum wrote:
> > On Fr, 2018-07-20 at 12:25 +0200, Pavel Machek wrote:

> > > So your goal is to make hibernation compatible with kernel
> > > lockdown? Do your patches provide sufficient security that hibernation
> > > can be enabled with kernel lockdown?
> > 
> > OK, maybe I am dense, but if the key comes from user space, will that
> > be enough?
> > 
> 
> Good point, we once tried to generate key in kernel, but people
> suggest to generate key in userspace and provide it to the
> kernel, which is what ecryptfs do currently, so it seems this
> should also be safe for encryption in kernel.
> https://www.spinics.net/lists/linux-crypto/msg33145.html
> Thus Chun-Yi's signature can use EFI key and both the key from
> user space.

It seems to me that your initial reasoning was correct and the key
should be generated in kernel space.

Regards
Oliver

[PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8

2018-07-24 Thread Arnd Bergmann

Almost all files in the kernel are either plain text or UTF-8
encoded. A couple however are ISO_8859-1, usually just a few
characters in a C comments, for historic reasons.

This converts them all to UTF-8 for consistency.

Signed-off-by: Arnd Bergmann 
---
 .../devicetree/bindings/net/nfc/pn544.txt |   2 +-
 arch/arm/boot/dts/sun4i-a10-inet97fv2.dts |   2 +-
 arch/arm/crypto/sha256_glue.c |   2 +-
 arch/arm/crypto/sha256_neon_glue.c|   4 +-
 drivers/crypto/vmx/ghashp8-ppc.pl |  12 +-
 drivers/iio/dac/ltc2632.c |   2 +-
 drivers/power/reset/ltc2952-poweroff.c|   4 +-
 kernel/events/callchain.c |   2 +-
 net/netfilter/ipvs/Kconfig|   8 +-
 net/netfilter/ipvs/ip_vs_mh.c |   4 +-
 tools/power/cpupower/po/de.po |  44 +++
 tools/power/cpupower/po/fr.po | 120 +-
 12 files changed, 103 insertions(+), 103 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt 
b/Documentation/devicetree/bindings/net/nfc/pn544.txt
index 538a86f7b2b0..72593f056b75 100644
--- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
+++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
@@ -2,7 +2,7 @@
 
 Required properties:
 - compatible: Should be "nxp,pn544-i2c".
-- clock-frequency: I?C work frequency.
+- clock-frequency: I??C work frequency.
 - reg: address on the bus
 - interrupt-parent: phandle for the interrupt gpio controller
 - interrupts: GPIO interrupt to which the chip is connected
diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
index 5d096528e75a..71c27ea0b53e 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
@@ -1,7 +1,7 @@
 /*
  * Copyright 2014 Open Source Support GmbH
  *
- * David Lanzend?rfer 
+ * David Lanzend??rfer 
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the GPL or the X11 license, at your option. Note that this dual
diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
index bf8ccff2c9d0..0ae900e778f3 100644
--- a/arch/arm/crypto/sha256_glue.c
+++ b/arch/arm/crypto/sha256_glue.c
@@ -2,7 +2,7 @@
  * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
  * using optimized ARM assembler and NEON instructions.
  *
- * Copyright ? 2015 Google Inc.
+ * Copyright ?? 2015 Google Inc.
  *
  * This file is based on sha256_ssse3_glue.c:
  *   Copyright (C) 2013 Intel Corporation
diff --git a/arch/arm/crypto/sha256_neon_glue.c 
b/arch/arm/crypto/sha256_neon_glue.c
index 9bbee56fbdc8..1d82c6cd31a4 100644
--- a/arch/arm/crypto/sha256_neon_glue.c
+++ b/arch/arm/crypto/sha256_neon_glue.c
@@ -2,10 +2,10 @@
  * Glue code for the SHA256 Secure Hash Algorithm assembly implementation
  * using NEON instructions.
  *
- * Copyright ? 2015 Google Inc.
+ * Copyright ?? 2015 Google Inc.
  *
  * This file is based on sha512_neon_glue.c:
- *   Copyright ? 2014 Jussi Kivilinna 
+ *   Copyright ?? 2014 Jussi Kivilinna 
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl 
b/drivers/crypto/vmx/ghashp8-ppc.pl
index f746af271460..38b06503ede0 100644
--- a/drivers/crypto/vmx/ghashp8-ppc.pl
+++ b/drivers/crypto/vmx/ghashp8-ppc.pl
@@ -129,9 +129,9 @@ $code=<<___;
 le?vperm   $IN,$IN,$IN,$lemask
vxor$zero,$zero,$zero
 
-   vpmsumd $Xl,$IN,$Hl # H.lo?Xi.lo
-   vpmsumd $Xm,$IN,$H  # H.hi?Xi.lo+H.lo?Xi.hi
-   vpmsumd $Xh,$IN,$Hh # H.hi?Xi.hi
+   vpmsumd $Xl,$IN,$Hl # H.lo??Xi.lo
+   vpmsumd $Xm,$IN,$H  # H.hi??Xi.lo+H.lo??Xi.hi
+   vpmsumd $Xh,$IN,$Hh # H.hi??Xi.hi
 
vpmsumd $t2,$Xl,$xC2# 1st phase
 
@@ -187,11 +187,11 @@ $code=<<___;
 .align 5
 Loop:
 subic  $len,$len,16
-   vpmsumd $Xl,$IN,$Hl # H.lo?Xi.lo
+   vpmsumd $Xl,$IN,$Hl # H.lo??Xi.lo
 subfe. r0,r0,r0# borrow?-1:0
-   vpmsumd $Xm,$IN,$H  # H.hi?Xi.lo+H.lo?Xi.hi
+   vpmsumd $Xm,$IN,$H  # H.hi??Xi.lo+H.lo??Xi.hi
 andr0,r0,$len
-   vpmsumd $Xh,$IN,$Hh # H.hi?Xi.hi
+   vpmsumd $Xh,$IN,$Hh # H.hi??Xi.hi
 add$inp,$inp,r0
 
vpmsumd $t2,$Xl,$xC2# 1st phase
diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index cca278eaa138..885105135580 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -1,7 +1,7 @@
 /*
  * LTC2632 Digital to analog convertors spi driver
  *
- * Copy

Re: CCREE performance on R-Car H3 + crash

2018-07-24 Thread Geert Uytterhoeven

Hi Gilad,

On Tue, Jul 24, 2018 at 9:32 AM Gilad Ben-Yossef  wrote:
> On Mon, Jul 23, 2018 at 5:35 PM, Geert Uytterhoeven
>  wrote:
> > On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef  
> > wrote:
> >> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef  
> >> wrote:
> >> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> >> >  wrote:
> >> >> CC linux-crypto for the crash log.
> >> >>
> >> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef  
> >> >> wrote:
> >> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> >> >>>  wrote:
> >> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some 
> >> >>> > small
> >> > ...
> >> >>
> >> >> $ cryptsetup benchmark
> >> >> # Tests are approximate using memory only (no storage IO).
> >> >> PBKDF2-sha1   478364 iterations per second for 256-bit key
> >> >> PBKDF2-sha256 927943 iterations per second for 256-bit key
> >> >> PBKDF2-sha512 360583 iterations per second for 256-bit key
> >> >> PBKDF2-ripemd160  266677 iterations per second for 256-bit key
> >> >> PBKDF2-whirlpool  115787 iterations per second for 256-bit key
> >> >> #  Algorithm | Key |  Encryption |  Decryption
> >> >>  aes-cbc   128b46.0 MiB/s46.7 MiB/s
> >> >>  serpent-cbc   128b   N/A   N/A
> >> >>  twofish-cbc   128b   N/A   N/A
> >> >>  aes-cbc   256b46.5 MiB/s46.4 MiB/s
> >> >>  serpent-cbc   256b   N/A   N/A
> >> >>  twofish-cbc   256b   N/A   N/A
> >> >> Segmentation fault
> >> >>
> >> >> Oops.
> >> >>
> >> >> ccree e6601000.crypto: Unsupported data size 65536.
> >> >> Unable to handle kernel paging request at virtual address 
> >> >> ffbf5c3c3c20
> >> >
> >> > Oy. Thank you for reporting this. I'll take a look at what is going on 
> >> > ASAP.
> >>
> >> hmm... well, the plot thickens.
> >>
> >> I was able to recreate the "Unsupported data size 65536" message and
> >> now trying to understand
> >> why the check that causes it is there but - I wasn't able to get a
> >> crash, nor do I understand why
> >> this condition would result in a crash (it ends up returning -EINVAL)... 
> >> :-(
> >>
> >> I am surely using a different tree though - I'm based on the
> >> cryptodev/master tree with cherry picking of just R-Car ccree clocks
> >> and enabling.
> >>
> >> I was thinking maybe it's a fix that is already in upstream cryptodev
> >> tree but not in your tree but didn't manage to identify any obvious
> >> suspects
> >>
> >> What tree are you based off?
> >
> > My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/
> >
> > Do you want me to try something different?
>
> I've tried booting your tree and see the same behavior - "Unsupported
> data size" error message but no crash.
>
> I'm running on an Savator-X R-Car H3 ES1.0 board.
>
> Not really sure how to proceed.
>
> Maybe you can send me your exact .config file?

I cannot reproduce the crash using renesas_defconfig + CONFIG_CRYPTO_DEV_CCREE=y
+ CONFIG_CRYPTO_USER_API_SKCIPHER=y.

I can reproduce it on Salvator-X with R-Car H3 ES1.0 and Salvator-XS with
R-Car H3 ES2.0 using the attached config.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


config-salvator-x.gz
Description: application/gzip

Re: CCREE performance on R-Car H3 + crash