[PATCH][crypto-next] crypto: omap-aes: fix spelling mistake "Encryptio" -> "Encryption"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in pr_err message

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

diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 521a310ea699..7d4f8a4be6d8 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -214,7 +214,7 @@ static int do_encrypt_iv(struct aead_request *req, u32 
*tag, u32 *iv)
}
/* fall through */
default:
-   pr_err("Encryptio of IV failed for GCM mode");
+   pr_err("Encryption of IV failed for GCM mode");
break;
}
 
-- 
2.11.0

Re: [PATCH v2 0/6] Appended signatures support for IMA appraisal

[Michael Ellerman]

Thiago Jung Bauermann  writes:

> Michael Ellerman  writes:
>
>> Thiago Jung Bauermann  writes:
>>
>>> On the OpenPOWER platform, secure boot and trusted boot are being
>>> implemented using IMA for taking measurements and verifying signatures.
>>
>> I still want you to implement arch_kexec_kernel_verify_sig() as well :)
>
> Yes, I will implement it! We are still working on loading the public
> keys for kernel signing from the firmware into a kernel keyring, so
> there's not much point in implementing arch_kexec_kernel_verify_sig
> without having that first.

OK. What's the ETA on those patches?

cheers

Re: [RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

[David Gstir]

Friendly ping. Any feedback on that?

Thanks,
David

> On 2 Jun 2017, at 14:24, David Gstir  wrote:
> 
> Hi!
> 
> While testing fscrypt's filename encryption, I noticed that the implementation
> of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled.
> Some digging showed that the refactoring of crypto/cts.c in v4.8 
> (commit 0605c41cc53ca) exposed some problems with CAAM's aes-cbc
> implementation. This can be tested quite easily by loading the tcrypt
> module with mode=38. Looks like the cts mode is not used very often
> and this went unnoticed since 4.8...
> 
> This patch series is an attempt to fix that and get cts(cbc(aes)) working
> properly again when the CAAM driver is enabled.
> 
> Specifically, the issues are:
> 
> 1) The cts implementation assumes ->info of ablkcipher_request (or ->iv of
>   skcipher_request respectively) to be set to the last ciphertext block when
>   the aes-cbc encryption is finished. Meaning that ->info is changed by the
>   aes-cbc code. The CAAM driver does not do that and leaves ->info as-is.
> 
>   It is not fully clear to me yet if this is a requirement of the crypto API,
>   or if this is just a side effect that is exploited by the cts 
> implementation?
> 
>   For now, I assumed it is a requirement of the crypto API since I've seen
>   other crypto drivers (e.g. AMD's CCP) do that. So the patch fixes the CAAM
>   crypto driver accordingly.
> 
>   Also, the aead code in the CAAM driver, more specifically the gcm mode code
>   seems to have the same flaw, so it'll need a similar fix in case.
> 
> 
> 2) The cts implementation uses aes-cbc twice to perform its job. The second
>   time, it is called from within the callback of the first call to aes-cbc.
>   This usage is not properly handled in the CAAM driver which triggers the
>   BUG below.
> 
>   My current proposal is to use in_interrupt() to detect such cases and set
>   the k*alloc flags accordingly. However, since using in_interrupt() is not
>   really nice, I'm wondering if there is a better way to handle this?
> 
> 
> Thanks,
> David
> 
> 
> [  126.252543] BUG: sleeping function called from invalid context at 
> mm/slab.h:432
> [  126.260099] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
> [  126.266837] no locks held by swapper/0/0.
> [  126.270969] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 4.12.0-rc3-00052-g0ddec680d395 #287
> [  126.279226] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  126.285821] Backtrace:
> [  126.288406] [] (dump_backtrace) from [] 
> (show_stack+0x18/0x1c)
> [  126.296057]  r7: r6:6113 r5: r4:c102ab48
> [  126.301798] [] (show_stack) from [] 
> (dump_stack+0xb4/0xe8)
> [  126.309106] [] (dump_stack) from [] 
> (___might_sleep+0x17c/0x2a0)
> [  126.316929]  r9: r8:c0a016dc r7:c101ee3e r6:01b0 r5:c0c12fac 
> r4:e000
> [  126.324751] [] (___might_sleep) from [] 
> (__might_sleep+0x64/0xa4)
> [  126.332655]  r7:014080c1 r6: r5:01b0 r4:c0c12fac
> [  126.338397] [] (__might_sleep) from [] 
> (__kmalloc+0x130/0x1b8)
> [  126.346039]  r6:c071a8ec r5:014080c1 r4:eec01e00
> [  126.350742] [] (__kmalloc) from [] 
> (ablkcipher_edesc_alloc.constprop.1+0x200/0x900)
> [  126.360213]  r10: r9: r8:c0a016dc r7:c0a016dc r6:ee05ac10 
> r5:edfdaec0
> [  126.368109]  r4:0001 r3:0020
> [  126.371765] [] (ablkcipher_edesc_alloc.constprop.1) from 
> [] (ablkcipher_encrypt+0x24/0x9c)
> [  126.381843]  r10: r9:0020 r8:0001 r7:ee05ac10 r6:ed597000 
> r5:edfdaec0
> [  126.389738]  r4:ed475d08
> [  126.392354] [] (ablkcipher_encrypt) from [] 
> (skcipher_encrypt_ablkcipher+0x68/0x6c)
> [  126.401822]  r7:ed475d08 r6:ed597000 r5:0400 r4:ed475d08
> [  126.407566] [] (skcipher_encrypt_ablkcipher) from [] 
> (cts_cbc_encrypt+0x118/0x124)
> [  126.416947]  r7:ed475d08 r6:c1001cc0 r5:0010 r4:edfdae00
> [  126.422686] [] (cts_cbc_encrypt) from [] 
> (crypto_cts_encrypt_done+0x20/0x54)
> [  126.431548]  r10: r9:ee05ac10 r8: r7:0010 r6:edc8e6c0 
> r5:edc8e6d8
> [  126.439443]  r4:edfdae00
> [  126.442056] [] (crypto_cts_encrypt_done) from [] 
> (ablkcipher_encrypt_done+0x88/0x9c)
> [  126.445180] fec 2188000.ethernet eth0: MDIO read timeout
> [  126.456948]  r5:edc8e6d8 r4:edfdaec0
> [  126.460604] [] (ablkcipher_encrypt_done) from [] 
> (caam_jr_dequeue+0x214/0x2d4)
> [  126.469639]  r9:0001 r8:ee088010 r7:01ff r6:0001 r5: 
> r4:edfdaec0
> [  126.477467] [] (caam_jr_dequeue) from [] 
> (tasklet_action+0x98/0x154)
> [  126.485160] fec 2188000.ethernet eth0: MDIO read timeout
> [  126.490975]  r10:c1080b80 r9:c1008b84 r8: r7:c100 r6: 
> r5:ee088028
> [  126.498870]  r4:ee088024
> [  126.501484] [] (tasklet_action) from [] 
> (__do_softirq+0xf0/0x2a4)
> [  126.509390]  r10:4006 r9:c1002080 r8:0101 r7:c1002098 r6:c100 
> r5:0006
> [  126.517285]  r4:
> [  126.519896] [] 

