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

2017-06-12 Thread kbuild test robot 
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


.config.gz
Description: application/gzip

[PATCH] crypto: testmgr - add testvector for pkcs1pad(rsa)

2017-06-12 Thread Stephan Müller 
The PKCS#1 RSA implementation is provided with a self test with RSA 2048
and SHA-256. This self test implicitly covers other RSA keys and other
hashes. Also, this self test implies that the pkcs1pad(rsa) is FIPS
140-2 compliant.

Signed-off-by: Stephan Mueller 
---
 crypto/testmgr.c | 33 ---
 crypto/testmgr.h | 96 
 2 files changed, 125 insertions(+), 4 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 5f8e683..4441273 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -,8 +,11 @@ static int test_akcipher_one(struct crypto_akcipher *tfm,
akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
  tcrypt_complete, );
 
-   /* Run RSA encrypt - c = m^e mod n;*/
-   err = wait_async_op(, crypto_akcipher_encrypt(req));
+   err = wait_async_op(, vecs->siggen_sigver_test ?
+/* Run asymmetric signature generation */
+crypto_akcipher_sign(req) :
+/* Run asymmetric encrypt */
+crypto_akcipher_encrypt(req));
if (err) {
pr_err("alg: akcipher: encrypt test failed. err %d\n", err);
goto free_all;
@@ -2261,8 +2264,11 @@ static int test_akcipher_one(struct crypto_akcipher *tfm,
init_completion();
akcipher_request_set_crypt(req, , , vecs->c_size, out_len_max);
 
-   /* Run RSA decrypt - m = c^d mod n;*/
-   err = wait_async_op(, crypto_akcipher_decrypt(req));
+   err = wait_async_op(, vecs->siggen_sigver_test ?
+/* Run asymmetric signature verification */
+crypto_akcipher_verify(req) :
+/* Run asymmetric decrypt */
+crypto_akcipher_decrypt(req));
if (err) {
pr_err("alg: akcipher: decrypt test failed. err %d\n", err);
goto free_all;
@@ -3309,6 +3315,25 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+   .alg = "pkcs1pad(rsa,sha224)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "pkcs1pad(rsa,sha256)",
+   .test = alg_test_akcipher,
+   .fips_allowed = 1,
+   .suite = {
+   .akcipher = __VECS(pkcs1pad_rsa_tv_template)
+   }
+   }, {
+   .alg = "pkcs1pad(rsa,sha384)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "pkcs1pad(rsa,sha512)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
.alg = "poly1305",
.test = alg_test_hash,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index db2e26c..9188f9e 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -133,6 +133,7 @@ struct akcipher_testvec {
unsigned int m_size;
unsigned int c_size;
bool public_key_vec;
+   bool siggen_sigver_test;
 };
 
 struct kpp_testvec {
@@ -541,6 +542,101 @@ static const struct akcipher_testvec rsa_tv_template[] = {
}
 };
 
+/*
+ * PKCS#1 RSA test vectors. Obtained from CAVS testing.
+ */
+static const struct akcipher_testvec pkcs1pad_rsa_tv_template[] = {
+   {
+   .key =
+   "\x30\x82\x03\x1f\x02\x01\x10\x02\x82\x01\x01\x00\xd7\x1e\x77\x82"
+   "\x8c\x92\x31\xe7\x69\x02\xa2\xd5\x5c\x78\xde\xa2\x0c\x8f\xfe\x28"
+   "\x59\x31\xdf\x40\x9c\x60\x61\x06\xb9\x2f\x62\x40\x80\x76\xcb\x67"
+   "\x4a\xb5\x59\x56\x69\x17\x07\xfa\xf9\x4c\xbd\x6c\x37\x7a\x46\x7d"
+   "\x70\xa7\x67\x22\xb3\x4d\x7a\x94\xc3\xba\x4b\x7c\x4b\xa9\x32\x7c"
+   "\xb7\x38\x95\x45\x64\xa4\x05\xa8\x9f\x12\x7c\x4e\xc6\xc8\x2d\x40"
+   "\x06\x30\xf4\x60\xa6\x91\xbb\x9b\xca\x04\x79\x11\x13\x75\xf0\xae"
+   "\xd3\x51\x89\xc5\x74\xb9\xaa\x3f\xb6\x83\xe4\x78\x6b\xcd\xf9\x5c"
+   "\x4c\x85\xea\x52\x3b\x51\x93\xfc\x14\x6b\x33\x5d\x30\x70\xfa\x50"
+   "\x1b\x1b\x38\x81\x13\x8d\xf7\xa5\x0c\xc0\x8e\xf9\x63\x52\x18\x4e"
+   "\xa9\xf9\xf8\x5c\x5d\xcd\x7a\x0d\xd4\x8e\x7b\xee\x91\x7b\xad\x7d"
+   "\xb4\x92\xd5\xab\x16\x3b\x0a\x8a\xce\x8e\xde\x47\x1a\x17\x01\x86"
+   "\x7b\xab\x99\xf1\x4b\x0c\x3a\x0d\x82\x47\xc1\x91\x8c\xbb\x2e\x22"
+   "\x9e\x49\x63\x6e\x02\xc1\xc9\x3a\x9b\xa5\x22\x1b\x07\x95\xd6\x10"
+   "\x02\x50\xfd\xfd\xd1\x9b\xbe\xab\xc2\xc0\x74\xd7\xec\x00\xfb\x11"
+   "\x71\xcb\x7a\xdc\x81\x79\x9f\x86\x68\x46\x63\x82\x4d\xb7\xf1\xe6"
+   "\x16\x6f\x42\x63\xf4\x94\xa0\xca\x33\xcc\x75\x13\x02\x82\x01\x00"
+   "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+

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

2017-06-12 Thread sean.wang 
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(-)

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;
-- 
1.9.1

[PATCH v2 0/3] add support of hardware random generator on MediaTek MT7622

2017-06-12 Thread sean.wang 
From: Sean Wang 

Changes since v1:
- update the bindings with the specific "mediatek,mt7622-rng"
  instead of the generic one as "mediatek,generic-rng"

The series add support of hardware RNG on MediaTek MT7622 and
, runtime PM support and add me as the maintainer for the existing
and following chipset.

Sean Wang (3):
  dt-bindings: rng: add MediaTek MT7622 Hardware Random Generator
bindings
  hwrng: mtk - add runtime PM support
  MAINTAINERS: add entry for MediaTek Random Number Generator

 Documentation/devicetree/bindings/rng/mtk-rng.txt |  4 ++-
 MAINTAINERS   |  5 +++
 drivers/char/hw_random/mtk-rng.c  | 42 +++
 3 files changed, 50 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v2 3/3] MAINTAINERS: add entry for MediaTek Random Number Generator

2017-06-12 Thread sean.wang 
From: Sean Wang 

I work for MediaTek on maintaining the MediaTek RNG driver
for the existing SoCs and adding support for the following
SoCs.

Signed-off-by: Sean Wang 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cf86519..da473d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8262,6 +8262,11 @@ L:   linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/mediatek/mt7601u/
 
+MEDIATEK RANDOM NUMBER GENERATOR SUPPORT
+M:  Sean Wang 
+S:  Maintained
+F:  drivers/char/hw_random/mtk-rng.c
+
 MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES
 M: Peter Senna Tschudin 
 M: Martin Donnelly 
-- 
1.9.1

[PATCH v2 2/3] hwrng: mtk - add runtime PM support

2017-06-12 Thread sean.wang 
From: Sean Wang 

Add runtime PM support.  There will be the benefit on SoCs where the
clock to the RNG used can be shutdown.

Signed-off-by: Sean Wang 
---
 drivers/char/hw_random/mtk-rng.c | 42 
 1 file changed, 42 insertions(+)

diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
index df8eb54..8da7bcf 100644
--- a/drivers/char/hw_random/mtk-rng.c
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 #include 
+#include 
+
+/* Runtime PM autosuspend timeout: */
+#define RNG_AUTOSUSPEND_TIMEOUT100
 
 #define USEC_POLL  2
 #define TIMEOUT_POLL   20
@@ -90,6 +94,8 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, size_t 
max, bool wait)
struct mtk_rng *priv = to_mtk_rng(rng);
int retval = 0;
 
+   pm_runtime_get_sync((struct device *)priv->rng.priv);
+
while (max >= sizeof(u32)) {
if (!mtk_rng_wait_ready(rng, wait))
break;
@@ -100,6 +106,9 @@ static int mtk_rng_read(struct hwrng *rng, void *buf, 
size_t max, bool wait)
max -= sizeof(u32);
}
 
+   pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
+   pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
+
return retval || !wait ? retval : -EIO;
 }
 
@@ -120,9 +129,12 @@ static int mtk_rng_probe(struct platform_device *pdev)
return -ENOMEM;
 
priv->rng.name = pdev->name;
+#ifndef CONFIG_PM
priv->rng.init = mtk_rng_init;
priv->rng.cleanup = mtk_rng_cleanup;
+#endif
priv->rng.read = mtk_rng_read;
+   priv->rng.priv = (unsigned long)>dev;
 
priv->clk = devm_clk_get(>dev, "rng");
if (IS_ERR(priv->clk)) {
@@ -142,11 +154,40 @@ static int mtk_rng_probe(struct platform_device *pdev)
return ret;
}
 
+   dev_set_drvdata(>dev, priv);
+   pm_runtime_set_autosuspend_delay(>dev, RNG_AUTOSUSPEND_TIMEOUT);
+   pm_runtime_use_autosuspend(>dev);
+   pm_runtime_enable(>dev);
+
dev_info(>dev, "registered RNG driver\n");
 
return 0;
 }
 
+#ifdef CONFIG_PM
+static int mtk_rng_runtime_suspend(struct device *dev)
+{
+   struct mtk_rng *priv = dev_get_drvdata(dev);
+
+   mtk_rng_cleanup(>rng);
+
+   return 0;
+}
+
+static int mtk_rng_runtime_resume(struct device *dev)
+{
+   struct mtk_rng *priv = dev_get_drvdata(dev);
+
+   return mtk_rng_init(>rng);
+}
+
+static UNIVERSAL_DEV_PM_OPS(mtk_rng_pm_ops, mtk_rng_runtime_suspend,
+   mtk_rng_runtime_resume, NULL);
+#define MTK_RNG_PM_OPS (_rng_pm_ops)
+#else  /* CONFIG_PM */
+#define MTK_RNG_PM_OPS NULL
+#endif /* CONFIG_PM */
+
 static const struct of_device_id mtk_rng_match[] = {
{ .compatible = "mediatek,mt7623-rng" },
{},
@@ -157,6 +198,7 @@ static int mtk_rng_probe(struct platform_device *pdev)
.probe  = mtk_rng_probe,
.driver = {
.name = MTK_RNG_DEV,
+   .pm = MTK_RNG_PM_OPS,
.of_match_table = mtk_rng_match,
},
 };
-- 
1.9.1

RE: Alg errors with Intel QAT Card

2017-06-12 Thread Benedetto, Salvatore 
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

> -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
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-

Re: [PATCH 00/12] arm64: crypto: prepare for new kernel mode NEON policy

2017-06-12 Thread Ard Biesheuvel 
On 10 June 2017 at 18:22, Ard Biesheuvel  wrote:
> TL;DR: preparatory work for expected changes in arm64's handling of kernel
>mode SIMD
>
> @Herbert: The arm64 maintainers may want to take this through the arm64 tree,
>   and if not, we need their acks on patch #1. Thanks.
>

Please disregard this for merging for now. I am looking into whether
it is possible to use time invariant fallbacks instead for the AES
routines (and I missed a couple of AES MAC routines in the conversion)

> Currently, arm64 allows kernel mode NEON (KMN) in process, softirq or hardirq
> context. In the process case, we preserve/restore the NEON context lazily,
> but in the softirq/hardirq cases, we eagerly stash a slice of the NEON
> register file, and immediately restore it when kernel_neon_end() is called.
>
> Given the above, arm64 actually does not use the generic may_use_simd() API
> at all*, which was added to allow async wrappers of synchronous SIMD routines
> to be implemented in a generic manner. (On x86, kernel mode SIMD may be used
> in process context or while serving an interrupt taken from user space. On 
> ARM,
> SIMD may only be used in process context)
>
> When adding support for the SVE architecture extension, which shared part of
> the NEON register file with the SIMD and crypto extensions, the eager 
> preserve/
> restore in interrupt context is becoming a problem: it should either preserve
> and restore the entire SVE state (which may be up to 8 KB in size), or it
> should not be allowed to interrupt the lazy preserve, which does need to deal
> with the large SVE state anyway. Otherwise, such an interruption would corrupt
> the NEON state the lazy preserve sees after the interruption.
>
> Given how
> a) KMN is never actually used in hardirq context,
> b) KMN is only used in softirq context by mac80211 code running on behalf of
>WiFi devices that don't perform the crypto in hardware,
> b) KMN in softirq context is statistically unlikely to interrupt the kernel
>while it is doing kernel mode NEON in process context,
>
> the unconditional eager preserve/restore typically executes when no KMN in
> process context is in progress, and we can simplify things substantially by
> disallowing nested KMN, i.e., disallow KMN in hardirq context, and allow KMN
> in softirq only if no KMN in process context is already in progress.
>
> The no-nesting rule leaves only the outer SVE-aware lazy preserve/restore,
> which needs to execute with bottom halves disabled, but other than that, no
> intrusive changes should be needed to deal with the SVE payloads.
>
> Given that the no-nesting rule implies that SIMD is no longer allowed in any
> context, the KMN users need to be made aware of this. This series updates the
> current KMN users in the arm64 tree to take may_use_simd() into account. Since
> at this time, SIMD is still allowed in any context, an implementation of
> may_use_simd() is added that simply returns true (#1). It will be updated in
> the future when the no-nesting modifications are made.
>
> * may_use_simd() is only used as a hint in the SHA256 NEON code, since on some
>   microarchitectures, it is only marginally faster, and the eager preserve and
>   restore could actually make it slower.
>
> Ard Biesheuvel (12):
>   arm64: neon: replace generic definition of may_use_simd()
>   crypto: arm64/ghash-ce - add non-SIMD scalar fallback
>   crypto: arm64/crct10dif - add non-SIMD generic fallback
>   crypto: arm64/crc32 - add non-SIMD scalar fallback
>   crypto: arm64/sha1-ce - add non-SIMD generic fallback
>   crypto: arm64/sha2-ce - add non-SIMD scalar fallback
>   crypto: arm64/aes-ce-cipher - match round key endianness with generic
> code
>   crypto: arm64/aes-ce-cipher: add non-SIMD generic fallback
>   crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback
>   crypto: arm64/aes-blk - add a non-SIMD fallback for synchronous CTR
>   crypto: arm64/chacha20 - take may_use_simd() into account
>   crypto: arm64/aes-bs - implement non-SIMD fallback for AES-CTR
>
>  arch/arm64/crypto/Kconfig  |  22 ++-
>  arch/arm64/crypto/aes-ce-ccm-core.S|  30 ++--
>  arch/arm64/crypto/aes-ce-ccm-glue.c| 152 +++-
>  arch/arm64/crypto/aes-ce-cipher.c  |  55 ---
>  arch/arm64/crypto/aes-ce.S |  12 +-
>  arch/arm64/crypto/aes-ctr-fallback.h   |  55 +++
>  arch/arm64/crypto/aes-glue.c   |  17 ++-
>  arch/arm64/crypto/aes-neonbs-glue.c|  48 ++-
>  arch/arm64/crypto/chacha20-neon-glue.c |   5 +-
>  arch/arm64/crypto/crc32-ce-glue.c  |  11 +-
>  arch/arm64/crypto/crct10dif-ce-glue.c  |  13 +-
>  arch/arm64/crypto/ghash-ce-glue.c  |  49 +--
>  arch/arm64/crypto/sha1-ce-glue.c   |  18 ++-
>  arch/arm64/crypto/sha2-ce-glue.c   |  30 +++-
>  arch/arm64/crypto/sha256-glue.c|   1 +
>  arch/arm64/include/asm/Kbuild  |   1 -
>  arch/arm64/include/asm/simd.h  |  24 
>  17 files

Re: [PATCH v3 0/5] Add support for the STM32F4 CRC32

2017-06-12 Thread Alexandre Torgue 

Hi Cosar,

On 05/22/2017 04:33 PM, Cosar Dindar wrote:

This patch series add hardware CRC32 ("Ethernet") calculation support
for STMicroelectronics STM32F429.

Polynomial and key setting are not supported, key is fixed as 0x4C11DB7
and poly is 0x.

Module is tested on STM32F429-disco board with crypto testmgr using
cases within the key 0x.

Changes in v3:
 Rearranged patch order to fix build test error.

Cosar Dindar (5):
   dt-bindings : Document the STM32F4 CRC32 binding
   crypto : stm32 - Add STM32F4 CRC32 support
   ARM: dts: stm32: Add CRC support to stm32f429
   ARM: dts: stm32: enable CRC32 on stm32429-disco board
   ARM: dts: stm32: enable CRC32 on stm32429i-eval board

  .../devicetree/bindings/crypto/st,stm32-crc.txt|  4 +-
  arch/arm/boot/dts/stm32429i-eval.dts   |  4 ++
  arch/arm/boot/dts/stm32f429-disco.dts  |  4 ++
  arch/arm/boot/dts/stm32f429.dtsi   |  7 +++
  drivers/crypto/stm32/stm32_crc32.c | 68 ++
  5 files changed, 75 insertions(+), 12 deletions(-)



Patches 3, 4, 5 applied on stm32-dt-for-v4.13

regards
Alex

Re: [PATCH 1/1] crypto:drbg- Fixes panic in wait_for_completion call.

2017-06-12 Thread Harsh Jain 
Hi Herbert,

Since It's a panic BUG.  Can we push this fix to stable kernel releases?

Regards
Harsh Jain

On Sat, Jun 10, 2017 at 9:47 AM, Herbert Xu  wrote:
> On Fri, May 26, 2017 at 12:12:51PM +0200, Stephan Müller wrote:
>> Am Donnerstag, 25. Mai 2017, 17:23:47 CEST schrieb Harsh Jain:
>>
>> Hi Harsh,
>>
>> > Initialise ctr_completion variable before use.
>>
>> Thank you very much for catching this.
>>
>> But I think the chosen function is wrong. When we have an HMAC or Hash DRBG, 
>> this completion function does not need to be initialized.
>>
>> May I ask you to check this patch?
>
> Patch applied.  Thanks.
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt