* [PATCH 9/9] arm64: dts: marvell: add TRNG description for Armada 8K CP
From: Romain Perier @ 2016-09-06 15:38 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160906153857.5503-1-romain.perier@free-electrons.com>
This commits adds the devicetree description of the SafeXcel IP-76 TRNG
found in the two Armada CP110.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8 ++++++++
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 ++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index da31bbb..aaffa24 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -164,6 +164,14 @@
clocks = <&cpm_syscon0 1 21>;
status = "disabled";
};
+
+ cpm_trng: trng@760000 {
+ compatible = "marvell,armada-8k-rng", "inside-secure,safexcel-eip76";
+ reg = <0x760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+ status = "okay";
+ };
};
cpm_pcie0: pcie@f2600000 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6ff1201..216de12 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -164,6 +164,14 @@
clocks = <&cps_syscon0 1 21>;
status = "disabled";
};
+
+ cps_trng: trng@760000 {
+ compatible = "marvell,armada-8k-rng", "inside-secure,safexcel-eip76";
+ reg = <0x760000 0x7d>;
+ interrupts = <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cps_syscon0 1 25>;
+ status = "okay";
+ };
};
cps_pcie0: pcie@f4600000 {
--
2.9.3
^ permalink raw reply related
* Re: echainiv not working as supposed to be?
From: Herbert Xu @ 2016-09-06 16:08 UTC (permalink / raw)
To: Mathias Krause; +Cc: Steffen Klassert, linux-crypto@vger.kernel.org
In-Reply-To: <CA+rthh9_=PsJgZDtfoHQsaFZ2fH2hz4w_sbhn8fnx7a3LOatXQ@mail.gmail.com>
On Tue, Sep 06, 2016 at 02:24:59PM +0200, Mathias Krause wrote:
>
> For each request it XORs the salt into the provided IV (req->iv). For
> ESP the provided IV is the sequence number or, at least, parts of it.
> The thus modified IV gets written into the *destination* buffer
> (req->dst) which might be a different buffer than the source buffer
> (not in the ESP case, though, as it passes the same sg for src and
> dst). Afterwards, the per-cpu IV gets copied over into req->iv,
> effectively overwriting the generated XORed value. Then the inner
> crypto request gets initiated which may finish synchronously or
> asynchronously. Either way, the per-cpu IV gets updated with the new
> value from subreq->iv, which should be equal to req->iv in the normal
> case.
I think your description is basically correct. However, you seem
to be missing the fact that the real IV (i.e., the IV transmitted
over the wire) is the first block of the encrypted ciphertext.
IOW the per-cpu IV is never sent over the wire. It's only used
to encrypt the first block of the ciphertext, which becomes the
actual IV.
> So, should echainiv use a per-context per-cpu array instead that --
> for simplicity -- gets initialised with random bytes and will be
> updated as it's now, just not with a single global per-cpu array, but
> a per-context one?
As I said, the per-cpu IV is never seen by anyone so there is no
need to make it per-tfm.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: PrasannaKumar Muralidharan @ 2016-09-06 16:31 UTC (permalink / raw)
To: Romain Perier
Cc: dsaxena, mpm, Herbert Xu, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas,
linux-crypto
In-Reply-To: <20160906153857.5503-5-romain.perier@free-electrons.com>
> Use devm_hwrng_register instead of hwrng_register. It avoids the need
> to handle unregistration explicitly from the remove function.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> drivers/char/hw_random/omap-rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
> index d47b24d..171c3e8 100644
> --- a/drivers/char/hw_random/omap-rng.c
> +++ b/drivers/char/hw_random/omap-rng.c
> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device *pdev)
> if (ret)
> goto err_ioremap;
>
> - ret = hwrng_register(&omap_rng_ops);
> + ret = devm_hwrng_register(dev, &omap_rng_ops);
> if (ret)
> goto err_register;
>
> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device *pdev)
> {
> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>
> - hwrng_unregister(&omap_rng_ops);
> -
> priv->pdata->cleanup(priv);
>
> pm_runtime_put_sync(&pdev->dev);
> --
If devm_hwrng_register is used hwrng_unregister will be called after
pm_runtime_disable is called. If RNG device is in use calling
omap_rng_remove may not work properly.
^ permalink raw reply
* [PATCH 13/21] padata: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2016-09-06 17:04 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, rt, tglx, Sebastian Andrzej Siewior,
Steffen Klassert, linux-crypto
In-Reply-To: <20160906170457.32393-1-bigeasy@linutronix.de>
Install the callbacks via the state machine. CPU-hotplug multinstance support
is used with the nocalls() version. Maybe parts of padata_alloc() could be
moved into the online callback so that we could invoke ->startup callback for
instance and drop get_online_cpus().
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
include/linux/padata.h | 2 +-
kernel/padata.c | 92 ++++++++++++++++++++++++++++----------------------
2 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/include/linux/padata.h b/include/linux/padata.h
index 113ee626a4dc..0f9e567d5e15 100644
--- a/include/linux/padata.h
+++ b/include/linux/padata.h
@@ -151,7 +151,7 @@ struct parallel_data {
* @flags: padata flags.
*/
struct padata_instance {
- struct notifier_block cpu_notifier;
+ struct hlist_node node;
struct workqueue_struct *wq;
struct parallel_data *pd;
struct padata_cpumask cpumask;
diff --git a/kernel/padata.c b/kernel/padata.c
index 993278895ccc..7848f0566403 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -30,6 +30,7 @@
#include <linux/slab.h>
#include <linux/sysfs.h>
#include <linux/rcupdate.h>
+#include <linux/module.h>
#define MAX_OBJ_NUM 1000
@@ -769,52 +770,43 @@ static inline int pinst_has_cpu(struct padata_instance *pinst, int cpu)
cpumask_test_cpu(cpu, pinst->cpumask.cbcpu);
}
-
-static int padata_cpu_callback(struct notifier_block *nfb,
- unsigned long action, void *hcpu)
+static int padata_cpu_online(unsigned int cpu, struct hlist_node *node)
{
- int err;
struct padata_instance *pinst;
- int cpu = (unsigned long)hcpu;
+ int ret;
- pinst = container_of(nfb, struct padata_instance, cpu_notifier);
+ pinst = hlist_entry_safe(node, struct padata_instance, node);
+ if (!pinst_has_cpu(pinst, cpu))
+ return 0;
- switch (action) {
- case CPU_ONLINE:
- case CPU_ONLINE_FROZEN:
- case CPU_DOWN_FAILED:
- case CPU_DOWN_FAILED_FROZEN:
- if (!pinst_has_cpu(pinst, cpu))
- break;
- mutex_lock(&pinst->lock);
- err = __padata_add_cpu(pinst, cpu);
- mutex_unlock(&pinst->lock);
- if (err)
- return notifier_from_errno(err);
- break;
-
- case CPU_DOWN_PREPARE:
- case CPU_DOWN_PREPARE_FROZEN:
- case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
- if (!pinst_has_cpu(pinst, cpu))
- break;
- mutex_lock(&pinst->lock);
- err = __padata_remove_cpu(pinst, cpu);
- mutex_unlock(&pinst->lock);
- if (err)
- return notifier_from_errno(err);
- break;
- }
-
- return NOTIFY_OK;
+ mutex_lock(&pinst->lock);
+ ret = __padata_add_cpu(pinst, cpu);
+ mutex_unlock(&pinst->lock);
+ return ret;
}
+
+static int padata_cpu_prep_down(unsigned int cpu, struct hlist_node *node)
+{
+ struct padata_instance *pinst;
+ int ret;
+
+ pinst = hlist_entry_safe(node, struct padata_instance, node);
+ if (!pinst_has_cpu(pinst, cpu))
+ return 0;
+
+ mutex_lock(&pinst->lock);
+ ret = __padata_remove_cpu(pinst, cpu);
+ mutex_unlock(&pinst->lock);
+ return ret;
+}
+
+static enum cpuhp_state hp_online;
#endif
static void __padata_free(struct padata_instance *pinst)
{
#ifdef CONFIG_HOTPLUG_CPU
- unregister_hotcpu_notifier(&pinst->cpu_notifier);
+ cpuhp_state_remove_instance_nocalls(hp_online, &pinst->node);
#endif
padata_stop(pinst);
@@ -1012,11 +1004,8 @@ struct padata_instance *padata_alloc(struct workqueue_struct *wq,
mutex_init(&pinst->lock);
#ifdef CONFIG_HOTPLUG_CPU
- pinst->cpu_notifier.notifier_call = padata_cpu_callback;
- pinst->cpu_notifier.priority = 0;
- register_hotcpu_notifier(&pinst->cpu_notifier);
+ cpuhp_state_add_instance_nocalls(hp_online, &pinst->node);
#endif
-
return pinst;
err_free_masks:
@@ -1039,3 +1028,26 @@ void padata_free(struct padata_instance *pinst)
kobject_put(&pinst->kobj);
}
EXPORT_SYMBOL(padata_free);
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+static __init int padata_driver_init(void)
+{
+ int ret;
+
+ ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "padata:online",
+ padata_cpu_online,
+ padata_cpu_prep_down);
+ if (ret < 0)
+ return ret;
+ hp_online = ret;
+ return 0;
+}
+module_init(padata_driver_init);
+
+static __exit void padata_driver_exit(void)
+{
+ cpuhp_remove_multi_state(hp_online);
+}
+module_exit(padata_driver_exit);
+#endif
--
2.9.3
^ permalink raw reply related
* linux 3.10 crash with crypto hardware assist,
From: Hsieh, Che-Min @ 2016-09-06 19:13 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org; +Cc: Herbert Xu, Bronstein, Dan
Has anyone seen the following problem on Linux 3.10, or later Linux?
If it is fixed, can anyone point out where the fix is?
Thanks.
Chemin
We are running Android, based on Linux3.10.
With our crypto hardware accelerator, and driver, algorithm of "authenc(hmac(sha1),cbc(aes))" is running well.
With our hardware accelerator and algorithm of "rfc4309(ccm(aes))", it is running fine too.
We start testing extended sequence number recently.
ip xfrm state is set with flag esn and replay-window 256.
System crashes shortly, after the first couple of packet transmits.
We try to run the same test with flag esn and replay-window 256 with algorithm of "rfc4309(ccm(aes))", it still runs fine with hardware accelerator.
We go back to the same algorithm of "authenc(hmac(sha1),cbc(aes))" but without hardware accelerator. This time, it runs fine.
The crypto hardware driver is agnostic to esn. Without esn, it is running fine. So it is less likely driver is at fault.
When it crashes, the stack dump looks like the following
# ping 10.2.242.93 -I 192.168.2.10
PING 10.2.242.93 (10.2.242.93) from 192.168.2.10: 56 data byt 329.068077] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 329.079579] pgd = c0004000
[ 329.082277] [00000008] *pgd=00000000
[ 329.085844] Internal error: Oops: 5 [#1] PREEMPT SMP THUMB2
[ 329.091390] Modules linked in: ota_crypto ath_pktlog(PO) umac(O) ath_dev(PO) ath_dfs(PO) ath_rate_atheros(PO) ath_hal(PO) adf(PO) asf(PO) evbug
[ 329.104228] CPU: 3 PID: 247 Comm: kworker/3:1H Tainted: P O 3.10.84-perf-gbc40dee-35160-g0d54083 #1
[ 329.114126] Workqueue: qcrypto_seq_response_wq seq_response
[ 329.119678] task: c94fd080 ti: c97be000 task.ti: c97be000
[ 329.125062] PC is at scatterwalk_map_and_copy+0x1e/0x98
[ 329.130272] LR is at authenc_esn_geniv_ahash_done+0x29/0x3c
[ 329.135824] pc : [<c02cd432>] lr : [<c02df0fd>] psr: 20000033
[ 329.135824] sp : c97bfe98 ip : 00000000 fp : c0c189e4
[ 329.147282] r10: c91585ac r9 : c9158564 r8 : c0b163c8
[ 329.152490] r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 271ae748
[ 329.158999] r3 : c0b6155c r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 329.165510] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel
[ 329.172977] Control: 50c5787d Table: 1267c06a DAC: 00000015
[ 329.178706]
[ 329.178706] PC: 0xc02cd3b2:
[ 329.182958] d3b0 f3c243e2 3201020b 1b2c441d bf284294 42b44614 4634bf28 ff5ef7ff 46394605
[ 329.191117] d3d0 0f00f1b8 4629d101 46224638 f02a4427 4628fadf fb62f645 5004f8d9 464842a6
[ 329.199277] d3f0 f04f4641 eba60201 44250604 5004f8c9 e9ddd1cd e9dd3400 e9dd5602 b0067804
[ 329.207436] d410 8200e8bd 4506e96d 8e04e9cd 38c8f246 08b1f2cc 6702e9cd f8d8b084 94034000
[ 329.215596] d430 688cb33b 91012600 b17446b6 1935684f 970242aa 680cd310 d40807a4 b32c698c
[ 329.223756] d450 462e3110 2c009101 f7ffd1f0 f8deff27 21004008 e7f5462e a9014417 461a1bbe
[ 329.231915] d470 96029b0a ff86f7ff 990aa801 f7ff2200 9a03ff5d 3000f8d8 d10d429a e9ddb004
[ 329.240075] d490 e9dd4500 b0046702 8100e8bd 462e6909 0103f021 e7d5688c ffacf661 f2474608
[ 329.248236] d4b0 f2cc21d8 f72b0172 bf00b85b 4504e96d f24f460c f1040120 f2cc0228 e9cd0189
[ 329.256397]
[ 329.256397] LR: 0xc02df07d:
[ 329.260650] f07c e7cf0149 ebc96cb2 46500308 e9d46961 6ae56702 65a36992 6aa36561 64e76a21
[ 329.268809] f09c 652264a6 e9c46665 68d31317 46014798 bf00e7b5 4e02e96d f5004604 f7ed708c
[ 329.276968] f0bc f504fa6b f7ed7080 4620fa67 4e00e9dd f6fdb002 bf00bea1 4504e96d e9cd460d
[ 329.285127] f0dc 68c46e02 6923b082 b9496c1a 44222601 f8d26a1b 6ce100cc 96006c22 f98cf7ee
[ 329.293287] f0fc 462968a3 b0024620 4500e9dd 6e02e9dd 4718b004 3406e96d 5602e9cd 4606460d
[ 329.301448] f11c 7e04e9cd e9d26902 6eda4310 f1034404 34ac0140 69d74620 681b6121 b1284798
[ 329.309608] f13c 3400e9dd 5602e9dd bd80b004 01acf106 f1066c72 eb010350 46200147 692361e3
[ 329.317768] f15c 0707ea21 622761a2 f8d66972 60e610a4 60a1402a f8536162 47983c3c d1df2800
[ 329.325927] f17c 46206cf1 62276c33 e9c46922 69733106 10a8f8d6 402b60e6 616360a1 3c3cf852
[ 329.334086]
[ 329.334086] SP: 0xc97bfe18:
[ 329.338340] fe18 00000001 c0b2cf80 c1b9f4c0 c0b2cf80 60000013 271ae748 c02cd432 20000033
[ 329.346500] fe38 ffffffff c97bfe84 c0b163c8 c9158564 c91585ac c06172f5 00000000 00000000
[ 329.354658] fe58 00000000 c0b6155c 271ae748 00000000 00000001 00000000 c0b163c8 c9158564
[ 329.362819] fe78 c91585ac c0c189e4 00000000 c97bfe98 c02df0fd c02cd432 20000033 ffffffff
[ 329.370978] fe98 c9158564 00008b43 00000001 271ae748 cab26540 00000000 00000001 00000000
[ 329.379139] feb8 c0c18950 c02df0fd 00000001 c02d087f c0c189fc 00000001 00000000 c03bc4c7
[ 329.387299] fed8 c0c189ec c0c189e0 c1ba1540 c0c189ec c97b4e80 c0b6ada0 c1ba1540 c1ba6800
[ 329.395458] fef8 00000001 c1ba1540 c97be008 c01458ab c97bff20 00000000 00000000 00000000
[ 329.403619]
[ 329.403619] FP: 0xc0c18964:
[ 329.407871] 8964 01000000 01010001 00010001 00000000 00000000 00000002 00000007 00000008
[ 329.416031] 8984 00530053 cbd5b000 cb6d6800 00000000 00000000 00000000 00000000 00000000
[ 329.424191] 89a4 cb6ab300 cb6ab600 00000003 00000001 00000000 c0c189b8 c0c189b8 00000000
[ 329.432350] 89c4 00000000 cb6ab600 c0c189cc c0c189cc c0c189cc 00000000 00000300 00000000
[ 329.440510] 89e4 00000001 cb6c0f00 000000e0 c0c189f0 c0c189f0 c03bc449 00000001 00000001
[ 329.448670] 8a04 00000003 cb6ab300 cb6ab500 00000000 00000000 00000000 00000001 00000007
[ 329.456829] 8a24 0000000d 00000000 00000002 00000001 00000000 00000000 00000004 00000002
[ 329.464989] 8a44 00000000 00000000 00000000 00000000 0000000e 00000001 cb9f8a18 00000000
[ 329.473150]
[ 329.473150] R3: 0xc0b614dc:
[ 329.477403] 14dc c0b61514 c0562ad1 c0562c2d 00000000 c0b6150c c0b6149c 00000002 0000000b
[ 329.485561] 14fc c0b61514 c0562d39 00000000 00000000 c0b6149c c0b614ec 00000000 00000003
[ 329.493722] 151c 0010000b 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 329.501881] 153c 00000000 c0b61180 c0b61fc8 c0563e95 c0563dad 00000000 00000000 00000000
[ 329.510042] 155c c0563d3d c0563541 c05656d9 00000000 c0563ec5 c0563bd9 c0563d1d 00000000
[ 329.518201] 157c c0564009 c0563f59 c05640ad c0563bf5 00000000 c0563b59 c0563b1d c0563779
[ 329.526361] 159c c05639e5 c0563a45 00000000 00000000 00000000 00000003 00000000 00000000
[ 329.534521] 15bc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 cbc01780
[ 329.542681]
[ 329.542681] R8: 0xc0b16348:
[ 329.546934] 6348 c41ad32f 0ec67274 cfcdd6f2 051177a9 5b749545 91a8341e 6e7e1c4c a4a2bd17
[ 329.555093] 6368 fac75ffb 301bfea0 f1105a26 3bccfb7d 65a91991 af75b8ca 9b044835 51d8e96e
[ 329.563253] 6388 0fbd0b82 c561aad9 046a0e5f ceb6af04 90d34de8 5a0fecb3 a5d9c4e1 6f0565ba
[ 329.571413] 63a8 31608756 fbbc260d 3ab7828b f06b23d0 ae0ec13c 64d26067 00000000 00000001
[ 329.579572] 63c8 271ae748 002fb0d7 00000009 c0113069 c0113031 00000022 ffffffff 00000000
[ 329.587732] 63e8 00000000 00000000 00000000 0000000f 0000000f 0000000f 0000000f 00000000
[ 329.595892] 6408 cbc3b900 cbc3b9c0 cbc3ba80 cbc26300 cbc3bb40 00000001 00000000 0000263b
[ 329.604051] 6428 000003e8 00000001 00000001 0000006e 00000020 00000001 00000000 0007a120
[ 329.612211]
[ 329.612211] R9: 0xc91584e4:
[ 329.616464] 84e4 00000028 00000004 00000000 c0d72b02 00000400 00000004 00000000 c0d7e762
[ 329.624624] 8504 0000002c 0000007c 1173b02c 00000002 00000000 00000000 00000000 c02df0d5
[ 329.632784] 8524 c02dfb11 c02dfa91 f50339d1 cff361ff 12a93443 655f0e57 05cf5684 c0d7e762
[ 329.640943] 8544 0000002c 0000007c 1173b02c 00000002 00000000 00000000 00000000 00000000
[ 329.649103] 8564 00100100 00200200 c02d0869 c9158564 ca4a2040 00000000 00000004 c91584f0
[ 329.657264] 8584 caf6b740 caf6b700 00000000 00000000 00000000 00000000 00000000 00000000
[ 329.665423] 85a4 00100100 00200200 00000000 c9158564 00000000 cb6ab500 c91584f0 00000004
[ 329.673582] 85c4 00200200 c02dfbb9 c9158480 ca4a2e00 00000000 00000070 c9158404 00000054
[ 329.681743]
[ 329.681743] R10: 0xc915852c:
[ 329.686083] 852c f50339d1 cff361ff 12a93443 655f0e57 05cf5684 c0d7e762 0000002c 0000007c
[ 329.694242] 854c 1173b02c 00000002 00000000 00000000 00000000 00000000 00100100 00200200
[ 329.702402] 856c c02d0869 c9158564 ca4a2040 00000000 00000004 c91584f0 caf6b740 caf6b700
[ 329.710561] 858c 00000000 00000000 00000000 00000000 00000000 00000000 00100100 00200200
[ 329.718721] 85ac 00000000 c9158564 00000000 cb6ab500 c91584f0 00000004 00200200 c02dfbb9
[ 329.726882] 85cc c9158480 ca4a2e00 00000000 00000070 c9158404 00000054 00000000 c03bace3
[ 329.735040] 85ec 00000000 00000000 0000007c 00000000 0a330000 799f27c1 1fc4c9ce b981ee60
[ 329.743200] 860c df442c11 81453d07 4ade9fdd 2be94b5c 8c2259c8 a6814796 8fde90c1 0e958c2f
[ 329.751363] Process kworker/3:1H (pid: 247, stack limit = 0xc97be238)
[ 329.757785] Stack: (0xc97bfe98 to 0xc97c0000)
[ 329.762125] fe80: c9158564 00008b43
[ 329.770286] fea0: 00000001 271ae748 cab26540 00000000 00000001 00000000 c0c18950 c02df0fd
[ 329.778446] fec0: 00000001 c02d087f c0c189fc 00000001 00000000 c03bc4c7 c0c189ec c0c189e0
[ 329.786607] fee0: c1ba1540 c0c189ec c97b4e80 c0b6ada0 c1ba1540 c1ba6800 00000001 c1ba1540
[ 329.794765] ff00: c97be008 c01458ab c97bff20 00000000 00000000 00000000 00000001 c97b4e80
[ 329.802926] ff20: c1ba1540 c97b4e98 c1ba1554 c97be000 c0b6a9ad c1ba1540 00000000 c0146313
[ 329.811085] ff40: 00000000 cbcb5e84 cbcb5e84 c97bff84 c97b4e80 c0146231 00000000 00000000
[ 329.819244] ff60: 00000000 c014a6f5 00000000 e7fddef0 c97b4e80 00000000 00000000 c97bff7c
[ 329.827406] ff80: c97bff7c 00000000 00000000 c97bff8c c97bff8c 271ae748 00000000 cbcb5e84
[ 329.835564] ffa0: c014a65d 00000000 00000000 c01059e1 00000000 00000000 00000000 00000000
[ 329.843723] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 329.851884] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 e7fddef0 e7fddef0
[ 329.860049] [<c02cd432>] (scatterwalk_map_and_copy+0x1e/0x98) from [<c02df0fd>] (authenc_esn_geniv_ahash_done+0x29/0x3c)
[ 329.870897] [<c02df0fd>] (authenc_esn_geniv_ahash_done+0x29/0x3c) from [<c03bc4c7>] (seq_response+0x7f/0x174)
[ 329.880795] [<c03bc4c7>] (seq_response+0x7f/0x174) from [<c01458ab>] (process_one_work+0xcf/0x324)
[ 329.889736] [<c01458ab>] (process_one_work+0xcf/0x324) from [<c0146313>] (worker_thread+0xe3/0x2d8)
[ 329.898763] [<c0146313>] (worker_thread+0xe3/0x2d8) from [<c014a6f5>] (kthread+0x99/0x9c)
[ 329.906924] [<c014a6f5>] (kthread+0x99/0x9c) from [<c01059e1>] (ret_from_fork+0x11/0x30)
[ 329.914992] Code: f8d8 4000 9403 b33b (688c) 2600
[ 329.919785] ---[ end trace b69ab7f7a6c9c9b9 ]---
[ 329.924366] Kernel panic - not syncing: Fatal exception in interrupt
[ 329.930717] CPU2: stopping
[ 329.933414] CPU: 2 PID: 0 Comm: swapper/2 Tainted: P D O 3.10.84-perf-gbc40dee-35160-g0d54083 #1
[ 329.942906] [<c010b7a1>] (unwind_backtrace+0x1/0xf8) from [<c0108dc5>] (show_stack+0xd/0x10)
[ 329.951312] [<c0108dc5>] (show_stack+0xd/0x10) from [<c010ad19>] (handle_IPI+0x151/0x168)
[ 329.959463] [<c010ad19>] (handle_IPI+0x151/0x168) from [<c0100425>] (gic_handle_irq+0x5d/0x60)
[ 329.968064] [<c0100425>] (gic_handle_irq+0x5d/0x60) from [<c061735b>] (__irq_svc+0x3b/0x80)
[ 329.976373] Exception stack(0xcbc8bf78 to 0xcbc8bfc0)
[ 329.981410] bf60: ffffffed 01088000
[ 329.989577] bf80: 00000000 c045e5d9 c0b16458 cbc8a000 c0b17180 c0b6b250 cbc8a008 c0b0a400
[ 329.997737] bfa0: cbc8a008 00000000 000000b2 cbc8bfc0 c0106535 c0106536 60070033 ffffffff
[ 330.005914] [<c061735b>] (__irq_svc+0x3b/0x80) from [<c0106536>] (arch_cpu_idle+0x1e/0x28)
[ 330.014160] [<c0106536>] (arch_cpu_idle+0x1e/0x28) from [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c)
[ 330.023267] [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c) from [<0860f365>] (0x860f365)
[ 330.031148] CPU0: stopping
[ 330.033854] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P D O 3.10.84-perf-gbc40dee-35160-g0d54083 #1
[ 330.043347] [<c010b7a1>] (unwind_backtrace+0x1/0xf8) from [<c0108dc5>] (show_stack+0xd/0x10)
[ 330.051747] [<c0108dc5>] (show_stack+0xd/0x10) from [<c010ad19>] (handle_IPI+0x151/0x168)
[ 330.059897] [<c010ad19>] (handle_IPI+0x151/0x168) from [<c0100425>] (gic_handle_irq+0x5d/0x60)
[ 330.068499] [<c0100425>] (gic_handle_irq+0x5d/0x60) from [<c061735b>] (__irq_svc+0x3b/0x80)
[ 330.076806] Exception stack(0xc0b0ff18 to 0xc0b0ff60)
[ 330.081843] ff00: ffffffed 0106e000
[ 330.090011] ff20: 00000000 c045e5d9 c0b16458 c0b0e000 c0b17180 c0b6b250 c0b0e008 c0b0a400
[ 330.098170] ff40: c0b0e008 00000000 000000b2 c0b0ff60 c0106535 c0106536 600f0033 ffffffff
[ 330.106351] [<c061735b>] (__irq_svc+0x3b/0x80) from [<c0106536>] (arch_cpu_idle+0x1e/0x28)
[ 330.114593] [<c0106536>] (arch_cpu_idle+0x1e/0x28) from [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c)
[ 330.123707] [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c) from [<c060bf31>] (rest_init+0x95/0xa8)
[ 330.132480] [<c060bf31>] (rest_init+0x95/0xa8) from [<c0a008a1>] (start_kernel+0x2bd/0x2d4)
[ 330.140785] CPU1: stopping
[ 330.143489] CPU: 1 PID: 0 Comm: swapper/1 Tainted: P D O 3.10.84-perf-gbc40dee-35160-g0d54083 #1
[ 330.152982] [<c010b7a1>] (unwind_backtrace+0x1/0xf8) from [<c0108dc5>] (show_stack+0xd/0x10)
[ 330.161382] [<c0108dc5>] (show_stack+0xd/0x10) from [<c010ad19>] (handle_IPI+0x151/0x168)
[ 330.169534] [<c010ad19>] (handle_IPI+0x151/0x168) from [<c0100425>] (gic_handle_irq+0x5d/0x60)
[ 330.178132] [<c0100425>] (gic_handle_irq+0x5d/0x60) from [<c061735b>] (__irq_svc+0x3b/0x80)
[ 330.186442] Exception stack(0xcbc89f78 to 0xcbc89fc0)
[ 330.191480] 9f60: ffffffed 0107b000
[ 330.199645] 9f80: 00000000 c045e5d9 c0b16458 cbc88000 c0b17180 c0b6b250 cbc88008 c0b0a400
[ 330.207806] 9fa0: cbc88008 00000000 0382a800 cbc89fc0 c0106535 c0106536 60070033 ffffffff
[ 330.215983] [<c061735b>] (__irq_svc+0x3b/0x80) from [<c0106536>] (arch_cpu_idle+0x1e/0x28)
[ 330.224227] [<c0106536>] (arch_cpu_idle+0x1e/0x28) from [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c)
[ 330.233340] [<c016cb6f>] (cpu_startup_entry+0x14b/0x20c) from [<0860f365>] (0x860f365)
[ 330.241396] Rebooting in 5 seconds..
[ 335.246158] Going down for restart now
[ 335.249660] Failed to disable secure wdog debug: -4
[ 346.257332] Reboot failed -- System halted
^ permalink raw reply
* Re: echainiv not working as supposed to be?
From: Herbert Xu @ 2016-09-07 10:42 UTC (permalink / raw)
To: Mathias Krause; +Cc: Steffen Klassert, linux-crypto@vger.kernel.org
In-Reply-To: <20160906160810.GA10311@gondor.apana.org.au>
On Wed, Sep 07, 2016 at 12:08:10AM +0800, Herbert Xu wrote:
>
> > So, should echainiv use a per-context per-cpu array instead that --
> > for simplicity -- gets initialised with random bytes and will be
> > updated as it's now, just not with a single global per-cpu array, but
> > a per-context one?
>
> As I said, the per-cpu IV is never seen by anyone so there is no
> need to make it per-tfm.
On second thought you're right. The global array was a very lame
idea. This patch changes it so that it instead does a multiply
with the salt.
---8<--
Subject: crypto: echainiv - Replace chaining with multiplication
The current implementation uses a global per-cpu array to store
data which are used to derive the next IV. This is insecure as
the attacker may change the stored data.
This patch removes all traces of chaining and replaces it with
multiplication of the salt and the sequence number.
Fixes: a10f554fa7e0 ("crypto: echainiv - Add encrypted chain IV...")
Cc: stable@vger.kernel.org
Reported-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index 1b01fe9..e3d889b 100644
--- a/crypto/echainiv.c
+++ b/crypto/echainiv.c
@@ -1,8 +1,8 @@
/*
* echainiv: Encrypted Chain IV Generator
*
- * This generator generates an IV based on a sequence number by xoring it
- * with a salt and then encrypting it with the same key as used to encrypt
+ * This generator generates an IV based on a sequence number by multiplying
+ * it with a salt and then encrypting it with the same key as used to encrypt
* the plain text. This algorithm requires that the block size be equal
* to the IV size. It is mainly useful for CBC.
*
@@ -24,81 +24,17 @@
#include <linux/err.h>
#include <linux/init.h>
#include <linux/kernel.h>
-#include <linux/mm.h>
#include <linux/module.h>
-#include <linux/percpu.h>
-#include <linux/spinlock.h>
+#include <linux/slab.h>
#include <linux/string.h>
-#define MAX_IV_SIZE 16
-
-static DEFINE_PER_CPU(u32 [MAX_IV_SIZE / sizeof(u32)], echainiv_iv);
-
-/* We don't care if we get preempted and read/write IVs from the next CPU. */
-static void echainiv_read_iv(u8 *dst, unsigned size)
-{
- u32 *a = (u32 *)dst;
- u32 __percpu *b = echainiv_iv;
-
- for (; size >= 4; size -= 4) {
- *a++ = this_cpu_read(*b);
- b++;
- }
-}
-
-static void echainiv_write_iv(const u8 *src, unsigned size)
-{
- const u32 *a = (const u32 *)src;
- u32 __percpu *b = echainiv_iv;
-
- for (; size >= 4; size -= 4) {
- this_cpu_write(*b, *a);
- a++;
- b++;
- }
-}
-
-static void echainiv_encrypt_complete2(struct aead_request *req, int err)
-{
- struct aead_request *subreq = aead_request_ctx(req);
- struct crypto_aead *geniv;
- unsigned int ivsize;
-
- if (err == -EINPROGRESS)
- return;
-
- if (err)
- goto out;
-
- geniv = crypto_aead_reqtfm(req);
- ivsize = crypto_aead_ivsize(geniv);
-
- echainiv_write_iv(subreq->iv, ivsize);
-
- if (req->iv != subreq->iv)
- memcpy(req->iv, subreq->iv, ivsize);
-
-out:
- if (req->iv != subreq->iv)
- kzfree(subreq->iv);
-}
-
-static void echainiv_encrypt_complete(struct crypto_async_request *base,
- int err)
-{
- struct aead_request *req = base->data;
-
- echainiv_encrypt_complete2(req, err);
- aead_request_complete(req, err);
-}
-
static int echainiv_encrypt(struct aead_request *req)
{
struct crypto_aead *geniv = crypto_aead_reqtfm(req);
struct aead_geniv_ctx *ctx = crypto_aead_ctx(geniv);
struct aead_request *subreq = aead_request_ctx(req);
- crypto_completion_t compl;
- void *data;
+ __be64 nseqno;
+ u64 seqno;
u8 *info;
unsigned int ivsize = crypto_aead_ivsize(geniv);
int err;
@@ -108,8 +44,6 @@ static int echainiv_encrypt(struct aead_request *req)
aead_request_set_tfm(subreq, ctx->child);
- compl = echainiv_encrypt_complete;
- data = req;
info = req->iv;
if (req->src != req->dst) {
@@ -127,29 +61,30 @@ static int echainiv_encrypt(struct aead_request *req)
return err;
}
- if (unlikely(!IS_ALIGNED((unsigned long)info,
- crypto_aead_alignmask(geniv) + 1))) {
- info = kmalloc(ivsize, req->base.flags &
- CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL:
- GFP_ATOMIC);
- if (!info)
- return -ENOMEM;
-
- memcpy(info, req->iv, ivsize);
- }
-
- aead_request_set_callback(subreq, req->base.flags, compl, data);
+ aead_request_set_callback(subreq, req->base.flags,
+ req->base.complete, req->base.data);
aead_request_set_crypt(subreq, req->dst, req->dst,
req->cryptlen, info);
aead_request_set_ad(subreq, req->assoclen);
- crypto_xor(info, ctx->salt, ivsize);
+ memcpy(&nseqno, info + ivsize - 8, 8);
+ seqno = be64_to_cpu(nseqno);
+ memset(info, 0, ivsize);
+
scatterwalk_map_and_copy(info, req->dst, req->assoclen, ivsize, 1);
- echainiv_read_iv(info, ivsize);
- err = crypto_aead_encrypt(subreq);
- echainiv_encrypt_complete2(req, err);
- return err;
+ do {
+ u64 a;
+
+ memcpy(&a, ctx->salt + ivsize - 8, 8);
+
+ a |= 1;
+ a *= seqno;
+
+ memcpy(info + ivsize - 8, &a, 8);
+ } while ((ivsize -= 8));
+
+ return crypto_aead_encrypt(subreq);
}
static int echainiv_decrypt(struct aead_request *req)
@@ -196,8 +131,7 @@ static int echainiv_aead_create(struct crypto_template *tmpl,
alg = crypto_spawn_aead_alg(spawn);
err = -EINVAL;
- if (inst->alg.ivsize & (sizeof(u32) - 1) ||
- inst->alg.ivsize > MAX_IV_SIZE)
+ if (inst->alg.ivsize & (sizeof(u64) - 1) || !inst->alg.ivsize)
goto free_inst;
inst->alg.encrypt = echainiv_encrypt;
@@ -206,7 +140,6 @@ static int echainiv_aead_create(struct crypto_template *tmpl,
inst->alg.init = aead_init_geniv;
inst->alg.exit = aead_exit_geniv;
- inst->alg.base.cra_alignmask |= __alignof__(u32) - 1;
inst->alg.base.cra_ctxsize = sizeof(struct aead_geniv_ctx);
inst->alg.base.cra_ctxsize += inst->alg.ivsize;
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz
From: Herbert Xu @ 2016-09-07 12:50 UTC (permalink / raw)
To: Iaroslav Gridin
Cc: davem, linux-crypto, linux-kernel, andy.gross, david.brown,
linux-arm-msm, linux-soc
In-Reply-To: <20160903164535.1118-1-voker57@gmail.com>
On Sat, Sep 03, 2016 at 07:45:35PM +0300, Iaroslav Gridin wrote:
>
> @@ -247,6 +261,8 @@ err_clks_iface:
> clk_disable_unprepare(qce->iface);
> err_clks_core:
> clk_disable_unprepare(qce->core);
> +err_clks_core_src:
> + clk_disable_unprepare(qce->core_src);
What about qce_crypto_remove?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allocate memory during module init
From: Herbert Xu @ 2016-09-07 12:53 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, jslaby, peter, lee.jones, linux-crypto
In-Reply-To: <1472977778-23996-1-git-send-email-prasannatsmkumar@gmail.com>
On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote:
>
> @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>
> static int __init hwrng_modinit(void)
> {
> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
> + if (!rng_buffer)
> + return -ENOMEM;
> +
> + rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
> + if (!rng_fillbuf) {
> + kfree(rng_buffer);
> + return -ENOMEM;
> + }
> +
> return register_miscdev();
You're leaking memory if register_miscdev fails.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz
From: Stanimir Varbanov @ 2016-09-07 13:04 UTC (permalink / raw)
To: Iaroslav Gridin, herbert
Cc: davem, linux-crypto, linux-kernel, andy.gross, david.brown,
linux-arm-msm, linux-soc
In-Reply-To: <20160903164535.1118-1-voker57@gmail.com>
Hi Iaroslav,
On 09/03/2016 07:45 PM, Iaroslav Gridin wrote:
> Without that, QCE performance is about 2x less.
On which platform? The clock rates are per SoC.
>
> Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
> ---
> drivers/crypto/qce/core.c | 18 +++++++++++++++++-
> drivers/crypto/qce/core.h | 2 +-
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index 0cde513..657354c 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
> @@ -193,6 +193,10 @@ static int qce_crypto_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> + qce->core_src = devm_clk_get(qce->dev, "core_src");
> + if (IS_ERR(qce->core_src))
> + return PTR_ERR(qce->core_src);
> +
> qce->core = devm_clk_get(qce->dev, "core");
> if (IS_ERR(qce->core))
> return PTR_ERR(qce->core);
> @@ -205,10 +209,20 @@ static int qce_crypto_probe(struct platform_device *pdev)
> if (IS_ERR(qce->bus))
> return PTR_ERR(qce->bus);
>
> - ret = clk_prepare_enable(qce->core);
> + ret = clk_prepare_enable(qce->core_src);
> if (ret)
> return ret;
>
> + ret = clk_set_rate(qce->core_src, 100000000);
Could you point me from where you got this number? Also I think you
shouldn't be requesting "core_src" it should be a parent of "core" clock
in the clock tree. Did you tried to set rate on "core" clock?
regards,
Stan
^ permalink raw reply
* Re: [PATCH] crypto: caam: add missing header dependencies
From: Herbert Xu @ 2016-09-07 13:11 UTC (permalink / raw)
To: Baoyou Xie
Cc: davem, horia.geanta, srinivas.kandagatla, alexandru.porosanu,
arnd, linux-crypto, linux-kernel, xie.baoyou
In-Reply-To: <1472873370-18589-1-git-send-email-baoyou.xie@linaro.org>
On Sat, Sep 03, 2016 at 11:29:30AM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 'caam_get_era' [-Wmissing-prototypes]
>
> In fact, this function is declared in drivers/crypto/caam/ctrl.h
> and be exported, thus can be refrenced by modules, so this patch
> adds missing header dependencies.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
This patch has already been applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allocate memory during module init
From: PrasannaKumar Muralidharan @ 2016-09-07 13:14 UTC (permalink / raw)
To: Herbert Xu; +Cc: mpm, jslaby, peter, Lee Jones, linux-crypto
In-Reply-To: <20160907125350.GB17176@gondor.apana.org.au>
> On Sun, Sep 04, 2016 at 01:59:38PM +0530, PrasannaKumar Muralidharan wrote:
>>
>> @@ -573,6 +557,17 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>>
>> static int __init hwrng_modinit(void)
>> {
>> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>> + if (!rng_buffer)
>> + return -ENOMEM;
>> +
>> + rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
>> + if (!rng_fillbuf) {
>> + kfree(rng_buffer);
>> + return -ENOMEM;
>> + }
>> +
>> return register_miscdev();
>
> You're leaking memory if register_miscdev fails.
Ah, yes! I can send a revised patch.
Do you think allocating rng_buffer, rng_fillbuf in module init useful?
If not there is no point in sending a new patch with fix.
Thanks,
PrasannaKumar
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allocate memory during module init
From: Herbert Xu @ 2016-09-07 13:16 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, jslaby, peter, Lee Jones, linux-crypto
In-Reply-To: <CANc+2y6ywn-9E0Cv5io6=ZWRFW8Q+GTnubFH31p0y1-WQsGbYQ@mail.gmail.com>
On Wed, Sep 07, 2016 at 06:44:32PM +0530, PrasannaKumar Muralidharan wrote:
>
> Ah, yes! I can send a revised patch.
> Do you think allocating rng_buffer, rng_fillbuf in module init useful?
> If not there is no point in sending a new patch with fix.
Yes I think it makes sense. Those who want to save a few bytes
by keeping the RNGs as modules can always build core HWRNG as a
module too.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] char: hw_random: bcm2835: handle of_iomap failures in bcm2835 driver
From: Herbert Xu @ 2016-09-07 13:19 UTC (permalink / raw)
To: Arvind Yadav
Cc: f.fainelli, rjui, sbranden, bcm-kernel-feedback-list, lee, eric,
yendapally.reddy, linux-crypto, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, mpm
In-Reply-To: <1472490616-9597-1-git-send-email-arvind.yadav.cs@gmail.com>
On Mon, Aug 29, 2016 at 10:40:16PM +0530, Arvind Yadav wrote:
> Check return value of of_iomap and handle errors correctly.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix incorrect accelerator mask for C3X devices
From: Herbert Xu @ 2016-09-07 13:20 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, Maksim Lukoshkov
In-Reply-To: <1472579760-3698-1-git-send-email-giovanni.cabiddu@intel.com>
On Tue, Aug 30, 2016 at 06:56:00PM +0100, Giovanni Cabiddu wrote:
> From: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
>
> Fix incorrect value of ADF_C3XXX_ACCELERATORS_MASK.
>
> Signed-off-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v4 0/2] crypto: engine: permit to enqueue ashash_request
From: Herbert Xu @ 2016-09-07 13:20 UTC (permalink / raw)
To: Corentin Labbe; +Cc: davem, linux-crypto, baolin.wang, linux-kernel
In-Reply-To: <1472644978-9003-1-git-send-email-clabbe.montjoie@gmail.com>
On Wed, Aug 31, 2016 at 02:02:56PM +0200, Corentin Labbe wrote:
> Hello
>
> I wanted to use the crypto engine for my Allwinner crypto driver but something
> prevented me to use it: it cannot enqueue hash requests.
> This patch convert crypto engine to permit enqueuing of ahash_requests.
> It also convert the only driver using crypto engine.
>
> The modifications against omap was only compile tested but the crypto engine with
> hash support was tested on two different offtree driver (sun4i-ss and sun8i-ce)
>
> Regards
>
> Changes since v1:
> - rebased on cryptodev for handling omap-des
>
> Changes since v2:
> - Fusionned both patch
> - Renamed crypt_one_request to do_one_request
> - Test the type of request before processing it
>
> Changes sunce v3
> - Add functions for each type (ablkcipher/ahash)
>
> LABBE Corentin (2):
> crypto: move crypto engine to its own header
> crypto: engine: permit to enqueue ashash_request
>
> crypto/crypto_engine.c | 187 ++++++++++++++++++++++++++++++++++++----------
> drivers/crypto/omap-aes.c | 9 ++-
> drivers/crypto/omap-des.c | 9 ++-
> include/crypto/algapi.h | 70 -----------------
> include/crypto/engine.h | 107 ++++++++++++++++++++++++++
> 5 files changed, 266 insertions(+), 116 deletions(-)
> create mode 100644 include/crypto/engine.h
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: caam - fix rfc3686(ctr(aes)) IV load
From: Herbert Xu @ 2016-09-07 13:20 UTC (permalink / raw)
To: Catalin Vasile; +Cc: linux-crypto, davem, horia.geanta
In-Reply-To: <1472648275-2542-1-git-send-email-cata.vasile@nxp.com>
On Wed, Aug 31, 2016 at 03:57:55PM +0300, Catalin Vasile wrote:
> -nonce is being loaded using append_load_imm_u32() instead of
> append_load_as_imm() (nonce is a byte array / stream, not a 4-byte
> variable)
> -counter is not being added in big endian format, as mandatated by
> RFC3686 and expected by the crypto engine
>
> Signed-off-by: Catalin Vasile <cata.vasile@nxp.com>
> Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/3] crypto: arm and cryptd fixes
From: Herbert Xu @ 2016-09-07 13:21 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1472736343-15305-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Sep 01, 2016 at 02:25:40PM +0100, Ard Biesheuvel wrote:
> Patch #1 fixes a trivial code generation issue on ARM.
>
> Patch #2 and #3 fix the broken GHASH on ARM using the v8 Crypto Extensions
> pmull.64 instructions. The problem seems to be that it is allowed to call
> .import() without .init() (at least, that is what the test cases do), but
> this means that the initialization to tie the shash_desc's to their child
> transforms needs to execute in the .import() context as well.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - add missing release in ccp_dmaengine_register
From: Herbert Xu @ 2016-09-07 13:21 UTC (permalink / raw)
To: Quentin Lambert
Cc: Tom Lendacky, Gary Hook, David S. Miller, linux-crypto,
linux-kernel, kernel-janitors
In-Reply-To: <20160902094853.21376-1-lambert.quentin@gmail.com>
On Fri, Sep 02, 2016 at 11:48:53AM +0200, Quentin Lambert wrote:
> ccp_dmaengine_register used to return with an error code before
> releasing all resource. This patch adds a jump to the appropriate label
> ensuring that the resources are properly released before returning.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: mv_cesa: remove NO_IRQ reference
From: Herbert Xu @ 2016-09-07 13:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Romain Perier, Boris Brezillon, Arnaud Ebalard, Thomas Petazzoni,
David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20160902232648.2119621-1-arnd@arndb.de>
On Sat, Sep 03, 2016 at 01:26:40AM +0200, Arnd Bergmann wrote:
> Drivers should not use NO_IRQ, as we are trying to get rid of that.
> In this case, the call to irq_of_parse_and_map() is both wrong
> (as it returns '0' on failure, not NO_IRQ) and unnecessary
> (as platform_get_irq() does the same thing)
>
> This removes the call to irq_of_parse_and_map() and checks for
> the error code correctly.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] hwrng: pasemi_rng.c: Migrate to managed API
From: Herbert Xu @ 2016-09-07 13:22 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: darren, clabbe.montjoie, linux-crypto, mpm, olof, linuxppc-dev
In-Reply-To: <1473012788-6262-1-git-send-email-prasannatsmkumar@gmail.com>
On Sun, Sep 04, 2016 at 11:43:08PM +0530, PrasannaKumar Muralidharan wrote:
> Use devm_ioremap and devm_hwrng_register instead of ioremap and
> hwrng_register. This removes unregistering and error handling code.
>
> Changes in v2:
> Remove hardcoded resource size in ioremap, use resource struct obtained
> by calling platform_get_resource.
>
> Removing hardcoded resource size was suggested by LABBE Corentin.
>
> CC: Darren Stevens <darren@stevens-zone.net>
>
> Suggested-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Herbert Xu @ 2016-09-07 13:29 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <0e19ed55-f24b-ad98-215b-1eb318193f06@ti.com>
On Mon, Sep 05, 2016 at 03:06:05PM +0300, Tero Kristo wrote:
>
> Additional request, would it be possible for you to check the rest
> of the series and just ignore patches #2 and #3 for now, the rest
> don't have any dependencies against these and can be applied cleanly
> without.
>
> I would like to see these move forward while I figure out how to
> handle the buffer / export+import...
Sure I'll review them again.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: arm/ghash: change internal cra_name to "__ghash"
From: Herbert Xu @ 2016-09-07 13:22 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1473076724-2725-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Sep 05, 2016 at 12:58:44PM +0100, Ard Biesheuvel wrote:
> The fact that the internal synchrous hash implementation is called
> "ghash" like the publicly visible one is causing the testmgr code
> to misidentify it as an algorithm that requires testing at boottime.
> So rename it to "__ghash" to prevent this.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: Romain Perier @ 2016-09-07 14:23 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: dsaxena, mpm, Herbert Xu, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas,
linux-crypto
In-Reply-To: <CANc+2y6LeOqSy37x=vXaLPkGM3C5Wh6Yq11ybO+-0DU19wLBUQ@mail.gmail.com>
Hello,
Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
>> Use devm_hwrng_register instead of hwrng_register. It avoids the need
>> to handle unregistration explicitly from the remove function.
>>
>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>> ---
>> drivers/char/hw_random/omap-rng.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
>> index d47b24d..171c3e8 100644
>> --- a/drivers/char/hw_random/omap-rng.c
>> +++ b/drivers/char/hw_random/omap-rng.c
>> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device *pdev)
>> if (ret)
>> goto err_ioremap;
>>
>> - ret = hwrng_register(&omap_rng_ops);
>> + ret = devm_hwrng_register(dev, &omap_rng_ops);
>> if (ret)
>> goto err_register;
>>
>> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device *pdev)
>> {
>> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>>
>> - hwrng_unregister(&omap_rng_ops);
>> -
>> priv->pdata->cleanup(priv);
>>
>> pm_runtime_put_sync(&pdev->dev);
>> --
>
> If devm_hwrng_register is used hwrng_unregister will be called after
> pm_runtime_disable is called. If RNG device is in use calling
> omap_rng_remove may not work properly.
>
The case where the remove function is called is if you unbind the driver
by hand or you call rmmod while the RNG device is used.
I don't think that the kernel will call platform->remove is the device
is in use (so /dev/hwrng). I mean the argument that the unregister
function is called after pm_runtime_disable is correct, but I don't
think that the remove function might be called while the device is in
use. There is necessarily a mutual exclusive case between "use the
device" and "call the remove function of the device". However, I am open
to suggestions.
Regards,
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration
From: PrasannaKumar Muralidharan @ 2016-09-07 14:45 UTC (permalink / raw)
To: Romain Perier
Cc: dsaxena, mpm, Herbert Xu, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas,
linux-crypto
In-Reply-To: <57D022F9.2020407@free-electrons.com>
On 7 September 2016 at 19:53, Romain Perier
<romain.perier@free-electrons.com> wrote:
> Hello,
>
>
> Le 06/09/2016 18:31, PrasannaKumar Muralidharan a écrit :
>>>
>>> Use devm_hwrng_register instead of hwrng_register. It avoids the need
>>> to handle unregistration explicitly from the remove function.
>>>
>>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>>> ---
>>> drivers/char/hw_random/omap-rng.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/char/hw_random/omap-rng.c
>>> b/drivers/char/hw_random/omap-rng.c
>>> index d47b24d..171c3e8 100644
>>> --- a/drivers/char/hw_random/omap-rng.c
>>> +++ b/drivers/char/hw_random/omap-rng.c
>>> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device
>>> *pdev)
>>> if (ret)
>>> goto err_ioremap;
>>>
>>> - ret = hwrng_register(&omap_rng_ops);
>>> + ret = devm_hwrng_register(dev, &omap_rng_ops);
>>> if (ret)
>>> goto err_register;
>>>
>>> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device
>>> *pdev)
>>> {
>>> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>>>
>>> - hwrng_unregister(&omap_rng_ops);
>>> -
>>> priv->pdata->cleanup(priv);
>>>
>>> pm_runtime_put_sync(&pdev->dev);
>>> --
>>
>>
>> If devm_hwrng_register is used hwrng_unregister will be called after
>> pm_runtime_disable is called. If RNG device is in use calling
>> omap_rng_remove may not work properly.
>>
>
> The case where the remove function is called is if you unbind the driver by
> hand or you call rmmod while the RNG device is used.
> I don't think that the kernel will call platform->remove is the device is in
> use (so /dev/hwrng). I mean the argument that the unregister function is
> called after pm_runtime_disable is correct, but I don't think that the
> remove function might be called while the device is in use. There is
> necessarily a mutual exclusive case between "use the device" and "call the
> remove function of the device". However, I am open to suggestions.
The way you explained is good :D. Good point too. But the device is
created by hw_random core (hwrng_modinit in core.c) so the device can
be in use when omap-rng module is removed. Please feel free to correct
me if I am wrong.
Cheers,
PrasannaKumar
^ permalink raw reply
* [PATCH v2] hwrng: core - Allocate memory during module init
From: PrasannaKumar Muralidharan @ 2016-09-07 14:48 UTC (permalink / raw)
To: mpm, herbert, lee.jones, jslaby, peter, linux-crypto
Cc: PrasannaKumar Muralidharan
In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
once and it is freed during module exit. This patch moves allocating
rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
avoids checking whether rng_buffer and rng_fillbuf was allocated from
every hwrng_register call. Also moving them to module init makes it
explicit that it is freed in module exit.
Change in v2:
Fix memory leak when register_miscdev fails.
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
---
drivers/char/hw_random/core.c | 37 ++++++++++++++++++++-----------------
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..4827945 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -449,22 +449,6 @@ int hwrng_register(struct hwrng *rng)
goto out;
mutex_lock(&rng_mutex);
-
- /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
- err = -ENOMEM;
- if (!rng_buffer) {
- rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_buffer)
- goto out_unlock;
- }
- if (!rng_fillbuf) {
- rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
- if (!rng_fillbuf) {
- kfree(rng_buffer);
- goto out_unlock;
- }
- }
-
/* Must not register two RNGs with the same name. */
err = -EEXIST;
list_for_each_entry(tmp, &rng_list, list) {
@@ -573,7 +557,26 @@ EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
static int __init hwrng_modinit(void)
{
- return register_miscdev();
+ int ret = -ENOMEM;
+
+ /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
+ rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_buffer)
+ return -ENOMEM;
+
+ rng_fillbuf = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_fillbuf) {
+ kfree(rng_buffer);
+ return -ENOMEM;
+ }
+
+ ret = register_miscdev();
+ if (ret) {
+ kfree(rng_fillbuf);
+ kfree(rng_buffer);
+ }
+
+ return ret;
}
static void __exit hwrng_modexit(void)
--
2.5.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox