[PATCH] crypto: Add ECB dependency for XTS mode

2017-02-22 Thread Milan Broz
Since the
   commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
   crypto: xts - Convert to skcipher
the XTS mode is based on ECB, so the mode must select
ECB otherwise it can fail to initialize.

Signed-off-by: Milan Broz 
---
 crypto/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..9c245eb0dd83 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -374,6 +374,7 @@ config CRYPTO_XTS
select CRYPTO_BLKCIPHER
select CRYPTO_MANAGER
select CRYPTO_GF128MUL
+   select CRYPTO_ECB
help
  XTS: IEEE1619/D16 narrow block cipher use with aes-xts-plain,
  key size 256, 384 or 512 bits. This implementation currently
-- 
2.11.0



[PATCH] crypto: brcm: fix spelling mistake: "genereate" -> "generate"

2017-02-22 Thread Colin King
From: Colin Ian King 

trivial fix to spelling mistake in pr_err message

Signed-off-by: Colin Ian King 
---
 drivers/crypto/bcm/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/bcm/util.c b/drivers/crypto/bcm/util.c
index 0502f46..430c557 100644
--- a/drivers/crypto/bcm/util.c
+++ b/drivers/crypto/bcm/util.c
@@ -312,7 +312,7 @@ int do_shash(unsigned char *name, unsigned char *result,
}
rc = crypto_shash_final(>shash, result);
if (rc)
-   pr_err("%s: Could not genereate %s hash", __func__, name);
+   pr_err("%s: Could not generate %s hash", __func__, name);
 
 do_shash_err:
crypto_free_shash(hash);
-- 
2.10.2



Re: [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi

2017-02-22 Thread Jon Mason
On Wed, Feb 22, 2017 at 4:22 PM, Steve Lin  wrote:
> Adds crypto hardware (SPU) to Northstar Plus device tree file.
>
> Signed-off-by: Steve Lin 

Looks good to me!

Acked-by: Jon Mason 

>
> ---
> Code changes for this addition were submitted previously by Rob
> Rice: 
> https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=9d12ba86f818aa9cfe9f01b750336aa441f2ffa2
> ---
>  arch/arm/boot/dts/bcm-nsp.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index b6142bd..9bac0c8 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -241,6 +241,12 @@
> brcm,nand-has-wp;
> };
>
> +   crypto@2f000 {
> +   compatible = "brcm,spum-nsp-crypto";
> +   reg = <0x2f000 0x900>;
> +   mboxes = < 0>;
> +   };
> +
> gpiob: gpio@3 {
> compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
> reg = <0x3 0x50>;
> --
> 2.1.0
>


Re: crypto: xts: regression in 4.10

2017-02-22 Thread Nicolas Porcel
On Wed, Feb 22, 2017 at 12:31:30PM +0100, Milan Broz wrote:
> Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much 
> earlier:-)

I was surprised that it was still broken in the mainline release. All
the other regressions I had have been fixed. Also, I guess LUKS with
aes-xts is quite standard.

> I guess either there is a bug in some specific dependency missing
> dependency in kernel config. Could you send your kernel .config that fails?
> 
> Do you have ECB mode compiled-in as well?

Nice guess. I had ECB enabled as a module, and I don't think it was
present in the initramfs. Compiling it in the kernel solves the problem.
Thanks for the clue!

I now have the xts(ecb(aes-generic)) driver appearing in /proc/crypto.
I had no xts driver before.

I don't think it's necessary now to copy my kernel config. Also, it's
quite minimalist: make defconfig with a few drivers I need, mostly compiled
in the kernel.

> (See commit description, shouldn't XTS now select ECB as well? This seems to 
> me
> like a bug...)

I was actually confused by the message, I thought it would fallback to
the old implementation. I guess the XTS module should select ECB if
that's not the case. Should I submit a patch for that? Or maybe it would
be easier if a maintainer directly makes the change?

> What mail on dmcrypt list? I do not see any recent mail.

It was a mail from 2012, I should be more careful with search engines...

-- 
Nicolas Porcel


Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-22 Thread Marcelo Cerri
Hi Hebert,

