* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..1a0c6a486a9c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..19c3dddd901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
+#define cpu_feature(x) ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ return elf_hwcap2 & (1UL << num);
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index aef022a87c53..5b1af6f8b2b5 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -14,6 +14,7 @@
#include <crypto/aes.h>
#include <crypto/ablk_helper.h>
#include <crypto/algapi.h>
+#include <linux/cpufeature.h>
#include <linux/module.h>
#include <crypto/xts.h>
@@ -515,8 +516,6 @@ static struct crypto_alg aes_algs[] = { {
static int __init aes_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_AES))
- return -ENODEV;
return crypto_register_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
@@ -525,5 +524,5 @@ static void __exit aes_exit(void)
crypto_unregister_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
-module_init(aes_init);
+module_cpu_feature_match(AES, aes_init);
module_exit(aes_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/ghash-ce-glue.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 7546b3c02466..6bac8bea9f1e 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -15,6 +15,7 @@
#include <crypto/cryptd.h>
#include <crypto/internal/hash.h>
#include <crypto/gf128mul.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -311,9 +312,6 @@ static int __init ghash_ce_mod_init(void)
{
int err;
- if (!(elf_hwcap2 & HWCAP2_PMULL))
- return -ENODEV;
-
err = crypto_register_shash(&ghash_alg);
if (err)
return err;
@@ -334,5 +332,5 @@ static void __exit ghash_ce_mod_exit(void)
crypto_unregister_shash(&ghash_alg);
}
-module_init(ghash_ce_mod_init);
+module_cpu_feature_match(PMULL, ghash_ce_mod_init);
module_exit(ghash_ce_mod_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha1-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha1-ce-glue.c b/arch/arm/crypto/sha1-ce-glue.c
index 80bc2fcd241a..555f72b5e659 100644
--- a/arch/arm/crypto/sha1-ce-glue.c
+++ b/arch/arm/crypto/sha1-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha1_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -82,8 +83,6 @@ static struct shash_alg alg = {
static int __init sha1_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA1))
- return -ENODEV;
return crypto_register_shash(&alg);
}
@@ -92,5 +91,5 @@ static void __exit sha1_ce_mod_fini(void)
crypto_unregister_shash(&alg);
}
-module_init(sha1_ce_mod_init);
+module_cpu_feature_match(SHA1, sha1_ce_mod_init);
module_exit(sha1_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel, linux-crypto, linux, herbert
Cc: steve.capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha2-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..df4dcef054ae 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha256_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -100,8 +101,6 @@ static struct shash_alg algs[] = { {
static int __init sha2_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA2))
- return -ENODEV;
return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
@@ -110,5 +109,5 @@ static void __exit sha2_ce_mod_fini(void)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
-module_init(sha2_ce_mod_init);
+module_cpu_feature_match(SHA2, sha2_ce_mod_init);
module_exit(sha2_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 10:55 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Herbert Xu
Cc: Will Deacon, Catalin Marinas, Russell King - ARM Linux,
Ard Biesheuvel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On 11 October 2016 at 19:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm. This is due
> to the fact that the key schedules are incompatible between generic AES and the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
> one that is compatible with the generic AES key schedule generation code (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>
Ping?
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
>
> arch/arm/crypto/aes-ce-glue.c | 5 ++
> arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
> arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
> arch/arm64/crypto/aes-ce.S | 1 +
> arch/arm64/crypto/aes-modes.S | 3 +-
> arch/arm64/crypto/aes-neon.S | 25 +++++----
> arch/arm64/crypto/ghash-ce-core.S | 6 +--
> arch/arm64/crypto/sha1-ce-core.S | 4 +-
> arch/arm64/crypto/sha2-ce-core.S | 4 +-
> 9 files changed, 72 insertions(+), 54 deletions(-)
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Catalin Marinas @ 2016-10-18 11:49 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto, linux-arm-kernel, herbert, will.deacon, linux
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm.
I think for future reference, the Fixes tag should denote the commit
that introduced the issue. An explicit Cc: stable tag would state how
far back it should be applied.
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
The changes look fine to me but I can't claim I fully understand these
algorithms. FWIW:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
(Will may pick them up for 4.9-rcX)
^ permalink raw reply
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 12:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Herbert Xu, Will Deacon,
Russell King - ARM Linux
In-Reply-To: <20161018114932.GG10115@e104818-lin.cambridge.arm.com>
On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> currently work, or have ever worked correctly when built for big endian. So this
>> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> well, and an additional fix for XTS which escaped my attention before.
>>
>> Each of these patches carries a fixes tag, and could be backported to stable.
>> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> fix is compatible with, not the patch that introduced the algorithm.
>
> I think for future reference, the Fixes tag should denote the commit
> that introduced the issue. An explicit Cc: stable tag would state how
> far back it should be applied.
>
OK, that sounds reasonable.
>> Ard Biesheuvel (8):
>> crypto: arm64/aes-ce - fix for big endian
>> crypto: arm64/ghash-ce - fix for big endian
>> crypto: arm64/sha1-ce - fix for big endian
>> crypto: arm64/sha2-ce - fix for big endian
>> crypto: arm64/aes-ccm-ce: fix for big endian
>> crypto: arm64/aes-neon - fix for big endian
>> crypto: arm64/aes-xts-ce: fix for big endian
>> crypto: arm/aes-ce - fix for big endian
>
> The changes look fine to me but I can't claim I fully understand these
> algorithms. FWIW:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> (Will may pick them up for 4.9-rcX)
Thanks, although I was kind of expecting Herbert to pick these up,
given that #8 affects ARM not arm64.
But if you (or Will) can pick up #1 to #7, that is also fine, then I
can drop #8 into rmk's patch database.
Thanks,
Ard,
^ permalink raw reply
* [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-10-18 12:34 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-kernel, linux-crypto, linux-arm-kernel, LABBE Corentin
From: LABBE Corentin <clabbe.montjoie@gmail.com>
The Security System have a PRNG.
This patch add support for it as an hwrng.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/Kconfig | 8 ++++
drivers/crypto/sunxi-ss/Makefile | 1 +
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +++++++
drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 ++++++++++++++++++++++++++++++++
drivers/crypto/sunxi-ss/sun4i-ss.h | 8 ++++
5 files changed, 101 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_SUN4I_SS_PRNG
+ bool "Support for Allwinner Security System PRNG"
+ depends on CRYPTO_DEV_SUN4I_SS
+ select HW_RANDOM
+ help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ /* Voluntarily made the PRNG optional */
+ err = sun4i_ss_hwrng_register(&ss->hwrng);
+ if (!err)
+ dev_info(ss->dev, "sun4i-ss PRNG loaded");
+ else
+ dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ sun4i_ss_hwrng_remove(&ss->hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 0000000..95fadb7
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,70 @@
+#include "sun4i-ss.h"
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+ get_random_bytes(ss->seed, SS_SEED_LEN);
+
+ return 0;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+ size_t max, bool wait)
+{
+ int i;
+ u32 v;
+ u32 *data = buf;
+ const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+ size_t len;
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+ len = min_t(size_t, SS_DATA_LEN, max);
+
+ spin_lock_bh(&ss->slock);
+
+ writel(mode, ss->base + SS_CTL);
+
+ /* write the seed */
+ for (i = 0; i < SS_SEED_LEN / 4; i++)
+ writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+ writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+ /* Read the random data */
+ readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+ if (len % 4 > 0) {
+ v = readl(ss->base + SS_TXFIFO);
+ memcpy(data + len / 4, &v, len % 4);
+ }
+
+ /* Update the seed */
+ for (i = 0; i < SS_SEED_LEN / 4; i++) {
+ v = readl(ss->base + SS_KEY0 + i * 4);
+ ss->seed[i] = v;
+ }
+
+ writel(0, ss->base + SS_CTL);
+ spin_unlock_bh(&ss->slock);
+ return len;
+}
+
+int sun4i_ss_hwrng_register(struct hwrng *hwrng)
+{
+ hwrng->name = "sun4i Security System PRNG";
+ hwrng->init = sun4i_ss_hwrng_init;
+ hwrng->read = sun4i_ss_hwrng_read;
+ hwrng->quality = 1000;
+
+ /* Cannot use devm_hwrng_register() since we need to hwrng_unregister
+ * before stopping clocks/regulator
+ */
+ return hwrng_register(hwrng);
+}
+
+void sun4i_ss_hwrng_remove(struct hwrng *hwrng)
+{
+ hwrng_unregister(hwrng);
+}
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
index f04c0f8..1297510 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -23,6 +23,7 @@
#include <linux/scatterlist.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/hw_random.h>
#include <crypto/md5.h>
#include <crypto/sha.h>
#include <crypto/hash.h>
@@ -125,6 +126,9 @@
#define SS_RXFIFO_EMP_INT_ENABLE (1 << 2)
#define SS_TXFIFO_AVA_INT_ENABLE (1 << 0)
+#define SS_SEED_LEN (192 / 8)
+#define SS_DATA_LEN (160 / 8)
+
struct sun4i_ss_ctx {
void __iomem *base;
int irq;
@@ -134,6 +138,8 @@ struct sun4i_ss_ctx {
struct device *dev;
struct resource *res;
spinlock_t slock; /* control the use of the device */
+ struct hwrng hwrng;
+ u32 seed[SS_SEED_LEN / 4];
};
struct sun4i_ss_alg_template {
@@ -199,3 +205,5 @@ int sun4i_ss_des_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen);
int sun4i_ss_des3_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen);
+int sun4i_ss_hwrng_register(struct hwrng *hwrng);
+void sun4i_ss_hwrng_remove(struct hwrng *hwrng);
--
2.7.3
^ permalink raw reply related
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: Stephan Mueller @ 2016-10-18 14:24 UTC (permalink / raw)
To: Corentin Labbe
Cc: herbert, davem, maxime.ripard, wens, linux-kernel, linux-crypto,
linux-arm-kernel
In-Reply-To: <1476794067-28563-1-git-send-email-clabbe.montjoie@gmail.com>
Am Dienstag, 18. Oktober 2016, 14:34:27 CEST schrieb Corentin Labbe:
Hi Corentin,
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c new file mode 100644
> index 0000000..95fadb7
> --- /dev/null
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> @@ -0,0 +1,70 @@
> +#include "sun4i-ss.h"
> +
> +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> +{
> + struct sun4i_ss_ctx *ss;
> +
> + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> + get_random_bytes(ss->seed, SS_SEED_LEN);
Is it wise to call get_random_bytes once in the init function and never
thereafter?
This init function may be called during boot time of the kernel at which the
input_pool may not yet have received sufficient amounts of entropy.
What about registering a callback with add_random_ready_callback and seed
again when sufficient entropy was collected?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG
From: PrasannaKumar Muralidharan @ 2016-10-18 16:09 UTC (permalink / raw)
To: Corentin Labbe
Cc: Herbert Xu, davem, maxime.ripard, wens, linux-kernel,
linux-crypto, linux-arm-kernel
In-Reply-To: <1476794067-28563-1-git-send-email-clabbe.montjoie@gmail.com>
Hi Corentin,
I have a few minor comments.
On 18 October 2016 at 18:04, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> From: LABBE Corentin <clabbe.montjoie@gmail.com>
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/Kconfig | 8 ++++
> drivers/crypto/sunxi-ss/Makefile | 1 +
> drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +++++++
> drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 ++++++++++++++++++++++++++++++++
> drivers/crypto/sunxi-ss/sun4i-ss.h | 8 ++++
> 5 files changed, 101 insertions(+)
> create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 4d2b81f..38f7aca 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
> To compile this driver as a module, choose M here: the module
> will be called sun4i-ss.
>
> +config CRYPTO_DEV_SUN4I_SS_PRNG
> + bool "Support for Allwinner Security System PRNG"
> + depends on CRYPTO_DEV_SUN4I_SS
> + select HW_RANDOM
> + help
> + This driver provides kernel-side support for the Pseudo-Random
> + Number Generator found in the Security System.
> +
> config CRYPTO_DEV_ROCKCHIP
> tristate "Rockchip's Cryptographic Engine driver"
> depends on OF && ARCH_ROCKCHIP
> diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
> index 8f4c7a2..ca049ee 100644
> --- a/drivers/crypto/sunxi-ss/Makefile
> +++ b/drivers/crypto/sunxi-ss/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
> sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
> +sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> index 3ac6c6c..fa739de 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> @@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
> }
> }
> platform_set_drvdata(pdev, ss);
> +
> +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> + /* Voluntarily made the PRNG optional */
> + err = sun4i_ss_hwrng_register(&ss->hwrng);
> + if (!err)
> + dev_info(ss->dev, "sun4i-ss PRNG loaded");
> + else
> + dev_err(ss->dev, "sun4i-ss PRNG failed");
> +#endif
> +
> return 0;
> error_alg:
> i--;
> @@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
> int i;
> struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
>
> +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
> + sun4i_ss_hwrng_remove(&ss->hwrng);
> +#endif
> +
> for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
> switch (ss_algs[i].type) {
> case CRYPTO_ALG_TYPE_ABLKCIPHER:
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> new file mode 100644
> index 0000000..95fadb7
> --- /dev/null
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
> @@ -0,0 +1,70 @@
> +#include "sun4i-ss.h"
> +
> +static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
> +{
> + struct sun4i_ss_ctx *ss;
> +
> + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> + get_random_bytes(ss->seed, SS_SEED_LEN);
> +
> + return 0;
> +}
> +
> +static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
> + size_t max, bool wait)
> +{
> + int i;
> + u32 v;
> + u32 *data = buf;
> + const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
> + size_t len;
> + struct sun4i_ss_ctx *ss;
> +
> + ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
> + len = min_t(size_t, SS_DATA_LEN, max);
> +
> + spin_lock_bh(&ss->slock);
Is spin_lock_bh really required here? I could see it is being used in
sun4i-ss-hash.c but could not find any comment/info about the need.
> + writel(mode, ss->base + SS_CTL);
> +
> + /* write the seed */
> + for (i = 0; i < SS_SEED_LEN / 4; i++)
> + writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
> + writel(mode | SS_PRNG_START, ss->base + SS_CTL);
> +
> + /* Read the random data */
> + readsl(ss->base + SS_TXFIFO, data, len / 4);
> +
> + if (len % 4 > 0) {
> + v = readl(ss->base + SS_TXFIFO);
> + memcpy(data + len / 4, &v, len % 4);
> + }
hwrng core asks for "rng_buffer_size()" of data which is a multiple of
4. So len % 4 will be 0. I think the above check is not required. Feel
free to correct if I am wrong.
> + /* Update the seed */
> + for (i = 0; i < SS_SEED_LEN / 4; i++) {
> + v = readl(ss->base + SS_KEY0 + i * 4);
> + ss->seed[i] = v;
> + }
> +
> + writel(0, ss->base + SS_CTL);
> + spin_unlock_bh(&ss->slock);
> + return len;
> +}
> +
> +int sun4i_ss_hwrng_register(struct hwrng *hwrng)
> +{
> + hwrng->name = "sun4i Security System PRNG";
> + hwrng->init = sun4i_ss_hwrng_init;
> + hwrng->read = sun4i_ss_hwrng_read;
> + hwrng->quality = 1000;
> +
> + /* Cannot use devm_hwrng_register() since we need to hwrng_unregister
> + * before stopping clocks/regulator
> + */
> + return hwrng_register(hwrng);
> +}
> +
> +void sun4i_ss_hwrng_remove(struct hwrng *hwrng)
> +{
> + hwrng_unregister(hwrng);
> +}
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
> index f04c0f8..1297510 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss.h
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
> @@ -23,6 +23,7 @@
> #include <linux/scatterlist.h>
> #include <linux/interrupt.h>
> #include <linux/delay.h>
> +#include <linux/hw_random.h>
> #include <crypto/md5.h>
> #include <crypto/sha.h>
> #include <crypto/hash.h>
> @@ -125,6 +126,9 @@
> #define SS_RXFIFO_EMP_INT_ENABLE (1 << 2)
> #define SS_TXFIFO_AVA_INT_ENABLE (1 << 0)
>
> +#define SS_SEED_LEN (192 / 8)
> +#define SS_DATA_LEN (160 / 8)
> +
> struct sun4i_ss_ctx {
> void __iomem *base;
> int irq;
> @@ -134,6 +138,8 @@ struct sun4i_ss_ctx {
> struct device *dev;
> struct resource *res;
> spinlock_t slock; /* control the use of the device */
> + struct hwrng hwrng;
> + u32 seed[SS_SEED_LEN / 4];
> };
>
> struct sun4i_ss_alg_template {
> @@ -199,3 +205,5 @@ int sun4i_ss_des_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
> unsigned int keylen);
> int sun4i_ss_des3_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
> unsigned int keylen);
> +int sun4i_ss_hwrng_register(struct hwrng *hwrng);
> +void sun4i_ss_hwrng_remove(struct hwrng *hwrng);
> --
> 2.7.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Gary R Hook @ 2016-10-18 18:04 UTC (permalink / raw)
To: Wei Yongjun, Tom Lendacky, Gary Hook, Herbert Xu
Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1476716930-9831-1-git-send-email-weiyj.lk@gmail.com>
On 10/17/2016 10:08 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/ccp-dev.c:44:6: warning:
> symbol 'ccp_error_codes' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Excellent. Thank you.
Acked-by: Gary R Hook <gary.hook@amd.com>
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Hook, Gary @ 2016-10-18 19:13 UTC (permalink / raw)
To: Wei Yongjun, Lendacky, Thomas, Hook, Gary, Herbert Xu
Cc: Wei Yongjun, linux-crypto@vger.kernel.org
In-Reply-To: <1476716930-9831-1-git-send-email-weiyj.lk@gmail.com>
On 10/17/2016 10:08 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/ccp-dev.c:44:6: warning:
> symbol 'ccp_error_codes' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/crypto/ccp/ccp-dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
> index cafa633..c25515a 100644
> --- a/drivers/crypto/ccp/ccp-dev.c
> +++ b/drivers/crypto/ccp/ccp-dev.c
> @@ -41,7 +41,7 @@ struct ccp_tasklet_data {
> };
>
> /* Human-readable error strings */
> -char *ccp_error_codes[] = {
> +static char *ccp_error_codes[] = {
> "",
> "ERR 01: ILLEGAL_ENGINE",
> "ERR 02: ILLEGAL_KEY_ID",
>
Yes, excellent. Thank you.
Acked-by: Gary R Hook <gary.hook@amd.com>
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* [PATCH] crypto: ccp - change bitfield type to unsigned ints
From: Gary R Hook @ 2016-10-18 22:28 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
Bit fields are not sensitive to endianness, so use
a transparent standard data type
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev.h | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index da5f4a6..0d996fe 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -541,23 +541,23 @@ static inline u32 ccp_addr_hi(struct ccp_dma_info *info)
* word 7: upper 16 bits of key pointer; key memory type
*/
struct dword0 {
- __le32 soc:1;
- __le32 ioc:1;
- __le32 rsvd1:1;
- __le32 init:1;
- __le32 eom:1; /* AES/SHA only */
- __le32 function:15;
- __le32 engine:4;
- __le32 prot:1;
- __le32 rsvd2:7;
+ unsigned int soc:1;
+ unsigned int ioc:1;
+ unsigned int rsvd1:1;
+ unsigned int init:1;
+ unsigned int eom:1; /* AES/SHA only */
+ unsigned int function:15;
+ unsigned int engine:4;
+ unsigned int prot:1;
+ unsigned int rsvd2:7;
};
struct dword3 {
- __le32 src_hi:16;
- __le32 src_mem:2;
- __le32 lsb_cxt_id:8;
- __le32 rsvd1:5;
- __le32 fixed:1;
+ unsigned int src_hi:16;
+ unsigned int src_mem:2;
+ unsigned int lsb_cxt_id:8;
+ unsigned int rsvd1:5;
+ unsigned int fixed:1;
};
union dword4 {
@@ -567,18 +567,18 @@ union dword4 {
union dword5 {
struct {
- __le32 dst_hi:16;
- __le32 dst_mem:2;
- __le32 rsvd1:13;
- __le32 fixed:1;
+ unsigned int dst_hi:16;
+ unsigned int dst_mem:2;
+ unsigned int rsvd1:13;
+ unsigned int fixed:1;
} fields;
__le32 sha_len_hi;
};
struct dword7 {
- __le32 key_hi:16;
- __le32 key_mem:2;
- __le32 rsvd1:14;
+ unsigned int key_hi:16;
+ unsigned int key_mem:2;
+ unsigned int rsvd1:14;
};
struct ccp5_desc {
^ permalink raw reply related
* [PATCH] crypto: ccp - remove unneeded code
From: Gary R Hook @ 2016-10-18 22:28 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
Clean up patch for an unneeded structure member.
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 0d996fe..b96d788 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -515,7 +515,6 @@ struct ccp_op {
struct ccp_passthru_op passthru;
struct ccp_ecc_op ecc;
} u;
- struct ccp_mem key;
};
static inline u32 ccp_addr_lo(struct ccp_dma_info *info)
^ permalink raw reply related
* [PATCH] crypto: ccp - Clean up the LSB slot allocation code
From: Gary R Hook @ 2016-10-18 22:33 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
Fix a few problems revealed by testing: verify consistent
units, especially in public slot allocation. Percolate
some common initialization code up to a common routine.
Add some comments.
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev-v3.c | 4 ----
drivers/crypto/ccp/ccp-dev-v5.c | 20 ++++++++++++--------
drivers/crypto/ccp/ccp-dev.c | 4 ++++
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 8d2dbac..7bc0998 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -404,10 +404,6 @@ static int ccp_init(struct ccp_device *ccp)
goto e_pool;
}
- /* Initialize the queues used to wait for KSB space and suspend */
- init_waitqueue_head(&ccp->sb_queue);
- init_waitqueue_head(&ccp->suspend_queue);
-
dev_dbg(dev, "Starting threads...\n");
/* Create a kthread for each queue */
for (i = 0; i < ccp->cmd_q_count; i++) {
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index faf3cb3..ff7816a 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -21,6 +21,12 @@
#include "ccp-dev.h"
+/* Allocate the requested number of contiguous LSB slots
+ * from the LSB bitmap. Look in the private range for this
+ * queue first; failing that, check the public area.
+ * If no space is available, wait around.
+ * Return: first slot number
+ */
static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, unsigned int count)
{
struct ccp_device *ccp;
@@ -50,7 +56,7 @@ static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, unsigned int count)
bitmap_set(ccp->lsbmap, start, count);
mutex_unlock(&ccp->sb_mutex);
- return start * LSB_ITEM_SIZE;
+ return start;
}
ccp->sb_avail = 0;
@@ -63,17 +69,18 @@ static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, unsigned int count)
}
}
+/* Free a number of LSB slots from the bitmap, starting at
+ * the indicated starting slot number.
+ */
static void ccp_lsb_free(struct ccp_cmd_queue *cmd_q, unsigned int start,
unsigned int count)
{
- int lsbno = start / LSB_SIZE;
-
if (!start)
return;
- if (cmd_q->lsb == lsbno) {
+ if (cmd_q->lsb == start) {
/* An entry from the private LSB */
- bitmap_clear(cmd_q->lsbmap, start % LSB_SIZE, count);
+ bitmap_clear(cmd_q->lsbmap, start, count);
} else {
/* From the shared LSBs */
struct ccp_device *ccp = cmd_q->ccp;
@@ -751,9 +758,6 @@ static int ccp5_init(struct ccp_device *ccp)
goto e_pool;
}
- /* Initialize the queue used to suspend */
- init_waitqueue_head(&ccp->suspend_queue);
-
dev_dbg(dev, "Loading LSB map...\n");
/* Copy the private LSB mask to the public registers */
status_lo = ioread32(ccp->io_regs + LSB_PRIVATE_MASK_LO_OFFSET);
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index d9885ce..653b5a5 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -478,6 +478,10 @@ struct ccp_device *ccp_alloc_struct(struct device *dev)
ccp->sb_count = KSB_COUNT;
ccp->sb_start = 0;
+ /* Initialize the wait queues */
+ init_waitqueue_head(&ccp->sb_queue);
+ init_waitqueue_head(&ccp->suspend_queue);
+
ccp->ord = ccp_increment_unit_ordinal();
snprintf(ccp->name, MAX_CCP_NAME_LEN, "ccp-%u", ccp->ord);
snprintf(ccp->rngname, MAX_CCP_NAME_LEN, "ccp-%u-rng", ccp->ord);
^ permalink raw reply related
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Herbert Xu @ 2016-10-19 3:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Catalin Marinas, linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Will Deacon,
Russell King - ARM Linux
In-Reply-To: <CAKv+Gu9wuXnrq77a3Zk0GnHgnkpURh=EegwgP+vAwMC=rdm3qA@mail.gmail.com>
On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> >> currently work, or have ever worked correctly when built for big endian. So this
> >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> >> well, and an additional fix for XTS which escaped my attention before.
> >>
> >> Each of these patches carries a fixes tag, and could be backported to stable.
> >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> >> fix is compatible with, not the patch that introduced the algorithm.
> >
> > I think for future reference, the Fixes tag should denote the commit
> > that introduced the issue. An explicit Cc: stable tag would state how
> > far back it should be applied.
> >
>
> OK, that sounds reasonable.
>
> >> Ard Biesheuvel (8):
> >> crypto: arm64/aes-ce - fix for big endian
> >> crypto: arm64/ghash-ce - fix for big endian
> >> crypto: arm64/sha1-ce - fix for big endian
> >> crypto: arm64/sha2-ce - fix for big endian
> >> crypto: arm64/aes-ccm-ce: fix for big endian
> >> crypto: arm64/aes-neon - fix for big endian
> >> crypto: arm64/aes-xts-ce: fix for big endian
> >> crypto: arm/aes-ce - fix for big endian
> >
> > The changes look fine to me but I can't claim I fully understand these
> > algorithms. FWIW:
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> > (Will may pick them up for 4.9-rcX)
>
> Thanks, although I was kind of expecting Herbert to pick these up,
> given that #8 affects ARM not arm64.
>
> But if you (or Will) can pick up #1 to #7, that is also fine, then I
> can drop #8 into rmk's patch database.
I was planning merging these for 4.10. But I'm fine with them
going through the arm tree. Let me know what you guys want to
do.
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 resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()
From: Herbert Xu @ 2016-10-19 3:50 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-crypto, linux-kernel, Matt Mackall, Rusty Russell,
Jens Axboe, Matt Mullins
In-Reply-To: <4169224b6858d1cf149f1a73f8a03603fa19076d.1476638125.git.luto@kernel.org>
On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote:
> hw_random carefully avoids using a stack buffer except in
> add_early_randomness(). This causes a crash in virtio_rng if
> CONFIG_VMAP_STACK=y.
>
> Reported-by: Matt Mullins <mmullins@mmlx.us>
> Tested-by: Matt Mullins <mmullins@mmlx.us>
> Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
> Signed-off-by: Andy Lutomirski <luto@kernel.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 v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 8:46 UTC (permalink / raw)
To: Herbert Xu
Cc: Catalin Marinas, Russell King - ARM Linux,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Ard Biesheuvel
In-Reply-To: <20161019030333.GA1269@gondor.apana.org.au>
On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> > >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> > >> currently work, or have ever worked correctly when built for big endian. So this
> > >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> > >> well, and an additional fix for XTS which escaped my attention before.
> > >>
> > >> Each of these patches carries a fixes tag, and could be backported to stable.
> > >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> > >> fix is compatible with, not the patch that introduced the algorithm.
> > >
> > > I think for future reference, the Fixes tag should denote the commit
> > > that introduced the issue. An explicit Cc: stable tag would state how
> > > far back it should be applied.
> > >
> >
> > OK, that sounds reasonable.
> >
> > >> Ard Biesheuvel (8):
> > >> crypto: arm64/aes-ce - fix for big endian
> > >> crypto: arm64/ghash-ce - fix for big endian
> > >> crypto: arm64/sha1-ce - fix for big endian
> > >> crypto: arm64/sha2-ce - fix for big endian
> > >> crypto: arm64/aes-ccm-ce: fix for big endian
> > >> crypto: arm64/aes-neon - fix for big endian
> > >> crypto: arm64/aes-xts-ce: fix for big endian
> > >> crypto: arm/aes-ce - fix for big endian
> > >
> > > The changes look fine to me but I can't claim I fully understand these
> > > algorithms. FWIW:
> > >
> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > (Will may pick them up for 4.9-rcX)
> >
> > Thanks, although I was kind of expecting Herbert to pick these up,
> > given that #8 affects ARM not arm64.
> >
> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
> > can drop #8 into rmk's patch database.
>
> I was planning merging these for 4.10. But I'm fine with them
> going through the arm tree. Let me know what you guys want to
> do.
I assumed you'd take them through crypto, as per usual, so I didn't
queue anything in the arm64 tree.
Ard -- were you planning to get these in for 4.9?
Will
^ permalink raw reply
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-19 8:49 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Russell King - ARM Linux, Herbert Xu,
linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org
In-Reply-To: <20161019084607.GB9193@arm.com>
On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
>> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
>> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> > >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> > >> currently work, or have ever worked correctly when built for big endian. So this
>> > >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> > >> well, and an additional fix for XTS which escaped my attention before.
>> > >>
>> > >> Each of these patches carries a fixes tag, and could be backported to stable.
>> > >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> > >> fix is compatible with, not the patch that introduced the algorithm.
>> > >
>> > > I think for future reference, the Fixes tag should denote the commit
>> > > that introduced the issue. An explicit Cc: stable tag would state how
>> > > far back it should be applied.
>> > >
>> >
>> > OK, that sounds reasonable.
>> >
>> > >> Ard Biesheuvel (8):
>> > >> crypto: arm64/aes-ce - fix for big endian
>> > >> crypto: arm64/ghash-ce - fix for big endian
>> > >> crypto: arm64/sha1-ce - fix for big endian
>> > >> crypto: arm64/sha2-ce - fix for big endian
>> > >> crypto: arm64/aes-ccm-ce: fix for big endian
>> > >> crypto: arm64/aes-neon - fix for big endian
>> > >> crypto: arm64/aes-xts-ce: fix for big endian
>> > >> crypto: arm/aes-ce - fix for big endian
>> > >
>> > > The changes look fine to me but I can't claim I fully understand these
>> > > algorithms. FWIW:
>> > >
>> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> > >
>> > > (Will may pick them up for 4.9-rcX)
>> >
>> > Thanks, although I was kind of expecting Herbert to pick these up,
>> > given that #8 affects ARM not arm64.
>> >
>> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
>> > can drop #8 into rmk's patch database.
>>
>> I was planning merging these for 4.10. But I'm fine with them
>> going through the arm tree. Let me know what you guys want to
>> do.
>
> I assumed you'd take them through crypto, as per usual, so I didn't
> queue anything in the arm64 tree.
>
> Ard -- were you planning to get these in for 4.9?
>
These are arguably bug fixes, but I spotted them by accident, they
weren't reported to me or anything. But it seems strange to add a cc
stable and then hold off until the next merge window.
In any case, I don't care deeply either way, as long as they get
merged in the end. I think it makes sense to keep them together (arm64
+ ARM), so Herbert's tree is a more natural route for them to take. I
will leave it up to Herbert whether they are sent onward as fixes or
as part of v4.10
Thanks,
Ard.
^ permalink raw reply
* Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 9:15 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Catalin Marinas, Russell King - ARM Linux, Herbert Xu,
linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu_A1XOL=yST_isyvMZL=9wUcuiFXdfmOqw7PO5te24Ktw@mail.gmail.com>
On Wed, Oct 19, 2016 at 09:49:46AM +0100, Ard Biesheuvel wrote:
> On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> >> I was planning merging these for 4.10. But I'm fine with them
> >> going through the arm tree. Let me know what you guys want to
> >> do.
> >
> > I assumed you'd take them through crypto, as per usual, so I didn't
> > queue anything in the arm64 tree.
> >
> > Ard -- were you planning to get these in for 4.9?
> >
>
> These are arguably bug fixes, but I spotted them by accident, they
> weren't reported to me or anything. But it seems strange to add a cc
> stable and then hold off until the next merge window.
>
> In any case, I don't care deeply either way, as long as they get
> merged in the end. I think it makes sense to keep them together (arm64
> + ARM), so Herbert's tree is a more natural route for them to take. I
> will leave it up to Herbert whether they are sent onward as fixes or
> as part of v4.10
Sounds good to me.
Will
^ permalink raw reply
* Re: [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Neil Armstrong @ 2016-10-19 9:19 UTC (permalink / raw)
To: Javier Martinez Canillas, linux-kernel
Cc: Herbert Xu, Kevin Hilman, Matt Mackall, Jason Gunthorpe,
linux-crypto, PrasannaKumar Muralidharan, Carlo Caione,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On 10/17/2016 09:51 PM, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v2:
> - Remove unrelated changes added by mistake. Suggested by Jason Gunthorpe.
>
> drivers/char/hw_random/meson-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
> index 58bef39f7286..51864a509be7 100644
> --- a/drivers/char/hw_random/meson-rng.c
> +++ b/drivers/char/hw_random/meson-rng.c
> @@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
> { .compatible = "amlogic,meson-rng", },
> {},
> };
> +MODULE_DEVICE_TABLE(of, meson_rng_of_match);
>
> static struct platform_driver meson_rng_driver = {
> .probe = meson_rng_probe,
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] crypto: engine - Handle the kthread worker using the new API
From: Petr Mladek @ 2016-10-19 11:54 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, linux-crypto, Tejun Heo, linux-kernel,
Petr Mladek
Use the new API to create and destroy the crypto engine kthread
worker. The API hides some implementation details.
In particular, kthread_create_worker() allocates and initializes
struct kthread_worker. It runs the kthread the right way
and stores task_struct into the worker structure.
kthread_destroy_worker() flushes all pending works, stops
the kthread and frees the structure.
This patch does not change the existing behavior except for
dynamically allocating struct kthread_worker and storing
only the pointer of this structure.
It is compile tested only because I did not find an easy
way how to run the code. Well, it should be pretty safe
given the nature of the change.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
crypto/crypto_engine.c | 26 +++++++++++---------------
include/crypto/engine.h | 6 ++----
2 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index 6989ba0046df..f1bf3418d968 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -47,7 +47,7 @@ static void crypto_pump_requests(struct crypto_engine *engine,
/* If another context is idling then defer */
if (engine->idling) {
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
goto out;
}
@@ -58,7 +58,7 @@ static void crypto_pump_requests(struct crypto_engine *engine,
/* Only do teardown in the thread */
if (!in_kthread) {
- kthread_queue_work(&engine->kworker,
+ kthread_queue_work(engine->kworker,
&engine->pump_requests);
goto out;
}
@@ -189,7 +189,7 @@ int crypto_transfer_cipher_request(struct crypto_engine *engine,
ret = ablkcipher_enqueue_request(&engine->queue, req);
if (!engine->busy && need_pump)
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
spin_unlock_irqrestore(&engine->queue_lock, flags);
return ret;
@@ -231,7 +231,7 @@ int crypto_transfer_hash_request(struct crypto_engine *engine,
ret = ahash_enqueue_request(&engine->queue, req);
if (!engine->busy && need_pump)
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
spin_unlock_irqrestore(&engine->queue_lock, flags);
return ret;
@@ -284,7 +284,7 @@ void crypto_finalize_cipher_request(struct crypto_engine *engine,
req->base.complete(&req->base, err);
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
}
EXPORT_SYMBOL_GPL(crypto_finalize_cipher_request);
@@ -321,7 +321,7 @@ void crypto_finalize_hash_request(struct crypto_engine *engine,
req->base.complete(&req->base, err);
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
}
EXPORT_SYMBOL_GPL(crypto_finalize_hash_request);
@@ -345,7 +345,7 @@ int crypto_engine_start(struct crypto_engine *engine)
engine->running = true;
spin_unlock_irqrestore(&engine->queue_lock, flags);
- kthread_queue_work(&engine->kworker, &engine->pump_requests);
+ kthread_queue_work(engine->kworker, &engine->pump_requests);
return 0;
}
@@ -422,11 +422,8 @@ struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
crypto_init_queue(&engine->queue, CRYPTO_ENGINE_MAX_QLEN);
spin_lock_init(&engine->queue_lock);
- kthread_init_worker(&engine->kworker);
- engine->kworker_task = kthread_run(kthread_worker_fn,
- &engine->kworker, "%s",
- engine->name);
- if (IS_ERR(engine->kworker_task)) {
+ engine->kworker = kthread_create_worker(0, "%s", engine->name);
+ if (IS_ERR(engine->kworker)) {
dev_err(dev, "failed to create crypto request pump task\n");
return NULL;
}
@@ -434,7 +431,7 @@ struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
if (engine->rt) {
dev_info(dev, "will run requests pump with realtime priority\n");
- sched_setscheduler(engine->kworker_task, SCHED_FIFO, ¶m);
+ sched_setscheduler(engine->kworker->task, SCHED_FIFO, ¶m);
}
return engine;
@@ -455,8 +452,7 @@ int crypto_engine_exit(struct crypto_engine *engine)
if (ret)
return ret;
- kthread_flush_worker(&engine->kworker);
- kthread_stop(engine->kworker_task);
+ kthread_destroy_worker(engine->kworker);
return 0;
}
diff --git a/include/crypto/engine.h b/include/crypto/engine.h
index 04eb5c77addd..1bf600fc99f7 100644
--- a/include/crypto/engine.h
+++ b/include/crypto/engine.h
@@ -43,8 +43,7 @@
* @prepare_hash_request: do some prepare if need before handle the current request
* @unprepare_hash_request: undo any work done by prepare_hash_request()
* @hash_one_request: do hash for current request
- * @kworker: thread struct for request pump
- * @kworker_task: pointer to task for request pump kworker thread
+ * @kworker: kthread worker struct for request pump
* @pump_requests: work struct for scheduling work to the request pump
* @priv_data: the engine private data
* @cur_req: the current request which is on processing
@@ -78,8 +77,7 @@ struct crypto_engine {
int (*hash_one_request)(struct crypto_engine *engine,
struct ahash_request *req);
- struct kthread_worker kworker;
- struct task_struct *kworker_task;
+ struct kthread_worker *kworker;
struct kthread_work pump_requests;
void *priv_data;
--
1.8.5.6
^ permalink raw reply related
* Re: provide DMA services in drivers/crypto
From: Vinod Koul @ 2016-10-19 14:54 UTC (permalink / raw)
To: Tudor-Dan Ambarus
Cc: herbert@gondor.apana.org.au, dan.j.williams@intel.com,
linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org
In-Reply-To: <DB4PR04MB06561BC01F736652940C004FB8D20@DB4PR04MB0656.eurprd04.prod.outlook.com>
On Wed, Oct 19, 2016 at 01:57:45PM +0000, Tudor-Dan Ambarus wrote:
Please wrap your mails within 80 chars, I have reflown below for reabability.
> Hi, Herbert,
>
> CAAM has the ability to provide DMA services. This is helpful for
> platforms that don't have a dedicated DMA hardware block.
>
> In this particular example, caam being a crypto accelerator at its
> fundamentals, where is recommended to add a caam-dma engine
> implementation, in drivers/dma or in drivers/crypto? Are the any
> rules/guidelines?
If the dma controller is internal to crypto, then it might be okay to be
inside the crypto driver. But if it is shared or common controller then a
dmaengine implementation would make sense..
> I noticed that CCP already registered DMA services, the driver being held
> in drivers/crypto.
I think drivers/crypto/ccp/ccp-dmaengine.c is wrong example, it should have
been in dmaengine directory. Not sure why it was addded in crypto :(
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Javier Martinez Canillas @ 2016-10-19 19:50 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Kevin Hilman, Neil Armstrong,
PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
Herbert Xu, Matt Mackall, linux-arm-kernel, linux-crypto
The Amlogic Meson is a DT-only platform, which means the devices are
registered via OF and not using the legacy platform devices support.
So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
the reported uevent MODALIAS to user-space will always be the OF one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/char/hw_random/meson-rng.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 51864a509be7..119d698439ae 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -122,7 +122,6 @@ static struct platform_driver meson_rng_driver = {
module_platform_driver(meson_rng_driver);
-MODULE_ALIAS("platform:meson-rng");
MODULE_DESCRIPTION("Meson H/W Random Number Generator driver");
MODULE_AUTHOR("Lawrence Mok <lawrence.mok@amlogic.com>");
MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
--
2.7.4
^ 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