[PATCH v1 4/4] crypto: crypto4xx - kill MODULE_NAME

[Christian Lamparter]

KBUILD_MODNAME provides the same value.

Signed-off-by: Christian Lamparter 
---
 drivers/crypto/amcc/crypto4xx_core.c | 2 +-
 drivers/crypto/amcc/crypto4xx_core.h | 2 --
 drivers/crypto/amcc/crypto4xx_trng.c | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index 4b03318775ac..f148627e925c 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1432,7 +1432,7 @@ MODULE_DEVICE_TABLE(of, crypto4xx_match);
 
 static struct platform_driver crypto4xx_driver = {
.driver = {
-   .name = MODULE_NAME,
+   .name = KBUILD_MODNAME,
.of_match_table = crypto4xx_match,
},
.probe  = crypto4xx_probe,
diff --git a/drivers/crypto/amcc/crypto4xx_core.h 
b/drivers/crypto/amcc/crypto4xx_core.h
index 61a02a4c5794..23b726da6534 100644
--- a/drivers/crypto/amcc/crypto4xx_core.h
+++ b/drivers/crypto/amcc/crypto4xx_core.h
@@ -28,8 +28,6 @@
 #include "crypto4xx_reg_def.h"
 #include "crypto4xx_sa.h"
 
-#define MODULE_NAME "crypto4xx"
-
 #define PPC460SX_SDR0_SRST  0x201
 #define PPC405EX_SDR0_SRST  0x200
 #define PPC460EX_SDR0_SRST  0x201
diff --git a/drivers/crypto/amcc/crypto4xx_trng.c 
b/drivers/crypto/amcc/crypto4xx_trng.c
index 677ca17fd223..5e63742b0d22 100644
--- a/drivers/crypto/amcc/crypto4xx_trng.c
+++ b/drivers/crypto/amcc/crypto4xx_trng.c
@@ -92,7 +92,7 @@ void ppc4xx_trng_probe(struct crypto4xx_core_device *core_dev)
if (!rng)
goto err_out;
 
-   rng->name = MODULE_NAME;
+   rng->name = KBUILD_MODNAME;
rng->data_present = ppc4xx_trng_data_present;
rng->data_read = ppc4xx_trng_data_read;
rng->priv = (unsigned long) dev;
-- 
2.15.1

[PATCH v1 3/4] crypto: crypto4xx - fix missing irq devname

[Christian Lamparter]

crypto4xx_device's name variable is not set to anything.
The common devname for request_irq seems to be the module
name. This will fix the seemingly anonymous interrupt
entry in /proc/interrupts for crypto4xx.

Signed-off-by: Christian Lamparter 
---
 drivers/crypto/amcc/crypto4xx_core.c | 2 +-
 drivers/crypto/amcc/crypto4xx_core.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index fde0136029f1..4b03318775ac 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1370,7 +1370,7 @@ static int crypto4xx_probe(struct platform_device *ofdev)
rc = request_irq(core_dev->irq, is_revb ?
 crypto4xx_ce_interrupt_handler_revb :
 crypto4xx_ce_interrupt_handler, 0,
-core_dev->dev->name, dev);
+KBUILD_MODNAME, dev);
if (rc)
goto err_request_irq;
 
diff --git a/drivers/crypto/amcc/crypto4xx_core.h 
b/drivers/crypto/amcc/crypto4xx_core.h
index 013d9992a44e..61a02a4c5794 100644
--- a/drivers/crypto/amcc/crypto4xx_core.h
+++ b/drivers/crypto/amcc/crypto4xx_core.h
@@ -82,7 +82,6 @@ struct pd_uinfo {
 
 struct crypto4xx_device {
struct crypto4xx_core_device *core_dev;
-   char *name;
void __iomem *ce_base;
void __iomem *trng_base;
 
-- 
2.15.1

[PATCH v1 1/4] crypto: crypto4xx - shuffle iomap in front of request_irq

[Christian Lamparter]

It is possible to avoid the ce_base null pointer check in the
drivers' interrupt handler routine "crypto4xx_ce_interrupt_handler()"
by simply doing the iomap in front of the IRQ registration.

This way, the ce_base will always be valid in the handler and
a branch in an critical path can be avoided.

Signed-off-by: Christian Lamparter 
---
 drivers/crypto/amcc/crypto4xx_core.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index c44954e274bc..50d5e64fbdbf 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -1075,9 +1075,6 @@ static irqreturn_t crypto4xx_ce_interrupt_handler(int 
irq, void *data)
struct device *dev = (struct device *)data;
struct crypto4xx_core_device *core_dev = dev_get_drvdata(dev);
 
-   if (!core_dev->dev->ce_base)
-   return 0;
-
writel(PPC4XX_INTERRUPT_CLR,
   core_dev->dev->ce_base + CRYPTO4XX_INT_CLR);
tasklet_schedule(_dev->tasklet);
@@ -1325,13 +1322,6 @@ static int crypto4xx_probe(struct platform_device *ofdev)
tasklet_init(_dev->tasklet, crypto4xx_bh_tasklet_cb,
 (unsigned long) dev);
 
-   /* Register for Crypto isr, Crypto Engine IRQ */
-   core_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
-   rc = request_irq(core_dev->irq, crypto4xx_ce_interrupt_handler, 0,
-core_dev->dev->name, dev);
-   if (rc)
-   goto err_request_irq;
-
core_dev->dev->ce_base = of_iomap(ofdev->dev.of_node, 0);
if (!core_dev->dev->ce_base) {
dev_err(dev, "failed to of_iomap\n");
@@ -1339,6 +1329,13 @@ static int crypto4xx_probe(struct platform_device *ofdev)
goto err_iomap;
}
 
+   /* Register for Crypto isr, Crypto Engine IRQ */
+   core_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
+   rc = request_irq(core_dev->irq, crypto4xx_ce_interrupt_handler, 0,
+core_dev->dev->name, dev);
+   if (rc)
+   goto err_request_irq;
+
/* need to setup pdr, rdr, gdr and sdr before this */
crypto4xx_hw_init(core_dev->dev);
 
@@ -1352,11 +1349,11 @@ static int crypto4xx_probe(struct platform_device 
*ofdev)
return 0;
 
 err_start_dev:
-   iounmap(core_dev->dev->ce_base);
-err_iomap:
free_irq(core_dev->irq, dev);
 err_request_irq:
irq_dispose_mapping(core_dev->irq);
+   iounmap(core_dev->dev->ce_base);
+err_iomap:
tasklet_kill(_dev->tasklet);
 err_build_sdr:
crypto4xx_destroy_sdr(core_dev->dev);
-- 
2.15.1

[PATCH v1 2/4] crypto: crypto4xx - support Revision B parts

[Christian Lamparter]

This patch adds support for the crypto4xx RevB cores
found in the 460EX, 460SX and later cores (like the APM821xx).

Without this patch, the crypto4xx driver will not be
able to process any offloaded requests and simply hang
indefinitely.

Signed-off-by: Christian Lamparter 
---
 drivers/crypto/amcc/crypto4xx_core.c| 48 +
 drivers/crypto/amcc/crypto4xx_core.h|  1 +
 drivers/crypto/amcc/crypto4xx_reg_def.h |  4 ++-
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index 50d5e64fbdbf..fde0136029f1 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -128,7 +128,14 @@ static void crypto4xx_hw_init(struct crypto4xx_device *dev)
writel(PPC4XX_INT_DESCR_CNT, dev->ce_base + CRYPTO4XX_INT_DESCR_CNT);
writel(PPC4XX_INT_DESCR_CNT, dev->ce_base + CRYPTO4XX_INT_DESCR_CNT);
writel(PPC4XX_INT_CFG, dev->ce_base + CRYPTO4XX_INT_CFG);
-   writel(PPC4XX_PD_DONE_INT, dev->ce_base + CRYPTO4XX_INT_EN);
+   if (dev->is_revb) {
+   writel(PPC4XX_INT_TIMEOUT_CNT_REVB << 10,
+  dev->ce_base + CRYPTO4XX_INT_TIMEOUT_CNT);
+   writel(PPC4XX_PD_DONE_INT | PPC4XX_TMO_ERR_INT,
+  dev->ce_base + CRYPTO4XX_INT_EN);
+   } else {
+   writel(PPC4XX_PD_DONE_INT, dev->ce_base + CRYPTO4XX_INT_EN);
+   }
 }
 
 int crypto4xx_alloc_sa(struct crypto4xx_ctx *ctx, u32 size)
@@ -1070,18 +1077,29 @@ static void crypto4xx_bh_tasklet_cb(unsigned long data)
 /**
  * Top Half of isr.
  */
-static irqreturn_t crypto4xx_ce_interrupt_handler(int irq, void *data)
+static inline irqreturn_t crypto4xx_interrupt_handler(int irq, void *data,
+ u32 clr_val)
 {
struct device *dev = (struct device *)data;
struct crypto4xx_core_device *core_dev = dev_get_drvdata(dev);
 
-   writel(PPC4XX_INTERRUPT_CLR,
-  core_dev->dev->ce_base + CRYPTO4XX_INT_CLR);
+   writel(clr_val, core_dev->dev->ce_base + CRYPTO4XX_INT_CLR);
tasklet_schedule(_dev->tasklet);
 
return IRQ_HANDLED;
 }
 
+static irqreturn_t crypto4xx_ce_interrupt_handler(int irq, void *data)
+{
+   return crypto4xx_interrupt_handler(irq, data, PPC4XX_INTERRUPT_CLR);
+}
+
+static irqreturn_t crypto4xx_ce_interrupt_handler_revb(int irq, void *data)
+{
+   return crypto4xx_interrupt_handler(irq, data, PPC4XX_INTERRUPT_CLR |
+   PPC4XX_TMO_ERR_INT);
+}
+
 /**
  * Supported Crypto Algorithms
  */
@@ -1263,6 +1281,8 @@ static int crypto4xx_probe(struct platform_device *ofdev)
struct resource res;
struct device *dev = >dev;
struct crypto4xx_core_device *core_dev;
+   u32 pvr;
+   bool is_revb = true;
 
rc = of_address_to_resource(ofdev->dev.of_node, 0, );
if (rc)
@@ -1279,6 +1299,7 @@ static int crypto4xx_probe(struct platform_device *ofdev)
   mfdcri(SDR0, PPC405EX_SDR0_SRST) | PPC405EX_CE_RESET);