Re: [PATCH v6 3/5] arm64: marvell: dts: add dma-mask in crypto nodes for 7k/8k

[Gregory CLEMENT]

Hi Antoine,
 
 On mer., mai 24 2017, Antoine Tenart  wrote:

> The EIP197 cryptographic engine supports 64 bits address width but is
> limited to 40 bits on 7k/8k. Add a dma-mask property in the
> cryptographic engine nodes to reflect this.
>
> Signed-off-by: Antoine Tenart 

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 1 +
>  arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi  | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index b4bc42ece754..434d8a806ffa 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -240,6 +240,7 @@
>   interrupt-names = "mem", "ring0", "ring1",
>   "ring2", "ring3", "eip";
>   clocks = <_syscon0 1 26>;
> + dma-mask = <0xff 0x>;
>   status = "disabled";
>   };
>   };
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 6e2058847ddc..17ca94a5d6b4 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -230,6 +230,7 @@
>   interrupt-names = "mem", "ring0", "ring1",
> "ring2", "ring3", "eip";
>   clocks = <_syscon0 1 26>;
> + dma-mask = <0xff 0x>;
>   status = "disabled";
>   };
>   };
> -- 
> 2.9.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH][crypto-next] crypto: cavium: fix spelling mistake "Revsion" -> "Revision"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in seq_printf message

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

diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c 
b/drivers/crypto/cavium/nitrox/nitrox_main.c
index eee6fb501580..ae44a464cd2d 100644
--- a/drivers/crypto/cavium/nitrox/nitrox_main.c
+++ b/drivers/crypto/cavium/nitrox/nitrox_main.c
@@ -399,7 +399,7 @@ static int nitrox_show(struct seq_file *s, void *v)
struct nitrox_device *ndev = s->private;
 
seq_printf(s, "NITROX-5 [idx: %d]\n", ndev->idx);
-   seq_printf(s, "  Revsion ID: 0x%0x\n", ndev->hw.revision_id);
+   seq_printf(s, "  Revision ID: 0x%0x\n", ndev->hw.revision_id);
seq_printf(s, "  Cores [AE: %u  SE: %u]\n",
   ndev->hw.ae_cores, ndev->hw.se_cores);
