[PATCH] crypto: Add ECB dependency for XTS mode
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"
From: Colin Ian Kingtrivial 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
On Wed, Feb 22, 2017 at 4:22 PM, Steve Linwrote: > 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
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
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
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
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
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
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
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
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
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
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
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