On Wed, Feb 22, 2017 at 04:18:19PM -0300, Marcelo Cerri wrote:
> Hi Paulo.
> 
> On Wed, Feb 22, 2017 at 03:00:15PM -0300, Paulo Flabiano Smorigo wrote:
> >  
> > if (in_interrupt()) {
> > -   ret = crypto_blkcipher_encrypt(_desc, dst, src,
> > -  nbytes);
> > +   SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> > +   skcipher_request_set_tfm(req, ctx->fallback);
> > +   skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> > +   skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> > +   ret = crypto_skcipher_encrypt(req);
> > +   skcipher_request_zero(req);
> 
> Probably you have to wait for the completion here before proceeding.
> 
> Check Documentation/crypto/api-samples.rst
> 

I noticed you used a similar approach in arch/s390/crypto/aes_s390.c
(commit 64e2680).

How do you ensure the skcipher operation will not be asynchronous? 

-- 
Regards,
Marcelo



signature.asc
Description: PGP signature


[PATCH 0/2] crypto: vmx - fix vmx failures by changing fallback to skcipher

2017-02-22 Thread Paulo Flabiano Smorigo
Currently, neither cbc or xts are working with upstream kernel due to a failure
in the fallback allocation. This can be fixed by changing the fallback to
skcipher.

Paulo Flabiano Smorigo (2):
  crypto: vmx - Use skcipher for cbc fallback
  crypto: vmx - Use skcipher for xts fallback

 drivers/crypto/vmx/aes_cbc.c | 41 -
 drivers/crypto/vmx/aes_xts.c | 32 ++--
 2 files changed, 38 insertions(+), 35 deletions(-)

-- 
2.9.3



[PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi

2017-02-22 Thread Steve Lin
Adds crypto hardware (SPU) to Northstar Plus device tree file.

Signed-off-by: Steve Lin 

---
Code changes for this addition were submitted previously by Rob
Rice: 
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=9d12ba86f818aa9cfe9f01b750336aa441f2ffa2
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index b6142bd..9bac0c8 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,12 @@
brcm,nand-has-wp;
};
 
+   crypto@2f000 {
+   compatible = "brcm,spum-nsp-crypto";
+   reg = <0x2f000 0x900>;
+   mboxes = < 0>;
+   };
+
gpiob: gpio@3 {
compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
reg = <0x3 0x50>;
-- 
2.1.0



Re: [PATCH 2/2] crypto: vmx - Use skcipher for xts fallback

2017-02-22 Thread Marcelo Cerri
In addition to cbc comments:

On Wed, Feb 22, 2017 at 03:00:45PM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo 
> ---
>  drivers/crypto/vmx/aes_xts.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
> index 24353ec3..a8245e1 100644
> --- a/drivers/crypto/vmx/aes_xts.c
> +++ b/drivers/crypto/vmx/aes_xts.c
> @@ -28,11 +28,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "aesp8-ppc.h"
>  
>  struct p8_aes_xts_ctx {
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
>   struct aes_key enc_key;
>   struct aes_key dec_key;
>   struct aes_key tweak_key;
> @@ -41,7 +42,7 @@ struct p8_aes_xts_ctx {
>  static int p8_aes_xts_init(struct crypto_tfm *tfm)
>  {
>   const char *alg;
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
>   struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
>  
>   if (!(alg = crypto_tfm_alg_name(tfm))) {
> @@ -50,7 +51,7 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
>   }
>  
>   fallback =
> - crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> + crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
>   if (IS_ERR(fallback)) {
>   printk(KERN_ERR
>   "Failed to allocate transformation for '%s': %ld\n",
> @@ -60,9 +61,9 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
>   printk(KERN_INFO "Using '%s' as fallback implementation.\n",
>   crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
>  
> - crypto_blkcipher_set_flags(
> + crypto_skcipher_set_flags(
>   fallback,
> - crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
> + crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
>   ctx->fallback = fallback;
>  
>   return 0;
> @@ -73,7 +74,7 @@ static void p8_aes_xts_exit(struct crypto_tfm *tfm)
>   struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
>  
>   if (ctx->fallback) {
> - crypto_free_blkcipher(ctx->fallback);
> + crypto_free_skcipher(ctx->fallback);
>   ctx->fallback = NULL;
>   }
>  }
> @@ -98,7 +99,7 @@ static int p8_aes_xts_setkey(struct crypto_tfm *tfm, const 
> u8 *key,
>   pagefault_enable();
>   preempt_enable();
>  
> - ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
> + ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
>   return ret;
>  }
>  
> @@ -113,15 +114,18 @@ static int p8_aes_xts_crypt(struct blkcipher_desc *desc,
>   struct blkcipher_walk walk;
>   struct p8_aes_xts_ctx *ctx =
>   crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>  
>   if (in_interrupt()) {
> - ret = enc ? crypto_blkcipher_encrypt(_desc, dst, src, 
> nbytes) :
> -crypto_blkcipher_decrypt(_desc, dst, 
> src, nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_encrypt(req);

You probably don't want this crypto_skcipher_encrypt call.


> + if (enc)
> + crypto_skcipher_encrypt(req);
> + else
> + crypto_skcipher_decrypt(req);

And you should check the return values here.

> + skcipher_request_zero(req);
>   } else {
>   preempt_disable();
>   pagefault_disable();
> -- 
> 2.9.3
> 

-- 
Regards,
Marcelo



signature.asc
Description: PGP signature


Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-22 Thread Marcelo Cerri
Hi Paulo.

On Wed, Feb 22, 2017 at 03:00:15PM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo 
> ---
>  drivers/crypto/vmx/aes_cbc.c | 41 -
>  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
> index 94ad5c0..5aa70997 100644
> --- a/drivers/crypto/vmx/aes_cbc.c
> +++ b/drivers/crypto/vmx/aes_cbc.c
> @@ -27,11 +27,12 @@
>  #include 
>  #include 
>  #include 
> +#include 

Isn't crypto/skcipher.h enough?

>  
>  #include "aesp8-ppc.h"
>  
>  struct p8_aes_cbc_ctx {
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
>   struct aes_key enc_key;
>   struct aes_key dec_key;
>  };
> @@ -39,7 +40,7 @@ struct p8_aes_cbc_ctx {
>  static int p8_aes_cbc_init(struct crypto_tfm *tfm)
>  {
>   const char *alg;
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
>   struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
>  
>   if (!(alg = crypto_tfm_alg_name(tfm))) {
> @@ -48,7 +49,7 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
>   }
>  
>   fallback =
> - crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> + crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
>   if (IS_ERR(fallback)) {
>   printk(KERN_ERR
>  "Failed to allocate transformation for '%s': %ld\n",
> @@ -58,9 +59,9 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
>   printk(KERN_INFO "Using '%s' as fallback implementation.\n",
>  crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
>  
> - crypto_blkcipher_set_flags(
> + crypto_skcipher_set_flags(
>   fallback,
> - crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
> + crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
>   ctx->fallback = fallback;
>  
>   return 0;
> @@ -71,7 +72,7 @@ static void p8_aes_cbc_exit(struct crypto_tfm *tfm)
>   struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
>  
>   if (ctx->fallback) {
> - crypto_free_blkcipher(ctx->fallback);
> + crypto_free_skcipher(ctx->fallback);
>   ctx->fallback = NULL;
>   }
>  }
> @@ -91,7 +92,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const 
> u8 *key,
>   pagefault_enable();
>   preempt_enable();
>  
> - ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
> + ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
>   return ret;
>  }
>  
> @@ -103,15 +104,14 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc 
> *desc,
>   struct blkcipher_walk walk;
>   struct p8_aes_cbc_ctx *ctx =
>   crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>  
>   if (in_interrupt()) {
> - ret = crypto_blkcipher_encrypt(_desc, dst, src,
> -nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_encrypt(req);
> + skcipher_request_zero(req);

Probably you have to wait for the completion here before proceeding.

Check Documentation/crypto/api-samples.rst


>   } else {
>   preempt_disable();
>   pagefault_disable();
> @@ -144,15 +144,14 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc 
> *desc,
>   struct blkcipher_walk walk;
>   struct p8_aes_cbc_ctx *ctx =
>   crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>  
>   if (in_interrupt()) {
> - ret = crypto_blkcipher_decrypt(_desc, dst, src,
> -nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_decrypt(req);
> + skcipher_request_zero(req);

Same here.


>   } else {
>   preempt_disable();
>   pagefault_disable();
> -- 
> 2.9.3
> 

-- 
Regards,
Marcelo



signature.asc
Description: PGP signature


[PATCH 2/2] crypto: vmx - Use skcipher for xts fallback

2017-02-22 Thread Paulo Flabiano Smorigo
Signed-off-by: Paulo Flabiano Smorigo 
---
 drivers/crypto/vmx/aes_xts.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
index 24353ec3..a8245e1 100644
--- a/drivers/crypto/vmx/aes_xts.c
+++ b/drivers/crypto/vmx/aes_xts.c
@@ -28,11 +28,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "aesp8-ppc.h"
 
 struct p8_aes_xts_ctx {
-   struct crypto_blkcipher *fallback;
+   struct crypto_skcipher *fallback;
struct aes_key enc_key;
struct aes_key dec_key;
struct aes_key tweak_key;
@@ -41,7 +42,7 @@ struct p8_aes_xts_ctx {
 static int p8_aes_xts_init(struct crypto_tfm *tfm)
 {
const char *alg;
-   struct crypto_blkcipher *fallback;
+   struct crypto_skcipher *fallback;
struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
 
if (!(alg = crypto_tfm_alg_name(tfm))) {
@@ -50,7 +51,7 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
}
 
fallback =
-   crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
+   crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
"Failed to allocate transformation for '%s': %ld\n",
@@ -60,9 +61,9 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
printk(KERN_INFO "Using '%s' as fallback implementation.\n",
crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
 
-   crypto_blkcipher_set_flags(
+   crypto_skcipher_set_flags(
fallback,
-   crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
+   crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
ctx->fallback = fallback;
 
return 0;
@@ -73,7 +74,7 @@ static void p8_aes_xts_exit(struct crypto_tfm *tfm)
struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
 
if (ctx->fallback) {
-   crypto_free_blkcipher(ctx->fallback);
+   crypto_free_skcipher(ctx->fallback);
ctx->fallback = NULL;
}
 }
@@ -98,7 +99,7 @@ static int p8_aes_xts_setkey(struct crypto_tfm *tfm, const u8 
*key,
pagefault_enable();
preempt_enable();
 
-   ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
+   ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
return ret;
 }
 
@@ -113,15 +114,18 @@ static int p8_aes_xts_crypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_xts_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
-   struct blkcipher_desc fallback_desc = {
-   .tfm = ctx->fallback,
-   .info = desc->info,
-   .flags = desc->flags
-   };
 
if (in_interrupt()) {
-   ret = enc ? crypto_blkcipher_encrypt(_desc, dst, src, 
nbytes) :
-crypto_blkcipher_decrypt(_desc, dst, src, 
nbytes);
+   SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+   skcipher_request_set_tfm(req, ctx->fallback);
+   skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+   skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+   ret = crypto_skcipher_encrypt(req);
+   if (enc)
+   crypto_skcipher_encrypt(req);
+   else
+   crypto_skcipher_decrypt(req);
+   skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
-- 
2.9.3



[PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback

2017-02-22 Thread Paulo Flabiano Smorigo
Signed-off-by: Paulo Flabiano Smorigo 
---
 drivers/crypto/vmx/aes_cbc.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
index 94ad5c0..5aa70997 100644
--- a/drivers/crypto/vmx/aes_cbc.c
+++ b/drivers/crypto/vmx/aes_cbc.c
@@ -27,11 +27,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "aesp8-ppc.h"
 
 struct p8_aes_cbc_ctx {
-   struct crypto_blkcipher *fallback;
+   struct crypto_skcipher *fallback;
struct aes_key enc_key;
struct aes_key dec_key;
 };
@@ -39,7 +40,7 @@ struct p8_aes_cbc_ctx {
 static int p8_aes_cbc_init(struct crypto_tfm *tfm)
 {
const char *alg;
-   struct crypto_blkcipher *fallback;
+   struct crypto_skcipher *fallback;
struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
 
if (!(alg = crypto_tfm_alg_name(tfm))) {
@@ -48,7 +49,7 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
}
 
fallback =
-   crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
+   crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
   "Failed to allocate transformation for '%s': %ld\n",
@@ -58,9 +59,9 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
printk(KERN_INFO "Using '%s' as fallback implementation.\n",
   crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
 
-   crypto_blkcipher_set_flags(
+   crypto_skcipher_set_flags(
fallback,
-   crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
+   crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
ctx->fallback = fallback;
 
return 0;
@@ -71,7 +72,7 @@ static void p8_aes_cbc_exit(struct crypto_tfm *tfm)
struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
 
if (ctx->fallback) {
-   crypto_free_blkcipher(ctx->fallback);
+   crypto_free_skcipher(ctx->fallback);
ctx->fallback = NULL;
}
 }
@@ -91,7 +92,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const u8 
*key,
pagefault_enable();
preempt_enable();
 
-   ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
+   ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
return ret;
 }
 
@@ -103,15 +104,14 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_cbc_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
-   struct blkcipher_desc fallback_desc = {
-   .tfm = ctx->fallback,
-   .info = desc->info,
-   .flags = desc->flags
-   };
 
if (in_interrupt()) {
-   ret = crypto_blkcipher_encrypt(_desc, dst, src,
-  nbytes);
+   SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+   skcipher_request_set_tfm(req, ctx->fallback);
+   skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+   skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+   ret = crypto_skcipher_encrypt(req);
+   skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
@@ -144,15 +144,14 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_cbc_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
-   struct blkcipher_desc fallback_desc = {
-   .tfm = ctx->fallback,
-   .info = desc->info,
-   .flags = desc->flags
-   };
 
if (in_interrupt()) {
-   ret = crypto_blkcipher_decrypt(_desc, dst, src,
-  nbytes);
+   SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+   skcipher_request_set_tfm(req, ctx->fallback);
+   skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+   skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+   ret = crypto_skcipher_decrypt(req);
+   skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
-- 
2.9.3



Re: crypto: xts: regression in 4.10

2017-02-22 Thread Marcelo Cerri
What XTS implementations do you have available on /proc/crypto after the
error?

Some drivers that allocate fallback implementations using the older API
started to fail after the generic templates were converted to skcipher.


On Wed, Feb 22, 2017 at 12:17:17AM +0100, Nicolas Porcel wrote:
> Hello,
> 
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
> 
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on  failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for 
> more info)
> 
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
> 
> > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> > Author: Herbert Xu 
> > Date:   Tue Nov 22 20:08:19 2016 +0800
> > 
> > crypto: xts - Convert to skcipher
> 
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.
> 
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.
> 
> Thank you in advance,
> 
> Best regards,
> 
> -- 
> Nicolas Porcel

-- 
Regards,
Marcelo



signature.asc
Description: PGP signature


Re: crypto/cavium MSI-X fixups

2017-02-22 Thread David Daney

On 02/21/2017 11:27 PM, Christoph Hellwig wrote:

On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:

With respect to pci_enable_msix(), what do you recommend as a replacement?


pci_alloc_irq_vectors.  In fact I have a tree ready for after -rc1
that removes pci_enable_msix() entirely.


I would like to see something that handles the case of this driver that 
I am attempting to get merged:



https://lkml.org/lkml/2017/2/15/1209





For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which
works well if the required MSI-X indexes are contiguous starting at zero.
What would be used for a device that has 184 MSI-X, but only a sparse
subset (fewer than half) of these are required for the driver operation.
It would waste system resources to use an API that forces us to allocate
184 when only 80 are required.


Currently we don't have a good API for that.  I've not been through all
users of pci_enable_msix_{range,exact} yet, but so far I've only found
one user not using all vectors from 0 to some limit.  Depending how many
such users we have and how they'll look I will have to look into an API
to support that use case.



See the patch above for the case that doesn't use 0..UPPER_LIMIT

David Daney


Re: crypto: xts: regression in 4.10

2017-02-22 Thread Milan Broz
On 02/22/2017 12:17 AM, Nicolas Porcel wrote:
> Hello,
> 
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
> 
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on  failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for 
> more info)
> 
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
> 
>> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
>> Author: Herbert Xu 
>> Date:   Tue Nov 22 20:08:19 2016 +0800
>>
>> crypto: xts - Convert to skcipher
> 
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.

Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much 
earlier:-)

I guess either there is a bug in some specific dependency missing
dependency in kernel config. Could you send your kernel .config that fails?

Do you have ECB mode compiled-in as well?

(See commit description, shouldn't XTS now select ECB as well? This seems to me
like a bug...)
 
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.

What mail on dmcrypt list? I do not see any recent mail.

Milan