seq_printf(s, "  Number of Queues: %u\n", ndev->nr_queues);
-- 
2.11.0

Re: [PATCH][crypto-next] crypto: cavium: fix spelling mistake "Revsion" -> "Revision"

[Colin Ian King]

On 13/06/17 11:36, Joe Perches wrote:
> On Tue, 2017-06-13 at 09:52 +0100, Colin King wrote:
>> From: Colin Ian King 
>>
>> Trivial fix to spelling mistake in seq_printf message
> 
> Hey Colin.
> 
> Fixing spelling typos is a good thing, but is it a
> good thing to change possibly API dependent output
> in seq_ calls?

Considering it's in -next and has not landed in upstream I supposed it
was better to fix it now before it landed in Linus' repo.

Colin

> 
>> diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c 
>> b/drivers/crypto/cavium/nitrox/nitrox_main.c
> []
>> @@ -399,7 +399,7 @@ static int nitrox_show(struct seq_file *s, void *v)
>>  struct nitrox_device *ndev = s->private;
>>  
>>  seq_printf(s, "NITROX-5 [idx: %d]\n", ndev->idx);
>> -seq_printf(s, "  Revsion ID: 0x%0x\n", ndev->hw.revision_id);
>> +seq_printf(s, "  Revision ID: 0x%0x\n", ndev->hw.revision_id);
>>  seq_printf(s, "  Cores [AE: %u  SE: %u]\n",
>> ndev->hw.ae_cores, ndev->hw.se_cores);
>>  seq_printf(s, "  Number of Queues: %u\n", ndev->nr_queues);
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH][crypto-next] crypto: cavium: fix spelling mistake "Revsion" -> "Revision"

[Joe Perches]

On Tue, 2017-06-13 at 11:40 +0100, Colin Ian King wrote:
> On 13/06/17 11:36, Joe Perches wrote:
> > On Tue, 2017-06-13 at 09:52 +0100, Colin King wrote:
> > > From: Colin Ian King 
> > > 
> > > Trivial fix to spelling mistake in seq_printf message
> > Fixing spelling typos is a good thing, but is it a
> > good thing to change possibly API dependent output
> > in seq_ calls?
> Considering it's in -next and has not landed in upstream I supposed it
> was better to fix it now before it landed in Linus' repo.

Good call, thanks.

> > > diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c 
> > > b/drivers/crypto/cavium/nitrox/nitrox_main.c
> > 
> > []
> > > @@ -399,7 +399,7 @@ static int nitrox_show(struct seq_file *s, void *v)
> > >   struct nitrox_device *ndev = s->private;
> > >  
> > >   seq_printf(s, "NITROX-5 [idx: %d]\n", ndev->idx);
> > > - seq_printf(s, "  Revsion ID: 0x%0x\n", ndev->hw.revision_id);
> > > + seq_printf(s, "  Revision ID: 0x%0x\n", ndev->hw.revision_id);
> > >   seq_printf(s, "  Cores [AE: %u  SE: %u]\n",
> > >  ndev->hw.ae_cores, ndev->hw.se_cores);
> > >   seq_printf(s, "  Number of Queues: %u\n", ndev->nr_queues);

Re: [PATCH v2 1/3] dt-bindings: rng: add MediaTek MT7622 Hardware Random Generator bindings

[Matthias Brugger]

On 12/06/17 17:56, sean.w...@mediatek.com wrote:

From: Sean Wang 

Document the bindings used by MediaTek MT7622 SoC hardware random number
generator.

Signed-off-by: Sean Wang 
---
  Documentation/devicetree/bindings/rng/mtk-rng.txt | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)



Reviewed-by: Matthias Brugger 


diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt 
b/Documentation/devicetree/bindings/rng/mtk-rng.txt
index a6d62a2..366b99b 100644
--- a/Documentation/devicetree/bindings/rng/mtk-rng.txt
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -2,7 +2,9 @@ Device-Tree bindings for Mediatek random number generator
  found in Mediatek SoC family
  
  Required properties:

-- compatible   : Should be "mediatek,mt7623-rng"
+- compatible   : Should be
+   "mediatek,mt7622-rng","mediatek,mt7623-rng" : 
for MT7622
+   "mediatek,mt7623-rng" : for MT7623
  - clocks  : list of clock specifiers, corresponding to
  entries in clock-names property;
  - clock-names : Should contain "rng" entries;

Re: [PATCH][crypto-next] crypto: cavium: fix spelling mistake "Revsion" -> "Revision"

[Joe Perches]

On Tue, 2017-06-13 at 09:52 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in seq_printf message

Hey Colin.

Fixing spelling typos is a good thing, but is it a
good thing to change possibly API dependent output
in seq_ calls?

> diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c 
> b/drivers/crypto/cavium/nitrox/nitrox_main.c
[]
> @@ -399,7 +399,7 @@ static int nitrox_show(struct seq_file *s, void *v)
>   struct nitrox_device *ndev = s->private;
>  
>   seq_printf(s, "NITROX-5 [idx: %d]\n", ndev->idx);
> - seq_printf(s, "  Revsion ID: 0x%0x\n", ndev->hw.revision_id);
> + seq_printf(s, "  Revision ID: 0x%0x\n", ndev->hw.revision_id);
>   seq_printf(s, "  Cores [AE: %u  SE: %u]\n",
>  ndev->hw.ae_cores, ndev->hw.se_cores);
>   seq_printf(s, "  Number of Queues: %u\n", ndev->nr_queues);

Re: [cryptodev:master 62/75] crypto/rsa-pkcs1pad.c:680:21: error: assignment from incompatible pointer type

[Tudor Ambarus]

Hi, Herbert,

Sorry, I thought that is better to make a patch for each driver.

Bisectibility is affected because I changed the declaration of max_size
function to return an unsigned int instead of an int, but I updated
each driver that uses this function in a different patch.

Bisectibility will be ok if we squash the patch that modifies the
declaration with the ones that use it. This also applies for kpp.

How should I proceed from here?

Thanks,
ta

On 13.06.2017 04:34, kbuild test robot wrote:

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head:   48df28b85991ac67a2270f0bb818221527834b78
commit: 561f8e2df990a7a2859a98bd208d0f7dc932c3f7 [62/75] crypto: akcipher - 
assume key is already set in maxsize
config: x86_64-randconfig-x019-201724 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
 git checkout 561f8e2df990a7a2859a98bd208d0f7dc932c3f7
 # save the attached .config to linux build tree
 make ARCH=x86_64

Note: the cryptodev/master HEAD 48df28b85991ac67a2270f0bb818221527834b78 builds 
fine.
   It only hurts bisectibility.

All errors (new ones prefixed by >>):

crypto/rsa-pkcs1pad.c: In function 'pkcs1pad_create':

crypto/rsa-pkcs1pad.c:680:21: error: assignment from incompatible pointer type 
[-Werror=incompatible-pointer-types]

  inst->alg.max_size = pkcs1pad_get_max_size;
 ^
cc1: some warnings being treated as errors

vim +680 crypto/rsa-pkcs1pad.c

a49de377 Tadeusz Struk  2016-03-03  664 CRYPTO_MAX_ALG_NAME)
c0d20d22 Herbert Xu 2016-06-29  665 goto out_drop_alg;
3d5b1ecd Andrzej Zaborowski 2015-12-05  666
3d5b1ecd Andrzej Zaborowski 2015-12-05  667 inst->alg.base.cra_flags = 
rsa_alg->base.cra_flags & CRYPTO_ALG_ASYNC;
3d5b1ecd Andrzej Zaborowski 2015-12-05  668 inst->alg.base.cra_priority = 
rsa_alg->base.cra_priority;
3d5b1ecd Andrzej Zaborowski 2015-12-05  669 inst->alg.base.cra_ctxsize = 
sizeof(struct pkcs1pad_ctx);
3d5b1ecd Andrzej Zaborowski 2015-12-05  670
3d5b1ecd Andrzej Zaborowski 2015-12-05  671 inst->alg.init = 
pkcs1pad_init_tfm;
3d5b1ecd Andrzej Zaborowski 2015-12-05  672 inst->alg.exit = 
pkcs1pad_exit_tfm;
3d5b1ecd Andrzej Zaborowski 2015-12-05  673
3d5b1ecd Andrzej Zaborowski 2015-12-05  674 inst->alg.encrypt = 
pkcs1pad_encrypt;
3d5b1ecd Andrzej Zaborowski 2015-12-05  675 inst->alg.decrypt = 
pkcs1pad_decrypt;
3d5b1ecd Andrzej Zaborowski 2015-12-05  676 inst->alg.sign = pkcs1pad_sign;
3d5b1ecd Andrzej Zaborowski 2015-12-05  677 inst->alg.verify = 
pkcs1pad_verify;
3d5b1ecd Andrzej Zaborowski 2015-12-05  678 inst->alg.set_pub_key = 
pkcs1pad_set_pub_key;
3d5b1ecd Andrzej Zaborowski 2015-12-05  679 inst->alg.set_priv_key = 
pkcs1pad_set_priv_key;
3d5b1ecd Andrzej Zaborowski 2015-12-05 @680 inst->alg.max_size = 
pkcs1pad_get_max_size;
3d5b1ecd Andrzej Zaborowski 2015-12-05  681 inst->alg.reqsize = sizeof(struct 
pkcs1pad_request) + rsa_alg->reqsize;
3d5b1ecd Andrzej Zaborowski 2015-12-05  682
3d5b1ecd Andrzej Zaborowski 2015-12-05  683 inst->free = pkcs1pad_free;
3d5b1ecd Andrzej Zaborowski 2015-12-05  684
3d5b1ecd Andrzej Zaborowski 2015-12-05  685 err = 
akcipher_register_instance(tmpl, inst);
3d5b1ecd Andrzej Zaborowski 2015-12-05  686 if (err)
c0d20d22 Herbert Xu 2016-06-29  687 goto out_drop_alg;
3d5b1ecd Andrzej Zaborowski 2015-12-05  688

:: The code at line 680 was first introduced by commit
:: 3d5b1ecdea6fb94f8c61554fcb2ba776a2d3d0e6 crypto: rsa - RSA padding 
algorithm

:: TO: Andrzej Zaborowski 
:: CC: Herbert Xu 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: Alg errors with Intel QAT Card

[Neil Horman]

On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote:
> Hi Raj,
> 
> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue.
> Are you seeing any of this with a previous kernel version? If not, git bisect 
> might
> help us finding the root-cause.
> Have you tried with another platform/hw?
> 
> Regards,
> Salvatore
> 
Try a soft reboot and see if the error clears up.  This looks a bit reminscient
of some firmware errors we've been chasing down
Neil

> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> > ow...@vger.kernel.org] On Behalf Of Raj Ammanur
> > Sent: Friday, June 9, 2017 7:37 PM
> > To: Linux Crypto Mailing List 
> > Subject: Alg errors with Intel QAT Card
> > 
> > Hi
> > 
> > I am seeing the below errors after  installing an Intel QAT card
> > and loading the upstreamed qat_dh895xcc and intel_qat modules.
> > 
> > Have others seen similar errors and know if this is a known issue
> > and a fix exists or know whats going on ? This is with 4.12.0-rc4+
> > version of the kernel.
> > 
> > Any help is sincerely appreciated.
> > 
> > thanks
> > --Raj
> > 
> > 
> > [3.639046] dh895xcc :00:0b.0: qat_dev0 started 12 acceleration 
> > engines
> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
> > encryption for qat_aes_cbc
> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
> > at page 0 for qat_aes_ctr
> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on
> > encryption for qat_aes_xts
> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
> > [root@dhcp-swlab-681 ~]# dmesg | grep -i alg
> > [1.499336] alg: No test for pkcs1pad(rsa,sha256)
> > (pkcs1pad(rsa-generic,sha256))
> > [2.562511] SELinux:  Class alg_socket not defined in policy.
> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
> > encryption for qat_aes_cbc
> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
> > at page 0 for qat_aes_ctr
> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on
> > encryption for qat_aes_xts
> > [4.367682] alg: akcipher: encrypt test failed. Invalid output
> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
> > [4.431827] alg: dh: generate public key test failed. Invalid output
> > [4.431829] alg: dh: test failed on vector 1, err=-22
> > 
> > 
> > 83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT
> > Subsystem: Intel Corporation Device 
> > Physical Slot: 2
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR+ FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > SERR-  > Latency: 0, Cache Line Size: 32 bytes
> > Interrupt: pin A routed to IRQ 35
> > NUMA node: 1
> > Region 0: Memory at fb90 (64-bit, prefetchable) [size=512K]
> > Region 2: Memory at fbd4 (64-bit, non-prefetchable) [size=256K]
> > Region 4: Memory at fbd0 (64-bit, non-prefetchable) [size=256K]
> > Capabilities: [b0] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Address:   Data: 
> > Masking:   Pending: 
> > Capabilities: [60] MSI-X: Enable+ Count=33 Masked-
> > Vector table: BAR=2 offset=0003b000
> > PBA: BAR=2 offset=0003b800
> > Capabilities: [6c] Power Management version 3
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-
> > ,D3cold-)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > Capabilities: [74] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <128ns, L1 <1us
> > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
> > DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
> > RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
> > MaxPayload 256 bytes, MaxReadReq 1024 bytes
> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
> > LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s, Exit Latency L0s
> > <512ns, L1 unlimited
> > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk- DLActive-
> > BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-, OBFF Not
> > Supported
> > AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF
> > Disabled
> > AtomicOpsCtl: ReqEn-
> > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> >  Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
> > ComplianceSOS-
> >  Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
> > EqualizationPhase1-
> >  EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> > Capabilities: [100 v1] Advanced Error Reporting
> > 

Re: Alg errors with Intel QAT Card

[Raj Ammanur]

Hi Neil & Salvatore,

thanks for the replies. The soft reboot hasn't helped. I am trying a previous
kernel version that works with a similar card that we installed in
another server
and that works fine. Will keep you posted.