mtdcri(SDR0, PPC405EX_SDR0_SRST,
   mfdcri(SDR0, PPC405EX_SDR0_SRST) & ~PPC405EX_CE_RESET);
+   is_revb = false;
} else if (of_find_compatible_node(NULL, NULL,
"amcc,ppc460sx-crypto")) {
mtdcri(SDR0, PPC460SX_SDR0_SRST,
@@ -1301,7 +1322,22 @@ static int crypto4xx_probe(struct platform_device *ofdev)
if (!core_dev->dev)
goto err_alloc_dev;
 
+   /*
+* Older version of 460EX/GT have a hardware bug.
+* Hence they do not support H/W based security intr coalescing
+*/
+   pvr = mfspr(SPRN_PVR);
+   if (is_revb && ((pvr >> 4) == 0x130218A)) {
+   u32 min = PVR_MIN(pvr);
+
+   if (min < 4) {
+   dev_info(dev, "RevA detected - disable interrupt 
coalescing\n");
+   is_revb = false;
+   }
+   }
+
core_dev->dev->core_dev = core_dev;
+   core_dev->dev->is_revb = is_revb;
core_dev->device = dev;
spin_lock_init(_dev->lock);
INIT_LIST_HEAD(_dev->dev->alg_list);
@@ -1331,7 +1367,9 @@ static int crypto4xx_probe(struct platform_device *ofdev)
 
/* Register for Crypto isr, Crypto Engine IRQ */
core_dev->irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
-   rc = request_irq(core_dev->irq, crypto4xx_ce_interrupt_handler, 0,
+   rc = request_irq(core_dev->irq, is_revb ?
+crypto4xx_ce_interrupt_handler_revb :
+crypto4xx_ce_interrupt_handler, 0,
 core_dev->dev->name, dev);
if (rc)
goto err_request_irq;
diff --git a/drivers/crypto/amcc/crypto4xx_core.h 
b/drivers/crypto/amcc/crypto4xx_core.h
index 8ac3bd37203b..013d9992a44e 100644
--- a/drivers/crypto/amcc/crypto4xx_core.h

Re: [PATCH v5] hwrng: exynos - add Samsung Exynos True RNG driver

[Philippe Ombredanne]

Łukasz,

On Fri, Dec 22, 2017 at 5:48 PM, Łukasz Stelmach  wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> Changes since v4:
>
> - SPDX license header instead of the traditional blurb.
>
> - MODULE_LICENSE("GPL v2") instead of "GPL"
>
> Thank you, Philippe Ombredanne.

You have my cheerful ack for these changes:

Acked-by: Philippe Ombredanne 

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Philippe Ombredanne]

On Fri, Dec 22, 2017 at 5:38 PM, Łukasz Stelmach  wrote:
> It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
>> Łukasz,
>>
>> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach  
>> wrote:
>>> Add support for True Random Number Generator found in Samsung Exynos
>>> 5250+ SoCs.
>>>
>>> Signed-off-by: Łukasz Stelmach 
>>> Reviewed-by: Krzysztof Kozlowski 
>>
>> 
>>
>>> --- /dev/null
>>> +++ b/drivers/char/hw_random/exynos-trng.c
>>> @@ -0,0 +1,245 @@
>>> +/*
>>> + * RNG driver for Exynos TRNGs
>>> + *
>>> + * Author: Łukasz Stelmach 
>>> + *
>>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>>> + *
>>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>>> + * Krzysztof Kozłowski 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation;
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>
>>
>> Would you mind using the new SPDX tags documented in Thomas patch set
>> [1] rather than this fine but longer legalese?
>>
>> And if you could spread the word to others in your team this would be very 
>> nice.
>> See also this fine article posted by Mauro on the Samsung Open Source
>> Group Blog [2]
>> Thank you!
>
> Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
> more. ;-)

Very nice! any pubic pointers?


>>> +MODULE_LICENSE("GPL");
>>
>> Per module.h this means GPL2 or later. This is not matching your
>> license above which does not state any version and therefore would
>> mean GPL1 or later,
>
> Thanks for spotting. My intention is GPL-2.0.
>
>> Please make sure you use something and common rather than this and
>> make sure your MODULE_LICENSE is consistent with the top level
>> license.
>>
>> Was it this way in the code from Krzysztof?
>
> Yes. And omap-rng, the second of my sources of reference, too. Actually,
> the majority of modules still specify "GPL".
>
>  281 | "Dual */*"
> 2082 | "GPL v2"
> 6359 | "GPL"
>  +-
> 8784 | Total
>
> Fixing.


Sigh. That's a lot! Now I have the tool to spot all these differences.
I need to run this and review.
As a first pass aligning the MODULE_LICENSE with the top level would
be something that requires minimal discussion I guess.

>> [1] https://lkml.org/lkml/2017/12/4/934
>> [2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/
>
> --
> Łukasz Stelmach
> Samsung R Institute Poland
> Samsung Electronics

-- 
Cordially
Philippe Ombredanne

Re: KASAN: use-after-free Read in __list_del_entry_valid (2)

[Eric Biggers]

On Sun, Dec 17, 2017 at 09:50:01PM -0800, syzbot wrote:
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.

#syz fix: crypto: pcrypt - fix freeing pcrypt instances

Re: KASAN: slab-out-of-bounds Write in sha3_update (2)

[Eric Biggers]

[+Cc keyri...@vger.kernel.org]

On Fri, Dec 22, 2017 at 07:55:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 9035a8961b504d0997369509ab8c6b1f0a4ee33d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> audit: type=1400 audit(1513919078.260:7): avc:  denied  { map } for
> pid=3152 comm="syzkaller717822" path="/root/syzkaller717822551" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in sha3_update+0xdf/0x2e0
> crypto/sha3_generic.c:161
> Write of size 192 at addr 8801cf0e3b3c by task syzkaller717822/3152
> 
> CPU: 0 PID: 3152 Comm: syzkaller717822 Not tainted 4.15.0-rc4+ #232
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
>  crypto_shash_update+0xda/0x240 crypto/shash.c:110
>  hmac_update+0x7e/0xa0 crypto/hmac.c:122
>  crypto_shash_update+0xda/0x240 crypto/shash.c:110
>  kdf_ctr security/keys/dh.c:181 [inline]
>  keyctl_dh_compute_kdf security/keys/dh.c:226 [inline]
>  __keyctl_dh_compute+0x160f/0x1990 security/keys/dh.c:398
>  keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
>  SYSC_keyctl security/keys/keyctl.c:1741 [inline]
>  SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x43feb9
> RSP: 002b:7ffd3aef51a8 EFLAGS: 0217 ORIG_RAX: 00fa
> RAX: ffda RBX: 004002c8 RCX: 0043feb9
> RDX: 20c2cfff RSI: 204c8ff4 RDI: 0017
> RBP: 006ca018 R08: 208e6fd4 R09: 
> R10: 0001 R11: 0217 R12: 00401820
> R13: 004018b0 R14:  R15: 
> 
> Allocated by task 3152:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc mm/slab.c:3708 [inline]
>  __kmalloc+0x162/0x760 mm/slab.c:3717
>  kmalloc include/linux/slab.h:504 [inline]
>  kdf_alloc security/keys/dh.c:111 [inline]
>  __keyctl_dh_compute+0x2b0/0x1990 security/keys/dh.c:288
>  keyctl_dh_compute+0xac/0xf3 security/keys/dh.c:434
>  SYSC_keyctl security/keys/keyctl.c:1741 [inline]
>  SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1637
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> 
> Freed by task 1637:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kfree+0xd6/0x260 mm/slab.c:3803
>  kernfs_fop_release+0x13f/0x180 fs/kernfs/file.c:783
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x296/0x310 arch/x86/entry/common.c:162
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x94/0x96
> 

The problem is that KEYCTL_DH_COMPUTE allows the user to request and use any
hash algorithm as an unkeyed hash without checking whether it is in fact
unkeyed.

We could fix this by checking for !crypto_shash_alg_has_setkey() after
allocating the hash, but now I'd really like to solve this for all users by
having crypto_[as]hash_init() and crypto_[as]hash_digest() automatically return
-ENOKEY if a key is needed and one hasn't been set.  That would also have solved
the bug I fixed specifically for HMAC by "crypto: hmac - require that the
underlying hash algorithm is unkeyed".

Eric

Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Łukasz Stelmach]

It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
> Łukasz,
>
> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach  
> wrote:
>> Add support for True Random Number Generator found in Samsung Exynos
>> 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach 
>> Reviewed-by: Krzysztof Kozlowski 
>
> 
>
>> --- /dev/null
>> +++ b/drivers/char/hw_random/exynos-trng.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * RNG driver for Exynos TRNGs
>> + *
>> + * Author: Łukasz Stelmach 
>> + *
>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>> + *
>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>> + * Krzysztof Kozłowski 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation;
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>
>
> Would you mind using the new SPDX tags documented in Thomas patch set
> [1] rather than this fine but longer legalese?
>
> And if you could spread the word to others in your team this would be very 
> nice.
> See also this fine article posted by Mauro on the Samsung Open Source
> Group Blog [2]
> Thank you!

Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
more. ;-)

>> +MODULE_LICENSE("GPL");
>
> Per module.h this means GPL2 or later. This is not matching your
> license above which does not state any version and therefore would
> mean GPL1 or later,

Thanks for spotting. My intention is GPL-2.0.

> Please make sure you use something and common rather than this and
> make sure your MODULE_LICENSE is consistent with the top level
> license.
>
> Was it this way in the code from Krzysztof?

Yes. And omap-rng, the second of my sources of reference, too. Actually,
the majority of modules still specify "GPL".

 281 | "Dual */*"
2082 | "GPL v2"
6359 | "GPL"
 +-
8784 | Total

Fixing.

> [1] https://lkml.org/lkml/2017/12/4/934
> [2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/

-- 
Łukasz Stelmach
Samsung R Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

Re: [PATCH] [RFT] crypto: aes-generic - turn off -ftree-pre and -ftree-sra

[Ard Biesheuvel]

On 21 December 2017 at 13:47, PrasannaKumar Muralidharan
 wrote:
> Hi Ard,
>
> On 21 December 2017 at 17:52, Ard Biesheuvel  
> wrote:
>> On 21 December 2017 at 10:20, Arnd Bergmann  wrote:
>>> On Wed, Dec 20, 2017 at 10:46 PM, Jakub Jelinek  wrote:
 On Wed, Dec 20, 2017 at 09:52:05PM +0100, Arnd Bergmann wrote:
> diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
> index ca554d57d01e..35f973ba9878 100644
> --- a/crypto/aes_generic.c
> +++ b/crypto/aes_generic.c
> @@ -1331,6 +1331,20 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
>   f_rl(bo, bi, 3, k); \
>  } while (0)
>
> +#if __GNUC__ >= 7
> +/*
> + * Newer compilers try to optimize integer arithmetic more aggressively,
> + * which generally improves code quality a lot, but in this specific case
> + * ends up hurting more than it helps, in some configurations drastically
> + * so. This turns off two optimization steps that have been shown to
> + * lead to rather badly optimized code with gcc-7.
> + *
> + * See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
> + */
> +#pragma GCC optimize("-fno-tree-pre")
> +#pragma GCC optimize("-fno-tree-sra")

 So do it only when UBSAN is enabled?  GCC doesn't have a particular
 predefined macro for those (only for asan and tsan), but either the kernel
 does have something already, or could have something added in the
 corresponding Makefile.
>>>
>>> My original interpretation of the resulting object code suggested that 
>>> disabling
>>> those two optimizations produced better results for this particular
>>> file even without
>>> UBSAN, on both gcc-7 and gcc-8 (but not gcc-6), so my patch might have
>>> been better, but I did some measurements now as Ard suggested, showing
>>> cycles/byte for AES256/CBC with 8KB blocks:
>>>
>>>
>>>default  ubsan patchedpatched+ubsan
>>> gcc-4.3.614.9   14.9 
>>> gcc-4.6.415.0   15.8 
>>> gcc-4.9.415.520.7   15.9 20.9
>>> gcc-5.5.015.647.3   86.4 48.8
>>> gcc-6.3.114.649.4   94.3 50.9
>>> gcc-7.1.113.554.6   15.2 52.0
>>> gcc-7.2.116.8   124.7   92.0 52.2
>>> gcc-8.0.015.0  no boot  15.3no boot
>>>
>>> I checked that there are actually three significant digits on the 
>>> measurements,
>>> detailed output is available at https://pastebin.com/eFsWYjQp
>>>
>>> It seems that I was wrong about the interpretation that disabling
>>> the optimization would be a win on gcc-7 and higher, it almost
>>> always makes things worse even with UBSAN. Making that
>>> check "#if __GNUC__ == 7 && IS_ENABLED(CONFIG_UBSAN_SANITIZE_ALL)"
>>> would help here, or we could list the file as an exception for
>>> UBSAN and never sanitize it.
>>>
>>> Looking at the 'default' column, I wonder if anyone would be interested
>>> in looking at why the throughput regressed with gcc-7.2 and gcc-8.
>>>
>>
>> Thanks for the elaborate benchmarks. Looking at the bugzilla entry, it
>> appears the UBSAN code inserts runtime checks to ensure that certain
>> u8 variables don't assume values <0 or >255, which seems like a rather
>> pointless exercise to me. But even if it didn't, I think it is
>> justified to disable UBSAN on all of the low-level cipher
>> implementations, given that they are hardly ever modified, and
>> typically don't suffer from the issues UBSAN tries to identify.
>>
>> So my vote is to disable UBSAN for all such cipher implementations:
>> aes_generic, but also aes_ti, which has a similar 256 byte lookup
>> table [although it does not seem to be affected by the same issue as
>> aes_generic], and possibly others as well.
>>
>> Perhaps it makes sense to move core cipher code into a separate
>> sub-directory, and disable UBSAN at the directory level?
>>
>> It would involve the following files
>>
>> crypto/aes_generic.c
>> crypto/aes_ti.c
>> crypto/anubis.c
>> crypto/arc4.c
>> crypto/blowfish_generic.c
>> crypto/camellia_generic.c
>> crypto/cast5_generic.c
>> crypto/cast6_generic.c
>> crypto/des_generic.c
>> crypto/fcrypt.c
>> crypto/khazad.c
>> crypto/seed.c
>> crypto/serpent_generic.c
>> crypto/tea.c
>> crypto/twofish_generic.c
>
> As *SAN is enabled only on developer setup, is such a change required?
> Looks like I am missing something here. Can you explain what value it
> provides?
>

Well, in this particular case, the value it provides is that the
kernel can still boot and invoke the AES code without overflowing the
kernel stack. Of course, this is a compiler issue that hopefully gets
fixed, but I think it may be reasonable to exclude some C code from
UBSAN by default.

Re: [PATCH 00/17] crypto: inside-secure - various improvements

[Antoine Tenart]

Hi Herbert,

On Fri, Dec 22, 2017 at 08:11:54PM +1100, Herbert Xu wrote:
> On Thu, Dec 14, 2017 at 03:26:42PM +0100, Antoine Tenart wrote:
> > 
> > This series depends on the previous one, "crypto: inside-secure - set of
> > fixes"[1]. The series contains various improvements to the Inside Secure
> > SafeXcel driver, which are bundled in a single series to avoid any
> > conflict.
> > 
> > - Patches 1-4 are cosmetic fixes (typo, more comments and dead code 
> > removal).
> > - Patches 5-8 are small improvements, mostly to improve the invalidation
> >   path.
> > - Patches 9-15 improve the request processing in the driver, by moving
> >   the requests dequeing into a workqueue and the result handling into a
> >   threaded IRQ thread. Other small improvements are made in the same
> >   direction.
> > - Patches 16-17 introduce the support of another revision of this crypto
> >   engine, similar to the one already supported. This crypto engine can be
> >   found on Marvell boards. (The corresponding device tree patches will 
> > follow
> >   once this series lands in).
> 
> Patches 1-16 applied.  If patch 17 needs to go through the crypto
> tree please let me know.

Thanks! Yes patch 17 should got through the crypto tree as well.

Thanks,
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Philippe Ombredanne]

Łukasz,

On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach  wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach 
> Reviewed-by: Krzysztof Kozlowski 



> --- /dev/null
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -0,0 +1,245 @@
> +/*
> + * RNG driver for Exynos TRNGs
> + *
> + * Author: Łukasz Stelmach 
> + *
> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
> + *
> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
> + * Krzysztof Kozłowski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation;
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */


Would you mind using the new SPDX tags documented in Thomas patch set
[1] rather than this fine but longer legalese?

And if you could spread the word to others in your team this would be very nice.
See also this fine article posted by Mauro on the Samsung Open Source
Group Blog [2]
Thank you!

> +MODULE_LICENSE("GPL");

Per module.h this means GPL2 or later. This is not matching your
license above which does not state any version and therefore would
mean GPL1 or later,
Please make sure you use something and common rather than this and
make sure your MODULE_LICENSE is consistent with the top level
license.

Was it this way in the code from Krzysztof?


[1] https://lkml.org/lkml/2017/12/4/934
[2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/

--
Cordially
Philippe Ombredanne

[PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Łukasz Stelmach]

Add support for True Random Number Generator found in Samsung Exynos
5250+ SoCs.

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Krzysztof Kozlowski 
---
Changes since v3:

- Fixed typo in the secongd argument of MODULE_DEVICE_TABLE
  (Thanks, Herbert Xu)

 MAINTAINERS  |   7 +
 drivers/char/hw_random/Kconfig   |  12 ++
 drivers/char/hw_random/Makefile  |   1 +
 drivers/char/hw_random/exynos-trng.c | 245 +++
 4 files changed, 265 insertions(+)
 create mode 100644 drivers/char/hw_random/exynos-trng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e6d849d0d153..1082846edb9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11933,6 +11933,13 @@ S: Maintained
 F: drivers/crypto/exynos-rng.c
 F: Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
 
+SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
+M: Łukasz Stelmach 
+L: linux-samsung-...@vger.kernel.org
+S: Maintained
+F: drivers/char/hw_random/exynos-trng.c
+F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
+
 SAMSUNG FRAMEBUFFER DRIVER
 M: Jingoo Han 
 L: linux-fb...@vger.kernel.org
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 90e4bb24819e..32f715394904 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -437,6 +437,18 @@ config HW_RANDOM_S390
 
  If unsure, say Y.
 
+config HW_RANDOM_EXYNOS
+   tristate "Samsung Exynos True Random Number Generator support"
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   default HW_RANDOM
+   ---help---
+ This driver provides support for the True Random Number
+ Generator available in Exynos SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called exynos-trng.
+
+ If unsure, say Y.
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index e7146a84d44a..7c8a66fe8cf6 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
 obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
 n2-rng-y := n2-drv.o n2-asm.o
 obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
+obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-trng.o
 obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
diff --git a/drivers/char/hw_random/exynos-trng.c 
b/drivers/char/hw_random/exynos-trng.c
new file mode 100644
index ..175708f9aa1d
--- /dev/null
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -0,0 +1,245 @@
+/*
+ * RNG driver for Exynos TRNGs
+ *
+ * Author: Łukasz Stelmach 
+ *
+ * Copyright 2017 (c) Samsung Electronics Software, Inc.
+ *
+ * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
+ * Krzysztof Kozłowski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation;
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EXYNOS_TRNG_CLKDIV (0x0)
+
+#define EXYNOS_TRNG_CTRL   (0x20)
+#define EXYNOS_TRNG_CTRL_RNGEN BIT(31)
+
+#define EXYNOS_TRNG_POST_CTRL  (0x30)
+#define EXYNOS_TRNG_ONLINE_CTRL(0x40)
+#define EXYNOS_TRNG_ONLINE_STAT(0x44)
+#define EXYNOS_TRNG_ONLINE_MAXCHI2 (0x48)
+#define EXYNOS_TRNG_FIFO_CTRL  (0x50)
+#define EXYNOS_TRNG_FIFO_0 (0x80)
+#define EXYNOS_TRNG_FIFO_1 (0x84)
+#define EXYNOS_TRNG_FIFO_2 (0x88)
+#define EXYNOS_TRNG_FIFO_3 (0x8c)
+#define EXYNOS_TRNG_FIFO_4 (0x90)
+#define EXYNOS_TRNG_FIFO_5 (0x94)
+#define EXYNOS_TRNG_FIFO_6 (0x98)
+#define EXYNOS_TRNG_FIFO_7 (0x9c)
+#define EXYNOS_TRNG_FIFO_LEN   (8)
+#define EXYNOS_TRNG_CLOCK_RATE (50)
+
+
+struct exynos_trng_dev {
+   struct device*dev;
+   void __iomem *mem;
+   struct clk   *clk;
+   struct hwrng rng;
+};
+
+static int exynos_trng_do_read(struct hwrng *rng, void *data, size_t max,
+  bool wait)
+{
+   struct exynos_trng_dev *trng;
+   u32 val;
+
+   max = min_t(size_t, max, (EXYNOS_TRNG_FIFO_LEN * 4));
+
+   trng = (struct exynos_trng_dev *)rng->priv;
+
+   writel_relaxed(max * 8, trng->mem + EXYNOS_TRNG_FIFO_CTRL);
+   val = readl_poll_timeout(trng->mem + 

Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

[Łukasz Stelmach]

It was <2017-12-22 pią 09:35>, when Herbert Xu wrote:
> On Fri, Dec 22, 2017 at 09:29:38AM +0100, Marek Szyprowski wrote:
>> Hi,
>> 
>> On 2017-12-22 09:24, Herbert Xu wrote:
>> >On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:
>> >>Add support for True Random Number Generator found in Samsung Exynos
>> >>5250+ SoCs.
>> >>
>> >>Signed-off-by: Łukasz Stelmach 
>> >This doesn't build for me:
>> >
>> >   CC [M]  drivers/char/hw_random/exynos-trng.o
>> >../drivers/char/hw_random/exynos-trng.c:230:1: error: 
>> >\u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
>> >../drivers/char/hw_random/exynos-trng.c:230:1: error: 
>> >\u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined 
>> >symbol \u2018exynos_rng_dt_match\u2019
>> >make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
>> >make[1]: *** [_module_drivers/char/hw_random] Error 2
>> 
>> This looks like a missing dependency on "OF" when "COMPILE_TEST" is
>> selected.
>
> Actually it looks like a typo.  The variable is actually called
> exynos_trng_dt_match as opposed to exynos_rng_dt_match.

Indeed. Honestly, I haven't seen this problem, not even once. Right, I
have never compiled it as a module. Thanks for spotting.

-- 
Łukasz Stelmach
Samsung R Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

Re: BUG: unable to handle kernel paging request in hmac_init_tfm

[Dmitry Vyukov]

On Fri, Dec 22, 2017 at 3:27 AM, Eric Biggers  wrote:
> On Thu, Dec 21, 2017 at 08:44:03AM +0100, 'Dmitry Vyukov' via syzkaller-bugs 
> wrote:
>> On Thu, Dec 21, 2017 at 12:09 AM, Eric Biggers  wrote:
>> > On Mon, Dec 18, 2017 at 11:36:01AM -0800, syzbot wrote:
>> >> Hello,
>> >>
>> >> syzkaller hit the following crash on
>> >> 6084b576dca2e898f5c101baef151f7bfdbb606d
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> >> compiler: gcc (GCC) 7.1.1 20170620
>> >> .config is attached
>> >
>> > FYI, in linux-next KASAN and other memory debugging options are now behind
>> > CONFIG_DEBUG_MEMORY.  So, I think KASAN isn't getting turned on anymore, 
>> > despite
>> > the CONFIG_KASAN=y.  (Patch was "lib/: make "Memory Debugging" a 
>> > menuconfig to
>> > ease disabling it all".)
>>
>> Ouch! That would be pretty bad.
>>
>> But I've tried both linux-next HEAD at:
>>
>> commit 0e08c463db387a2adcb0243b15ab868a73f87807 (HEAD, tag:
>> next-20171221, linux-next/master)
>> Author: Stephen Rothwell 
>> Date:   Thu Dec 21 15:37:39 2017 +1100
>> Add linux-next specific files for 20171221
>>
>> and mmots HEAD at:
>>
>> commit 75aa5540627fdb3d8f86229776ea87f995275351 (HEAD, tag:
>> v4.15-rc4-mmots-2017-12-20-19-10, mmots/master)
>> Author: Linus Torvalds 
>> Date:   Thu Dec 21 04:02:17 2017 +
>> pci: test for unexpectedly disabled bridges
>>
>> and after running make olddefconfig I still see CONFIG_KASAN=y in
>> .config, nor I can find CONFIG_DEBUG_MEMORY in menuconfig.
>>
>> What am I missing? What commit has added the config?
>>
>
> Ah, I see the patch was added to -mm on 2017-12-12 but removed two days later:
>
> https://www.spinics.net/lists/mm-commits/msg129685.html
> https://www.spinics.net/lists/mm-commits/msg129696.html
>
> So it was in linux-next temporarily (including the kernel version used for 
> this
> particular bug report) but now it's not.  Just keep an eye out for it coming
> back, I guess.


I see. Then I will add CONFIG_DEBUG_MEMORY=y to our config
proactively. Without that patch olddefconfig will just wipe that
config, so should work.

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

[Corentin Labbe]

On Fri, Dec 22, 2017 at 08:06:03PM +1100, Herbert Xu wrote:
> On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote:
> >
> > It's you that was suggesting using crypto_async_request:
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
> > "The only wart with this scheme is that the drivers end up seeing
> > struct crypto_async_request and will need to convert that to the
> > respective request types but I couldn't really find a better way."
> > 
> > So I wait for any suggestion.
> 
> The core engine code obviously will use the base type but it should
> not be exposed to the driver authors.  IOW all exposed API should
> take the final types such as aead_request before casting it.
> 

For driver->engine 
calls(crypto_finalize_request/crypto_transfer_request_to_engine) it's easy.

But I do not see how to do it for crypto_engine_op appart re-introducing the 
big if/then/else that
you didnt want.
Or do you agree to set the request parameter for 
crypto_engine_op(prepare_request/unprepare_request/do_one_request) to void * ?

Regards

Re: [PATCH v4 0/4] crypto: inside-secure - set of fixes

[Herbert Xu]

On Mon, Dec 11, 2017 at 12:10:54PM +0100, Antoine Tenart wrote:
> Hi Herbert,
> 
> This series is a set of 4 fixes on the Inside Secure SafeXcel crypto
> engine driver. The series will be followed by another non-fix one.
> 
> This is based on v4.15-rc3.

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH crypto] crypto: aesni - add wrapper for generic gcm(aes)

[Herbert Xu]

On Wed, Dec 13, 2017 at 02:54:36PM +0100, Sabrina Dubroca wrote:
> When I added generic-gcm-aes I didn't add a wrapper like the one
> provided for rfc4106(gcm(aes)). We need to add a cryptd wrapper to fall
> back on in case the FPU is not available, otherwise we might corrupt the
> FPU state.
> 
> Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
> Reported-by: Ilya Lesokhin 
> Signed-off-by: Sabrina Dubroca 
> Reviewed-by: Stefano Brivio 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH crypto] crypto: aesni - fix typo in generic_gcmaes_decrypt

[Herbert Xu]

On Wed, Dec 13, 2017 at 02:53:43PM +0100, Sabrina Dubroca wrote:
> generic_gcmaes_decrypt needs to use generic_gcmaes_ctx, not
> aesni_rfc4106_gcm_ctx. This is actually harmless because the fields in
> struct generic_gcmaes_ctx share the layout of the same fields in
> aesni_rfc4106_gcm_ctx.
> 
> Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
> Signed-off-by: Sabrina Dubroca 
> Reviewed-by: Stefano Brivio 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 00/17] crypto: inside-secure - various improvements

[Herbert Xu]

On Thu, Dec 14, 2017 at 03:26:42PM +0100, Antoine Tenart wrote:
> Hi Herbert,
> 
> This series depends on the previous one, "crypto: inside-secure - set of
> fixes"[1]. The series contains various improvements to the Inside Secure
> SafeXcel driver, which are bundled in a single series to avoid any
> conflict.
> 
> - Patches 1-4 are cosmetic fixes (typo, more comments and dead code removal).
> - Patches 5-8 are small improvements, mostly to improve the invalidation
>   path.
> - Patches 9-15 improve the request processing in the driver, by moving
>   the requests dequeing into a workqueue and the result handling into a
>   threaded IRQ thread. Other small improvements are made in the same
>   direction.
> - Patches 16-17 introduce the support of another revision of this crypto
>   engine, similar to the one already supported. This crypto engine can be
>   found on Marvell boards. (The corresponding device tree patches will follow
>   once this series lands in).

Patches 1-16 applied.  If patch 17 needs to go through the crypto
tree please let me know.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] hwrng: Clean up RNG list when last hwrng is unregistered

[Herbert Xu]

On Fri, Dec 15, 2017 at 01:55:59PM -0600, Gary R Hook wrote:
> Commit 142a27f0a731 added support for a "best" RNG, and in doing so
> introduced a hang from rmmod/modprobe -r when the last RNG on the list
> was unloaded.
> 
> When the hwrng list is depleted, return the global variables to their
> original state and decrement all references to the object.
> 
> Fixes: 142a27f0a731 ("hwrng: core - Reset user selected rng by writing "" to 
> rng_current")
> Signed-off-by: Gary R Hook 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 0/4] Assorted changes for Exynos PRNG driver

[Herbert Xu]

On Tue, Dec 12, 2017 at 05:36:03PM +0100, Łukasz Stelmach wrote:
> Hello,
> 
> This is a series of patches for exynos-rng driver I've decided to
> create after adding support for Exynos5250+ chips. They do not
> strictly depend on each other, but I think it is better to send them
> as a single patch-set.
> 
> The driver requires appropriate DT configuration introduced in
> 
> https://patchwork.kernel.org/patch/10106797/
> 
> Patch #1 Add support for PRNG in Exynos5250+ SoCs
> 
> Patch #2 Improve output performance by using memcpy() rather than a
> custom function to retrieve random bytes from registers. Rearrange
> the loop for polling the hardware.
> 
> Patch #3 Reseed the PRNG after reading 2^16 bytes. Simmilar approach
> is implemented in DRBG. (Thanks Stephan Mueller)
> 
> Patch #4 Introduce locking to prevent simultaneous access to the
> hardware from more than one thread/process.
> 
> Changes since v2:

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2/2] crypto: seqiv - Remove unused alg/spawn variable

[Herbert Xu]

On Tue, Dec 12, 2017 at 07:30:14PM +, Corentin Labbe wrote:
> This patch remove two unused variable and some dead "code" using it.
> 
> Fixes: 92932d03c2b3 ("crypto: seqiv - Remove AEAD compatibility code")
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/2] crypto: echainiv - Remove unused alg/spawn variable

[Herbert Xu]

On Tue, Dec 12, 2017 at 07:30:13PM +, Corentin Labbe wrote:
> This patch remove two unused variable and some dead "code" using it.
> 
> Fixes: 66008d4230f6 ("crypto: echainiv - Remove AEAD compatibility code")
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: artpec6: set correct iv size for gcm(aes)

[Herbert Xu]

Lars Persson  wrote:
> The IV size should not include the 32 bit counter. Because we had the
> IV size set as 16 the transform only worked when the IV input was zero
> padded.
> 
> Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator 
> driver")
> Signed-off-by: Lars Persson 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: gf128mul - remove incorrect comment

[Herbert Xu]

On Mon, Dec 11, 2017 at 01:58:26PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> The comment in gf128mul_x8_ble() was copy-and-pasted from gf128mul.h and
> makes no sense in the new context.  Remove it.
> 
> Cc: Harsh Jain 
> Signed-off-by: Eric Biggers 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

[Herbert Xu]

On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote:
>
> It's you that was suggesting using crypto_async_request:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
> "The only wart with this scheme is that the drivers end up seeing
> struct crypto_async_request and will need to convert that to the
> respective request types but I couldn't really find a better way."
> 
> So I wait for any suggestion.

The core engine code obviously will use the base type but it should
not be exposed to the driver authors.  IOW all exposed API should
take the final types such as aead_request before casting it.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: qat - reduce stack size with KASAN

[Herbert Xu]

On Mon, Dec 11, 2017 at 01:07:00PM +0100, Arnd Bergmann wrote:
> Passing the register value by reference here leads a large amount of stack 
> being
> used when CONFIG_KASAN is enabled:
> 
> drivers/crypto/qat/qat_common/qat_hal.c: In function 
> 'qat_hal_exec_micro_inst.constprop':
> drivers/crypto/qat/qat_common/qat_hal.c:963:1: error: the frame size of 1792 
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> 
> Changing the register-read function to return the value instead reduces the 
> stack
> size to around 800 bytes, most of which is for the 'savuwords' array. The 
> function
> now no longer returns an error code, but nothing ever evaluated that anyway.
> 
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: api - Unexport crypto_larval_lookup()

[Herbert Xu]

Eric Biggers  wrote:
> From: Eric Biggers 
> 
> crypto_larval_lookup() is not used outside of crypto/api.c, so unexport
> it and mark it 'static'.
> 
> Signed-off-by: Eric Biggers 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: null - Get rid of crypto_{get,put}_default_null_skcipher2()

[Herbert Xu]

Eric Biggers  wrote:
> From: Eric Biggers 
> 
> Since commit 499a66e6b689 ("crypto: null - Remove default null
> blkcipher"), crypto_get_default_null_skcipher2() and
> crypto_put_default_null_skcipher2() are the same as their non-2
> equivalents.  So switch callers of the "2" versions over to the original
> versions and remove the "2" versions.
> 
> Signed-off-by: Eric Biggers 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

[Corentin Labbe]

On Fri, Dec 22, 2017 at 05:57:24PM +1100, Herbert Xu wrote:
> On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> > The crypto engine could actually only enqueue hash and ablkcipher request.
> > This patch permit it to enqueue any type of crypto_async_request.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> This is going the wrong way.  We do not want to expose any of the
> base types such as crypto_alg, crypto_async_request to end-users
> and that includes drivers.  Only core API code should touch these
> base types.
> 

Hello

It's you that was suggesting using crypto_async_request:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
"The only wart with this scheme is that the drivers end up seeing
struct crypto_async_request and will need to convert that to the
respective request types but I couldn't really find a better way."

So I wait for any suggestion.

Regards
Corentin Labbe

Re: [PATCH] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Herbert Xu]

On Tue, Dec 05, 2017 at 11:31:35PM +, James Hogan wrote:
> From: James Hogan 
> 
> Current MIPS64r6 toolchains aren't able to generate efficient
> DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
> performs an unsigned 64 x 64 bit multiply and returns the upper and
> lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
> inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
> x 128 multiply. This is both inefficient, and it results in a link error
> since we don't include __multi3 in MIPS linux.
> 
> For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
> checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
> 64r6el_defconfig builds by indirectly selecting MPILIB. The same build
> errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:
> 
> lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
> lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
> lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
> lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
> lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
> lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
> lib/mpi/mpih-div.o In function `mpihelp_divrem':
> lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
> lib/mpi/mpih-div.c:142: undefined reference to `__multi3'
> 
> Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
> inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
> calls being emitted.
> 
> Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
> Signed-off-by: James Hogan 
> Cc: Ralf Baechle 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: linux-m...@linux-mips.org
> Cc: linux-crypto@vger.kernel.org

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: exynos - Icrease the priority of the driver

[Herbert Xu]

On Tue, Dec 05, 2017 at 05:20:46PM +0100, Łukasz Stelmach wrote:
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available. The value 300 was selected to give the PRNG priority before
> software implementations, but allow them to be selected in FIPS-mode
> (fips=1 in the kernel command line).
> 
> Signed-off-by: Łukasz Stelmach 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 02/45] drivers: crypto: remove duplicate includes

[Herbert Xu]

On Tue, Dec 05, 2017 at 07:27:22AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [crypto] chcr: fix a type cast error

[Herbert Xu]

Atul Gupta  wrote:
> fix a type cast error for queue descriptor
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Atul Gupta 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: pcrypt - fix freeing pcrypt instances

[Herbert Xu]

On Wed, Dec 20, 2017 at 02:28:25PM -0800, Eric Biggers wrote:
> From: Eric Biggers 
> 
> pcrypt is using the old way of freeing instances, where the ->free()
> method specified in the 'struct crypto_template' is passed a pointer to
> the 'struct crypto_instance'.  But the crypto_instance is being
> kfree()'d directly, which is incorrect because the memory was actually
> allocated as an aead_instance, which contains the crypto_instance at a
> nonzero offset.  Thus, the wrong pointer was being kfree()'d.
> 
> Fix it by switching to the new way to free aead_instance's where the
> ->free() method is specified in the aead_instance itself.
> 
> Reported-by: syzbot 
> Fixes: 0496f56065e0 ("crypto: pcrypt - Add support for new AEAD interface")
> Cc:  # v4.2+
> Signed-off-by: Eric Biggers 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: n2 - cure use after free

[Herbert Xu]

Jan Engelhardt  wrote:
> queue_cache_init is first called for the Control Word Queue
> (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new
> kmem_cache will be allocated. If the subsequent n2_register_algs call
> fails, the kmem_cache will be released in queue_cache_destroy, but
> queue_cache_init[0] is not set back to NULL.
> 
> So when the Module Arithmetic Unit gets probed next (n2_mau_probe),
> queue_cache_init will not allocate a kmem_cache again, but leave it
> as its bogus value, causing a BUG() to trigger when queue_cache[0] is
> eventually passed to kmem_cache_zalloc:
> 
>n2_crypto: Found N2CP at /virtual-devices@100/n2cp@7
>n2_crypto: Registered NCS HVAPI version 2.0
>called queue_cache_init
>n2_crypto: md5 alg registration failed
>n2cp f028687c: /virtual-devices@100/n2cp@7: Unable to register 
> algorithms.
>called queue_cache_destroy
>n2cp: probe of f028687c failed with error -22
>n2_crypto: Found NCP at /virtual-devices@100/ncp@6
>n2_crypto: Registered NCS HVAPI version 2.0
>called queue_cache_init
>kernel BUG at mm/slab.c:2993!
>Call Trace:
> [00604488] kmem_cache_alloc+0x1a8/0x1e0
>  (inlined) kmem_cache_zalloc
>  (inlined) new_queue
>  (inlined) spu_queue_setup
>  (inlined) handle_exec_unit
> [10c61eb4] spu_mdesc_scan+0x1f4/0x460 [n2_crypto]
> [10c62b80] n2_mau_probe+0x100/0x220 [n2_crypto]
> [0084b174] platform_drv_probe+0x34/0xc0
> 
> Signed-off-by: Jan Engelhardt 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

[Herbert Xu]

On Fri, Dec 22, 2017 at 09:29:38AM +0100, Marek Szyprowski wrote:
> Hi,
> 
> On 2017-12-22 09:24, Herbert Xu wrote:
> >On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:
> >>Add support for True Random Number Generator found in Samsung Exynos
> >>5250+ SoCs.
> >>
> >>Signed-off-by: Łukasz Stelmach 
> >This doesn't build for me:
> >
> >   CC [M]  drivers/char/hw_random/exynos-trng.o
> >../drivers/char/hw_random/exynos-trng.c:230:1: error: 
> >\u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
> >../drivers/char/hw_random/exynos-trng.c:230:1: error: 
> >\u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined 
> >symbol \u2018exynos_rng_dt_match\u2019
> >make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
> >make[1]: *** [_module_drivers/char/hw_random] Error 2
> 
> This looks like a missing dependency on "OF" when "COMPILE_TEST" is
> selected.

Actually it looks like a typo.  The variable is actually called
exynos_trng_dt_match as opposed to exynos_rng_dt_match.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: chcr: select CRYPTO_GF128MUL

[Herbert Xu]

On Tue, Dec 05, 2017 at 11:10:26AM +0100, Arnd Bergmann wrote:
> Without the gf128mul library support, we can run into a link
> error:
> 
> drivers/crypto/chelsio/chcr_algo.o: In function `chcr_update_tweak':
> chcr_algo.c:(.text+0x7e0): undefined reference to `gf128mul_x8_ble'
> 
> This adds a Kconfig select statement for it, next to the ones we
> already have.
> 
> Fixes: b8fd1f4170e7 ("crypto: chcr - Add ctr mode and process large sg 
> entries for cipher")
> Signed-off-by: Arnd Bergmann 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

[Marek Szyprowski]

Hi,

On 2017-12-22 09:24, Herbert Xu wrote:

On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:

Add support for True Random Number Generator found in Samsung Exynos
5250+ SoCs.

Signed-off-by: Łukasz Stelmach 

This doesn't build for me:

   CC [M]  drivers/char/hw_random/exynos-trng.o
../drivers/char/hw_random/exynos-trng.c:230:1: error: 
\u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
../drivers/char/hw_random/exynos-trng.c:230:1: error: 
\u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined 
symbol \u2018exynos_rng_dt_match\u2019
make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
make[1]: *** [_module_drivers/char/hw_random] Error 2


This looks like a missing dependency on "OF" when "COMPILE_TEST" is 
selected.


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Herbert Xu]

On Fri, Dec 22, 2017 at 08:59:21AM +0100, Ralf Baechle wrote:
> On Fri, Dec 22, 2017 at 06:08:08PM +1100, Herbert Xu wrote:
> 
> > I can take this but I'd like to see an ack from someone on the
> > MIPS side.
> 
> Sure:
> 
> Acked-by: Ralf Baechle 

Thanks Ralf!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: stm32 - Use standard CONFIG name

[Fabien DESSENNE]

Hi Corentin


Thank you for the patch.


On 20/12/17 19:19, Corentin Labbe wrote:
> All hardware crypto devices have their CONFIG names using the following
> convention:
> CRYPTO_DEV_name_algo
>
> This patch apply this conventions on STM32 CONFIG names.
>
> Signed-off-by: Corentin Labbe 
Reviewed-by: Fabien Dessenne 
> ---
>   drivers/crypto/stm32/Kconfig  | 6 +++---
>   drivers/crypto/stm32/Makefile | 6 +++---
>   2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> index 61ef00b6bf45..63aa78c0b12b 100644
> --- a/drivers/crypto/stm32/Kconfig
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -1,4 +1,4 @@
> -config CRC_DEV_STM32
> +config CRYPTO_DEV_STM32_CRC
>   tristate "Support for STM32 crc accelerators"
>   depends on ARCH_STM32
>   select CRYPTO_HASH
> @@ -6,7 +6,7 @@ config CRC_DEV_STM32
> This enables support for the CRC32 hw accelerator which can be 
> found
> on STMicroelectronics STM32 SOC.
>   
> -config HASH_DEV_STM32
> +config CRYPTO_DEV_STM32_HASH
>   tristate "Support for STM32 hash accelerators"
>   depends on ARCH_STM32
>   depends on HAS_DMA
> @@ -19,7 +19,7 @@ config HASH_DEV_STM32
> This enables support for the HASH hw accelerator which can be 
> found
> on STMicroelectronics STM32 SOC.
>   
> -config CRYP_DEV_STM32
> +config CRYPTO_DEV_STM32_CRYP
>   tristate "Support for STM32 cryp accelerators"
>   depends on ARCH_STM32
>   select CRYPTO_HASH
> diff --git a/drivers/crypto/stm32/Makefile b/drivers/crypto/stm32/Makefile
> index 2c19fc155bfd..53d1bb94b221 100644
> --- a/drivers/crypto/stm32/Makefile
> +++ b/drivers/crypto/stm32/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_CRC_DEV_STM32) += stm32_crc32.o
> -obj-$(CONFIG_HASH_DEV_STM32) += stm32-hash.o
> -obj-$(CONFIG_CRYP_DEV_STM32) += stm32-cryp.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRC) += stm32_crc32.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_HASH) += stm32-hash.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRYP) += stm32-cryp.o

Re: [PATCH] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Ralf Baechle]

On Fri, Dec 22, 2017 at 06:08:08PM +1100, Herbert Xu wrote:

> I can take this but I'd like to see an ack from someone on the
> MIPS side.

Sure:

Acked-by: Ralf Baechle 

  Ralf