Neil: have you found fix/workaround for the firmware errors or you just using
a soft reboot? by that, you just mean unload and load the kernel modules or
a system reboot. I have tried both.

thanks
--Raj

On Tue, Jun 13, 2017 at 5:30 AM, Neil Horman  wrote:
> On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote:
>> Hi Raj,
>>
>> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue.
>> Are you seeing any of this with a previous kernel version? If not, git 
>> bisect might
>> help us finding the root-cause.
>> Have you tried with another platform/hw?
>>
>> Regards,
>> Salvatore
>>
> Try a soft reboot and see if the error clears up.  This looks a bit 
> reminscient
> of some firmware errors we've been chasing down
> Neil
>
>> > -Original Message-
>> > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
>> > ow...@vger.kernel.org] On Behalf Of Raj Ammanur
>> > Sent: Friday, June 9, 2017 7:37 PM
>> > To: Linux Crypto Mailing List 
>> > Subject: Alg errors with Intel QAT Card
>> >
>> > Hi
>> >
>> > I am seeing the below errors after  installing an Intel QAT card
>> > and loading the upstreamed qat_dh895xcc and intel_qat modules.
>> >
>> > Have others seen similar errors and know if this is a known issue
>> > and a fix exists or know whats going on ? This is with 4.12.0-rc4+
>> > version of the kernel.
>> >
>> > Any help is sincerely appreciated.
>> >
>> > thanks
>> > --Raj
>> >
>> >
>> > [3.639046] dh895xcc :00:0b.0: qat_dev0 started 12 acceleration 
>> > engines
>> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
>> > encryption for qat_aes_cbc
>> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
>> > at page 0 for qat_aes_ctr
>> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on
>> > encryption for qat_aes_xts
>> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
>> > [root@dhcp-swlab-681 ~]# dmesg | grep -i alg
>> > [1.499336] alg: No test for pkcs1pad(rsa,sha256)
>> > (pkcs1pad(rsa-generic,sha256))
>> > [2.562511] SELinux:  Class alg_socket not defined in policy.
>> > [4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
>> > encryption for qat_aes_cbc
>> > [4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
>> > at page 0 for qat_aes_ctr
>> > [4.282042] alg: skcipher: Test 4 failed (invalid result) on
>> > encryption for qat_aes_xts
>> > [4.367682] alg: akcipher: encrypt test failed. Invalid output
>> > [4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
>> > [4.431827] alg: dh: generate public key test failed. Invalid output
>> > [4.431829] alg: dh: test failed on vector 1, err=-22
>> >
>> >
>> > 83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT
>> > Subsystem: Intel Corporation Device 
>> > Physical Slot: 2
>> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> > Stepping- SERR+ FastB2B- DisINTx+
>> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> > SERR- > > Latency: 0, Cache Line Size: 32 bytes
>> > Interrupt: pin A routed to IRQ 35
>> > NUMA node: 1
>> > Region 0: Memory at fb90 (64-bit, prefetchable) [size=512K]
>> > Region 2: Memory at fbd4 (64-bit, non-prefetchable) [size=256K]
>> > Region 4: Memory at fbd0 (64-bit, non-prefetchable) [size=256K]
>> > Capabilities: [b0] MSI: Enable- Count=1/1 Maskable+ 64bit+
>> > Address:   Data: 
>> > Masking:   Pending: 
>> > Capabilities: [60] MSI-X: Enable+ Count=33 Masked-
>> > Vector table: BAR=2 offset=0003b000
>> > PBA: BAR=2 offset=0003b800
>> > Capabilities: [6c] Power Management version 3
>> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-
>> > ,D3cold-)
>> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> > Capabilities: [74] Express (v2) Endpoint, MSI 00
>> > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <128ns, L1 <1us
>> > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
>> > DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
>> > RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
>> > MaxPayload 256 bytes, MaxReadReq 1024 bytes
>> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
>> > LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s, Exit Latency L0s
>> > <512ns, L1 unlimited
>> > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> > LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk- DLActive-
>> > BWMgmt- ABWMgmt-
>> > DevCap2: Completion Timeout: Range B, 

[PATCH] of: update ePAPR references to point to Devicetree Specification

[frowand . list]

From: Frank Rowand 

The Devicetree Specification has superseded the ePAPR as the
base specification for bindings.  Update files in Documentation
to reference the new document.

Some files are not updated because there is no hypervisor chapter
in the Devicetree Specification:
   Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
   Documenation/virtual/kvm/api.txt
   Documenation/virtual/kvm/ppc-pv.txt

Signed-off-by: Frank Rowand 
---
 Documentation/devicetree/bindings/arm/cci.txt   | 12 ++--
 Documentation/devicetree/bindings/arm/cpus.txt  | 13 +++--
 Documentation/devicetree/bindings/arm/idle-states.txt   |  4 ++--
 Documentation/devicetree/bindings/arm/l2c2x0.txt|  4 ++--
 Documentation/devicetree/bindings/arm/topology.txt  |  4 ++--
 Documentation/devicetree/bindings/bus/simple-pm-bus.txt |  2 +-
 Documentation/devicetree/bindings/chosen.txt|  3 ++-
 Documentation/devicetree/bindings/common-properties.txt |  2 +-
 Documentation/devicetree/bindings/crypto/fsl-sec4.txt   |  4 ++--
 Documentation/devicetree/bindings/crypto/fsl-sec6.txt   |  4 ++--
 .../devicetree/bindings/interrupt-controller/open-pic.txt   |  5 ++---
 Documentation/devicetree/bindings/net/ethernet.txt  |  9 ++---
 Documentation/devicetree/bindings/powerpc/fsl/cpus.txt  |  6 +++---
 Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt   |  2 +-
 Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt  |  4 ++--
 Documentation/devicetree/bindings/powerpc/fsl/srio.txt  |  3 ++-
 Documentation/devicetree/booting-without-of.txt |  2 +-
 Documentation/devicetree/usage-model.txt|  2 +-
 Documentation/xtensa/mmu.txt|  6 +++---
 19 files changed, 48 insertions(+), 43 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cci.txt 
b/Documentation/devicetree/bindings/arm/cci.txt
index 0f2153e8fa7e..cc7621b204f4 100644
--- a/Documentation/devicetree/bindings/arm/cci.txt
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -11,9 +11,9 @@ clusters, through memory mapped interface, with a global 
control register
 space and multiple sets of interface control registers, one per slave
 interface.
 
-Bindings for the CCI node follow the ePAPR standard, available from:
+Bindings for the CCI node follow the Devicetree Specification, available from:
 
-www.power.org/documentation/epapr-version-1-1/
+https://www.devicetree.org/specifications/
 
 with the addition of the bindings described in this document which are
 specific to ARM.
@@ -50,10 +50,10 @@ specific to ARM.
as a tuple of cells, containing child address,
parent address and the size of the region in the
child address space.
-   Definition: A standard property. Follow rules in the ePAPR for
-   hierarchical bus addressing. CCI interfaces
-   addresses refer to the parent node addressing
-   scheme to declare their register bases.
+   Definition: A standard property. Follow rules in the Devicetree
+   Specification for hierarchical bus addressing. CCI
+   interfaces addresses refer to the parent node
+   addressing scheme to declare their register bases.
 
CCI interconnect node can define the following child nodes:
 
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index 1030f5f50207..283c520a2224 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -6,9 +6,9 @@ The device tree allows to describe the layout of CPUs in a 
system through
 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
 defining properties for every cpu.
 
-Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
+Bindings for CPU nodes follow the Devicetree Specification, available from:
 
-https://www.power.org/documentation/epapr-version-1-1/
+https://www.devicetree.org/specifications/
 
 with updates for 32-bit and 64-bit ARM systems provided in this document.
 
@@ -16,8 +16,8 @@ with updates for 32-bit and 64-bit ARM systems provided in 
this document.
 Convention used in this document
 
 
-This document follows the conventions described in the ePAPR v1.1, with
-the addition:
+This document follows the conventions described in the Devicetree
+Specification, with the addition:
 
 - square brackets define bitfields, eg reg[7:0] value of the bitfield in
   the reg property contained in bits 7 down to 0
@@ -26,8 +26,9 @@ the addition:
 cpus and cpu node bindings definition
 =
 
-The ARM architecture, in 

Re: Alg errors with Intel QAT Card

[Raj Ammanur]

those previous alg error msgs are gone with 4.11.3-202.fc25.x86_64,
but now I see
multiple tracebacks like the ones below.

Looks like its been reported a few months back with 4.10.0-rc3+ , but
with no response
or further update:
https://www.spinics.net/lists/linux-crypto/msg23699.html


[  182.697358] WARNING: CPU: 6 PID: 558 at crypto/algapi.c:348
crypto_wait_for_test+0x60/0x80
[  182.699505] Modules linked in: ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
ebtable_broute bridge st
p llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_raw ip6table_mangle ip6table_security iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_raw
iptable_mangle iptable_security ebtable_filter ebtables
ip6table_filter
ip6_tables crct10dif_pclmul ppdev qat_dh895xcc(+) crc32_pclmul
intel_qat ghash_clmulni_intel joydev parport_pc parport acpi_cpufreq
tpm_tis t
pm_tis_core tpm virtio_balloon qemu_fw_cfg i2c_piix4 dh_generic
authenc nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_net
virtio_blk cir
rus drm_kms_helper ttm crc32c_intel drm serio_raw virtio_pci ixgbevf
virtio_ring virtio ata_generic pata_acpi
[  182.705805] CPU: 6 PID: 558 Comm: systemd-udevd Not tainted
4.11.3-202.fc25.x86_64 #1
[  182.706502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.1-1.fc24 04/01/2014
[  182.707269] Call Trace:
[  182.707513]  dump_stack+0x63/0x86
[  182.707825]  __warn+0xcb/0xf0
[  182.708098]  warn_slowpath_null+0x1d/0x20
[  182.708463]  crypto_wait_for_test+0x60/0x80
[  182.708842]  crypto_register_alg+0x5b/0x70
[  182.709208]  crypto_register_algs+0x3a/0x80
[  182.709599]  qat_algs_register+0x6c/0xc0 [intel_qat]
[  182.710041]  adf_dev_start+0xd1/0x160 [intel_qat]
[  182.710477]  adf_probe+0x5ec/0x610 [qat_dh895xcc]
[  182.710909]  local_pci_probe+0x45/0xa0
[  182.711250]  pci_device_probe+0xfa/0x150
[  182.711623]  driver_probe_device+0x2bb/0x460
[  182.712009]  __driver_attach+0xdf/0xf0
[  182.712349]  ? driver_probe_device+0x460/0x460
[  182.712751]  bus_for_each_dev+0x6c/0xc0
[  182.713099]  driver_attach+0x1e/0x20
[  182.713426]  bus_add_driver+0x170/0x270
[  182.713773]  driver_register+0x60/0xe0
[  182.714113]  ? 0xc01ba000
[  182.714425]  __pci_register_driver+0x4c/0x50
[  182.714811]  adfdrv_init+0x2f/0x1000 [qat_dh895xcc]
[  182.715255]  do_one_initcall+0x52/0x1a0
[  182.715618]  ? kmem_cache_alloc_trace+0x159/0x1b0
[  182.716047]  ? do_init_module+0x27/0x1f8
[  182.716406]  do_init_module+0x5f/0x1f8
[  182.716754]  load_module+0x27cc/0x2be0
[  182.717096]  SYSC_init_module+0x173/0x190
[  182.717461]  ? SYSC_init_module+0x173/0x190
[  182.717837]  SyS_init_module+0xe/0x10
[  182.718169]  do_syscall_64+0x67/0x180
[  182.719638]  entry_SYSCALL64_slow_path+0x25/0x25
[  182.721178] RIP: 0033:0x7fd22ee715ca
[  182.722622] RSP: 002b:7ffc498bc428 EFLAGS: 0246 ORIG_RAX:
00af
[  182.724415] RAX: ffda RBX: 55ba9680ca30 RCX: 7fd22ee715ca
[  182.726161] RDX: 7fd22f9a3995 RSI: 3f03 RDI: 55ba97066a00
[  182.727897] RBP: 7fd22f9a3995 R08: 55ba9680d460 R09: 
[  182.729624] R10:  R11: 0246 R12: 55ba97066a00
[  182.731326] R13: 55ba9681b030 R14: 0002 R15: 55ba9680ca30

On Tue, Jun 13, 2017 at 1:32 PM, Raj Ammanur  wrote:
> Hi Neil & Salvatore,
>
> thanks for the replies. The soft reboot hasn't helped. I am trying a previous
> kernel version that works with a similar card that we installed in
> another server
> and that works fine. Will keep you posted.
>
> Neil: have you found fix/workaround for the firmware errors or you just using
> a soft reboot? by that, you just mean unload and load the kernel modules or
> a system reboot. I have tried both.
>
> thanks
> --Raj
>
> On Tue, Jun 13, 2017 at 5:30 AM, Neil Horman  wrote:
>> On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote:
>>> Hi Raj,
>>>
>>> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue.
>>> Are you seeing any of this with a previous kernel version? If not, git 
>>> bisect might
>>> help us finding the root-cause.
>>> Have you tried with another platform/hw?
>>>
>>> Regards,
>>> Salvatore
>>>
>> Try a soft reboot and see if the error clears up.  This looks a bit 
>> reminscient
>> of some firmware errors we've been chasing down
>> Neil
>>
>>> > -Original Message-
>>> > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
>>> > ow...@vger.kernel.org] On Behalf Of Raj Ammanur
>>> > Sent: Friday, June 9, 2017 7:37 PM
>>> > To: Linux Crypto Mailing List 
>>> > Subject: Alg errors with Intel QAT Card
>>> >
>>> > Hi
>>> >
>>> > I am seeing the below errors after  installing an Intel QAT card
>>> > and loading the upstreamed qat_dh895xcc and intel_qat modules.
>>> >
>>> > Have others seen similar errors