* [PATCH 5/6] crypto: talitos - implement cra_priority
From: Christophe Leroy @ 2016-05-27 9:32 UTC (permalink / raw)
To: Kim Phillips, Herbert Xu, David S Miller
Cc: linux-kernel, linuxppc-dev, linux-crypto
In-Reply-To: <cover.1464330501.git.christophe.leroy@c-s.fr>
SEC1 doesn't have IPSEC_ESP descriptor type but it is able to perform
IPSEC using HMAC_SNOOP_NO_AFEU, which is also existing on SEC2
In order to be able to define descriptors templates for SEC1 without
breaking SEC2+, we have to give lower priority to HMAC_SNOOP_NO_AFEU
so that SEC2+ selects IPSEC_ESP and not HMAC_SNOOP_NO_AFEU which is
less performant.
This is done by adding a priority field in the template. If the field
is 0, we use the default priority, otherwise we used the one in the
field.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/crypto/talitos.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index fcdf83b..b554f56 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2103,6 +2103,7 @@ static int ahash_setkey(struct crypto_ahash *tfm, const u8 *key,
struct talitos_alg_template {
u32 type;
+ u32 priority;
union {
struct crypto_alg crypto;
struct ahash_alg hash;
@@ -2880,7 +2881,10 @@ static struct talitos_crypto_alg *talitos_alg_alloc(struct device *dev,
}
alg->cra_module = THIS_MODULE;
- alg->cra_priority = TALITOS_CRA_PRIORITY;
+ if (t_alg->algt.priority)
+ alg->cra_priority = t_alg->algt.priority;
+ else
+ alg->cra_priority = TALITOS_CRA_PRIORITY;
alg->cra_alignmask = 0;
alg->cra_ctxsize = sizeof(struct talitos_ctx);
alg->cra_flags |= CRYPTO_ALG_KERN_DRIVER_ONLY;
--
2.1.0
^ permalink raw reply related
* [PATCH 6/6] crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU
From: Christophe Leroy @ 2016-05-27 9:32 UTC (permalink / raw)
To: Kim Phillips, Herbert Xu, David S Miller
Cc: linux-kernel, linuxppc-dev, linux-crypto
In-Reply-To: <cover.1464330501.git.christophe.leroy@c-s.fr>
This will allow IPSEC on SEC1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/crypto/talitos.c | 180 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 180 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b554f56..d3951e3 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -811,6 +811,11 @@ static void talitos_unregister_rng(struct device *dev)
* crypto alg
*/
#define TALITOS_CRA_PRIORITY 3000
+/*
+ * Defines a priority for doing AEAD with descriptors type
+ * HMAC_SNOOP_NO_AFEA (HSNA) instead of type IPSEC_ESP
+ */
+#define TALITOS_CRA_PRIORITY_AEAD_HSNA (TALITOS_CRA_PRIORITY - 1)
#define TALITOS_MAX_KEY_SIZE 96
#define TALITOS_MAX_IV_LENGTH 16 /* max of AES_BLOCK_SIZE, DES3_EDE_BLOCK_SIZE */
@@ -2135,6 +2140,27 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_SHA1_HMAC,
},
{ .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha1),cbc(aes))",
+ .cra_driver_name = "authenc-hmac-sha1-"
+ "cbc-aes-talitos",
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = SHA1_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_CBC |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA1_HMAC,
+ },
+ { .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
.cra_name = "authenc(hmac(sha1),"
@@ -2156,6 +2182,29 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_PAD |
DESC_HDR_MODE1_MDEU_SHA1_HMAC,
},
+ { .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha1),"
+ "cbc(des3_ede))",
+ .cra_driver_name = "authenc-hmac-sha1-"
+ "cbc-3des-talitos",
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .maxauthsize = SHA1_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_DEU |
+ DESC_HDR_MODE0_DEU_CBC |
+ DESC_HDR_MODE0_DEU_3DES |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA1_HMAC,
+ },
{ .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
@@ -2176,6 +2225,27 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_PAD |
DESC_HDR_MODE1_MDEU_SHA224_HMAC,
},
+ { .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha224),cbc(aes))",
+ .cra_driver_name = "authenc-hmac-sha224-"
+ "cbc-aes-talitos",
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = SHA224_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_CBC |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA224_HMAC,
+ },
{ .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
@@ -2199,6 +2269,29 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_SHA224_HMAC,
},
{ .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha224),"
+ "cbc(des3_ede))",
+ .cra_driver_name = "authenc-hmac-sha224-"
+ "cbc-3des-talitos",
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .maxauthsize = SHA224_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_DEU |
+ DESC_HDR_MODE0_DEU_CBC |
+ DESC_HDR_MODE0_DEU_3DES |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA224_HMAC,
+ },
+ { .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
.cra_name = "authenc(hmac(sha256),cbc(aes))",
@@ -2219,6 +2312,27 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_SHA256_HMAC,
},
{ .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha256),cbc(aes))",
+ .cra_driver_name = "authenc-hmac-sha256-"
+ "cbc-aes-talitos",
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = SHA256_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_CBC |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA256_HMAC,
+ },
+ { .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
.cra_name = "authenc(hmac(sha256),"
@@ -2241,6 +2355,29 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_SHA256_HMAC,
},
{ .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha256),"
+ "cbc(des3_ede))",
+ .cra_driver_name = "authenc-hmac-sha256-"
+ "cbc-3des-talitos",
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .maxauthsize = SHA256_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_DEU |
+ DESC_HDR_MODE0_DEU_CBC |
+ DESC_HDR_MODE0_DEU_3DES |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_SHA256_HMAC,
+ },
+ { .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
.cra_name = "authenc(hmac(sha384),cbc(aes))",
@@ -2345,6 +2482,27 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_MD5_HMAC,
},
{ .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(md5),cbc(aes))",
+ .cra_driver_name = "authenc-hmac-md5-"
+ "cbc-aes-talitos",
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = MD5_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_CBC |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_MD5_HMAC,
+ },
+ { .type = CRYPTO_ALG_TYPE_AEAD,
.alg.aead = {
.base = {
.cra_name = "authenc(hmac(md5),cbc(des3_ede))",
@@ -2365,6 +2523,28 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE1_MDEU_PAD |
DESC_HDR_MODE1_MDEU_MD5_HMAC,
},
+ { .type = CRYPTO_ALG_TYPE_AEAD,
+ .priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(md5),cbc(des3_ede))",
+ .cra_driver_name = "authenc-hmac-md5-"
+ "cbc-3des-talitos",
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ },
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .maxauthsize = MD5_DIGEST_SIZE,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
+ DESC_HDR_SEL0_DEU |
+ DESC_HDR_MODE0_DEU_CBC |
+ DESC_HDR_MODE0_DEU_3DES |
+ DESC_HDR_SEL1_MDEUA |
+ DESC_HDR_MODE1_MDEU_INIT |
+ DESC_HDR_MODE1_MDEU_PAD |
+ DESC_HDR_MODE1_MDEU_MD5_HMAC,
+ },
/* ABLKCIPHER algorithms. */
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
--
2.1.0
^ permalink raw reply related
* [PATCH v2 0/4] hw rng support for NSP SoC
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-27 10:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
This patchset contains the hw random number generator support for the
Broadcom's NSP SoC. The block is similar to the block available in
bcm2835 with different default interrupt mask value. Due to lack of
documentation, I cannot confirm the interrupt mask register details
in bcm2835. In an effort to not break the existing functionality of
bcm2835, I used a different compatible string to mask the interrupt
for NSP SoC. Please let me know. Also supported providing requested
number of random numbers instead of static size of four bytes.
The first patch contains the documentation changes and the second patch
contains the support for rng available in NSP SoC. The third patch
contains the device tree changes for NSP SoC. The fourth patch contains
the support for reading requested number of random numbers.
This patch set has been tested on NSP bcm958625HR board.
This patch set is based on v4.6.0-rc1 and is available from github
repo: https://github.com/Broadcom/cygnus-linux.git
branch: nsp-rng-v2
Changes since v1
Addressed the review comments from Eric
Added acked by Eric
Yendapally Reddy Dhananjaya Reddy (4):
dt-bindings: rng: Northstar Plus SoC rng bindings
hwrng: bcm2835: Support Broadcom NSP SoC rng
ARM: dts: nsp: Add rng device tree entry
hwrng: bcm2835: Read as much data as available
.../devicetree/bindings/rng/brcm,bcm2835.txt | 7 +++-
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +++
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rng.c | 46 +++++++++++++++++++---
4 files changed, 52 insertions(+), 8 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-27 10:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464343841-29504-1-git-send-email-yendapally.reddy@broadcom.com>
Document the bindings used by Northstar Plus(NSP) SoC random number
generator.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Acked-by: Eric Anholt <eric@anholt.net>
---
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
index 07ccdaa..aa304d4 100644
--- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -2,7 +2,7 @@ BCM2835 Random number generator
Required properties:
-- compatible : should be "brcm,bcm2835-rng"
+- compatible : should be "brcm,bcm2835-rng" or "brcm,bcm-nsp-rng"
- reg : Specifies base physical address and size of the registers.
Example:
@@ -11,3 +11,8 @@ rng {
compatible = "brcm,bcm2835-rng";
reg = <0x7e104000 0x10>;
};
+
+rng@18033000 {
+ compatible = "brcm,bcm-nsp-rng";
+ reg = <0x18033000 0x14>;
+};
--
2.1.0
^ permalink raw reply related
* [PATCH v2 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-27 10:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464343841-29504-1-git-send-email-yendapally.reddy@broadcom.com>
This supports the random number generator available in NSP SoC.
Masks the rng interrupt for NSP.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Acked-by: Eric Anholt <eric@anholt.net>
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rng.c | 34 ++++++++++++++++++++++++++++++----
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 67ee8b0..f8d1a2b 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -90,7 +90,7 @@ config HW_RANDOM_BCM63XX
config HW_RANDOM_BCM2835
tristate "Broadcom BCM2835 Random Number Generator support"
- depends on ARCH_BCM2835
+ depends on ARCH_BCM2835 || ARCH_BCM_NSP
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index 7192ec2..b1e8b78 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -19,6 +19,7 @@
#define RNG_CTRL 0x0
#define RNG_STATUS 0x4
#define RNG_DATA 0x8
+#define RNG_INT_MASK 0x10
/* enable rng */
#define RNG_RBGEN 0x1
@@ -26,6 +27,18 @@
/* the initial numbers generated are "less random" so will be discarded */
#define RNG_WARMUP_COUNT 0x40000
+#define RNG_INT_OFF 0x1
+
+static void __init nsp_rng_init(void __iomem *base)
+{
+ u32 val;
+
+ /* mask the interrupt */
+ val = readl(base + RNG_INT_MASK);
+ val |= RNG_INT_OFF;
+ writel(val, base + RNG_INT_MASK);
+}
+
static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
bool wait)
{
@@ -46,10 +59,18 @@ static struct hwrng bcm2835_rng_ops = {
.read = bcm2835_rng_read,
};
+static const struct of_device_id bcm2835_rng_of_match[] = {
+ { .compatible = "brcm,bcm2835-rng"},
+ { .compatible = "brcm,bcm-nsp-rng", .data = nsp_rng_init},
+ {},
+};
+
static int bcm2835_rng_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
+ void (*rng_setup)(void __iomem *base);
+ const struct of_device_id *rng_id;
void __iomem *rng_base;
int err;
@@ -61,6 +82,15 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
}
bcm2835_rng_ops.priv = (unsigned long)rng_base;
+ rng_id = of_match_node(bcm2835_rng_of_match, np);
+ if (!rng_id)
+ return -EINVAL;
+
+ /* Check for rng init function, execute it */
+ rng_setup = rng_id->data;
+ if (rng_setup)
+ rng_setup(rng_base);
+
/* set warm-up count & enable */
__raw_writel(RNG_WARMUP_COUNT, rng_base + RNG_STATUS);
__raw_writel(RNG_RBGEN, rng_base + RNG_CTRL);
@@ -90,10 +120,6 @@ static int bcm2835_rng_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id bcm2835_rng_of_match[] = {
- { .compatible = "brcm,bcm2835-rng", },
- {},
-};
MODULE_DEVICE_TABLE(of, bcm2835_rng_of_match);
static struct platform_driver bcm2835_rng_driver = {
--
2.1.0
^ permalink raw reply related
* [PATCH v2 4/4] hwrng: bcm2835: Read as much data as available
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-27 10:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464343841-29504-1-git-send-email-yendapally.reddy@broadcom.com>
Read the requested number of data from the fifo
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
---
drivers/char/hw_random/bcm2835-rng.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index b1e8b78..75ca820 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -43,6 +43,8 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
bool wait)
{
void __iomem *rng_base = (void __iomem *)rng->priv;
+ u32 max_words = max / sizeof(u32);
+ u32 num_words, count;
while ((__raw_readl(rng_base + RNG_STATUS) >> 24) == 0) {
if (!wait)
@@ -50,8 +52,14 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
cpu_relax();
}
- *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
- return sizeof(u32);
+ num_words = readl(rng_base + RNG_STATUS) >> 24;
+ if (num_words > max_words)
+ num_words = max_words;
+
+ for (count = 0; count < num_words; count++)
+ ((u32 *)buf)[count] = readl(rng_base + RNG_DATA);
+
+ return num_words * sizeof(u32);
}
static struct hwrng bcm2835_rng_ops = {
--
2.1.0
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: nsp: Add rng device tree entry
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-27 10:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464343841-29504-1-git-send-email-yendapally.reddy@broadcom.com>
Add support for the random number generator to the Northstar Plus
SoC device tree.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index def9e78..1ed829e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -206,6 +206,11 @@
brcm,nand-has-wp;
};
+ rng: rng@33000 {
+ compatible = "brcm,bcm-nsp-rng";
+ reg = <0x33000 0x14>;
+ };
+
ccbtimer0: timer@34000 {
compatible = "arm,sp804";
reg = <0x34000 0x1000>;
--
2.1.0
^ permalink raw reply related
* [RFC v2 0/3] Introduce the bulk mode method when sending request to crypto layer
From: Baolin Wang @ 2016-05-27 11:11 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode. For bulk mode, we can use sg table to map the whole bio and
send all scatterlists of one bio to crypto engine to encrypt or decrypt,
which can improve the hardware engine's efficiency.
As Milan pointed out we need one driver with using the new 'CRYPTO_ALG_BULK'
flag, I'll add one cipher engine driver with 'CRYPTO_ALG_BULK' flag to test
this optimization in next version, if I am sure this optimization is on the
right direction according to your comments.
Looking forward to any comments and suggestions. Thanks.
Changes since v1:
- Refactor the blk_bio_map_sg() function to avoid duplicated code.
- Move the sg table allocation to crypt_ctr_cipher() function to avoid memory
allocation in the IO path.
- Remove the crypt_sg_entry() function.
- Other optimization.
Baolin Wang (3):
block: Introduce blk_bio_map_sg() to map one bio
crypto: Introduce CRYPTO_ALG_BULK flag
md: dm-crypt: Introduce the bulk mode method when sending request
block/blk-merge.c | 36 +++++++++--
drivers/md/dm-crypt.c | 145 ++++++++++++++++++++++++++++++++++++++++++++-
include/crypto/skcipher.h | 7 +++
include/linux/blkdev.h | 2 +
include/linux/crypto.h | 6 ++
5 files changed, 190 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-05-27 11:11 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464346333.git.baolin.wang@linaro.org>
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.
So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
mode.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/crypto/skcipher.h | 7 +++++++
include/linux/crypto.h | 6 ++++++
2 files changed, 13 insertions(+)
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 0f987f5..d89d29a 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -519,5 +519,12 @@ static inline void skcipher_request_set_crypt(
req->iv = iv;
}
+static inline unsigned int skcipher_is_bulk_mode(struct crypto_skcipher *sk_tfm)
+{
+ struct crypto_tfm *tfm = crypto_skcipher_tfm(sk_tfm);
+
+ return crypto_tfm_alg_bulk(tfm);
+}
+
#endif /* _CRYPTO_SKCIPHER_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..a315487 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -63,6 +63,7 @@
#define CRYPTO_ALG_DEAD 0x00000020
#define CRYPTO_ALG_DYING 0x00000040
#define CRYPTO_ALG_ASYNC 0x00000080
+#define CRYPTO_ALG_BULK 0x00000100
/*
* Set this bit if and only if the algorithm requires another algorithm of
@@ -623,6 +624,11 @@ static inline u32 crypto_tfm_alg_type(struct crypto_tfm *tfm)
return tfm->__crt_alg->cra_flags & CRYPTO_ALG_TYPE_MASK;
}
+static inline unsigned int crypto_tfm_alg_bulk(struct crypto_tfm *tfm)
+{
+ return tfm->__crt_alg->cra_flags & CRYPTO_ALG_BULK;
+}
+
static inline unsigned int crypto_tfm_alg_blocksize(struct crypto_tfm *tfm)
{
return tfm->__crt_alg->cra_blocksize;
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 3/3] md: dm-crypt: Introduce the bulk mode method when sending request
From: Baolin Wang @ 2016-05-27 11:11 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464346333.git.baolin.wang@linaro.org>
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.
With this optimization, On my test setup (beaglebone black board) using 64KB
I/Os on an eMMC storage device I saw about 60% improvement in throughput for
encrypted writes, and about 100% improvement for encrypted reads. But this
is not fit for other modes which need different IV for each sector.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/md/dm-crypt.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 144 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb35..2101f35 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -33,6 +33,7 @@
#include <linux/device-mapper.h>
#define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 1024
/*
* context holding the current state of a multi-part conversion
@@ -142,6 +143,9 @@ struct crypt_config {
char *cipher;
char *cipher_string;
+ struct sg_table sgt_in;
+ struct sg_table sgt_out;
+
struct crypt_iv_operations *iv_gen_ops;
union {
struct iv_essiv_private essiv;
@@ -837,6 +841,129 @@ static u8 *iv_of_dmreq(struct crypt_config *cc,
crypto_skcipher_alignmask(any_tfm(cc)) + 1);
}
+static void crypt_init_sg_table(struct scatterlist *sgl)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, DM_MAX_SG_LIST, i) {
+ if (i < DM_MAX_SG_LIST - 1 && sg_is_last(sg))
+ sg_unmark_end(sg);
+ else if (i == DM_MAX_SG_LIST - 1)
+ sg_mark_end(sg);
+ }
+
+ for_each_sg(sgl, sg, DM_MAX_SG_LIST, i) {
+ memset(sg, 0, sizeof(struct scatterlist));
+
+ if (i == DM_MAX_SG_LIST - 1)
+ sg_mark_end(sg);
+ }
+}
+
+static void crypt_reinit_sg_table(struct crypt_config *cc)
+{
+ if (!cc->sgt_in.orig_nents || !cc->sgt_out.orig_nents)
+ return;
+
+ crypt_init_sg_table(cc->sgt_in.sgl);
+ crypt_init_sg_table(cc->sgt_out.sgl);
+}
+
+static int crypt_alloc_sg_table(struct crypt_config *cc)
+{
+ unsigned int bulk_mode = skcipher_is_bulk_mode(any_tfm(cc));
+ int ret = 0;
+
+ if (!bulk_mode)
+ goto out_skip_alloc;
+
+ ret = sg_alloc_table(&cc->sgt_in, DM_MAX_SG_LIST, GFP_KERNEL);
+ if (ret)
+ goto out_skip_alloc;
+
+ ret = sg_alloc_table(&cc->sgt_out, DM_MAX_SG_LIST, GFP_KERNEL);
+ if (ret)
+ goto out_free_table;
+
+ return 0;
+
+out_free_table:
+ sg_free_table(&cc->sgt_in);
+out_skip_alloc:
+ cc->sgt_in.orig_nents = 0;
+ cc->sgt_out.orig_nents = 0;
+
+ return ret;
+}
+
+static int crypt_convert_bulk_block(struct crypt_config *cc,
+ struct convert_context *ctx,
+ struct skcipher_request *req)
+{
+ struct bio *bio_in = ctx->bio_in;
+ struct bio *bio_out = ctx->bio_out;
+ unsigned int total_bytes = bio_in->bi_iter.bi_size;
+ unsigned int total_sg_in, total_sg_out;
+ struct scatterlist *sg_in, *sg_out;
+ struct dm_crypt_request *dmreq;
+ u8 *iv;
+ int r;
+
+ if (!cc->sgt_in.orig_nents || !cc->sgt_out.orig_nents)
+ return -EINVAL;
+
+ dmreq = dmreq_of_req(cc, req);
+ iv = iv_of_dmreq(cc, dmreq);
+ dmreq->iv_sector = ctx->cc_sector;
+ dmreq->ctx = ctx;
+
+ total_sg_in = blk_bio_map_sg(bdev_get_queue(bio_in->bi_bdev),
+ bio_in, cc->sgt_in.sgl);
+ if ((total_sg_in <= 0) || (total_sg_in > DM_MAX_SG_LIST)) {
+ DMERR("%s in sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_in, cc->sgt_in.orig_nents);
+ return -EINVAL;
+ }
+
+ ctx->iter_in.bi_size -= total_bytes;
+ sg_in = cc->sgt_in.sgl;
+ sg_out = cc->sgt_in.sgl;
+
+ if (bio_data_dir(bio_in) == READ)
+ goto set_crypt;
+
+ total_sg_out = blk_bio_map_sg(bdev_get_queue(bio_out->bi_bdev),
+ bio_out, cc->sgt_out.sgl);
+ if ((total_sg_out <= 0) || (total_sg_out > DM_MAX_SG_LIST)) {
+ DMERR("%s out sg map error %d, sg table nents[%d]\n",
+ __func__, total_sg_out, cc->sgt_out.orig_nents);
+ return -EINVAL;
+ }
+
+ ctx->iter_out.bi_size -= total_bytes;
+ sg_out = cc->sgt_out.sgl;
+
+set_crypt:
+ if (cc->iv_gen_ops) {
+ r = cc->iv_gen_ops->generator(cc, iv, dmreq);
+ if (r < 0)
+ return r;
+ }
+
+ skcipher_request_set_crypt(req, sg_in, sg_out, total_bytes, iv);
+
+ if (bio_data_dir(ctx->bio_in) == WRITE)
+ r = crypto_skcipher_encrypt(req);
+ else
+ r = crypto_skcipher_decrypt(req);
+
+ if (!r && cc->iv_gen_ops && cc->iv_gen_ops->post)
+ r = cc->iv_gen_ops->post(cc, iv, dmreq);
+
+ return r;
+}
+
static int crypt_convert_block(struct crypt_config *cc,
struct convert_context *ctx,
struct skcipher_request *req)
@@ -920,6 +1047,7 @@ static void crypt_free_req(struct crypt_config *cc,
static int crypt_convert(struct crypt_config *cc,
struct convert_context *ctx)
{
+ unsigned int bulk_mode;
int r;
atomic_set(&ctx->cc_pending, 1);
@@ -930,7 +1058,14 @@ static int crypt_convert(struct crypt_config *cc,
atomic_inc(&ctx->cc_pending);
- r = crypt_convert_block(cc, ctx, ctx->req);
+ bulk_mode = skcipher_is_bulk_mode(any_tfm(cc));
+ if (!bulk_mode) {
+ r = crypt_convert_block(cc, ctx, ctx->req);
+ } else {
+ r = crypt_convert_bulk_block(cc, ctx, ctx->req);
+ if (r == -EINVAL)
+ r = crypt_convert_block(cc, ctx, ctx->req);
+ }
switch (r) {
/*
@@ -1081,6 +1216,7 @@ static void crypt_dec_pending(struct dm_crypt_io *io)
if (io->ctx.req)
crypt_free_req(cc, io->ctx.req, base_bio);
+ crypt_reinit_sg_table(cc);
base_bio->bi_error = error;
bio_endio(base_bio);
}
@@ -1563,6 +1699,9 @@ static void crypt_dtr(struct dm_target *ti)
kzfree(cc->cipher);
kzfree(cc->cipher_string);
+ sg_free_table(&cc->sgt_in);
+ sg_free_table(&cc->sgt_out);
+
/* Must zero key material before freeing */
kzfree(cc);
}
@@ -1718,6 +1857,10 @@ static int crypt_ctr_cipher(struct dm_target *ti,
}
}
+ ret = crypt_alloc_sg_table(cc);
+ if (ret)
+ DMWARN("Allocate sg table for bulk mode failed");
+
ret = 0;
bad:
kfree(cipher_api);
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 1/3] block: Introduce blk_bio_map_sg() to map one bio
From: Baolin Wang @ 2016-05-27 11:11 UTC (permalink / raw)
To: axboe, agk, snitzer, dm-devel, herbert, davem
Cc: ebiggers3, js1304, tadeusz.struk, smueller, standby24x7, shli,
dan.j.williams, martin.petersen, sagig, kent.overstreet,
keith.busch, tj, ming.lei, broonie, arnd, linux-crypto,
linux-block, linux-raid, linux-kernel, baolin.wang
In-Reply-To: <cover.1464346333.git.baolin.wang@linaro.org>
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
For avoiding the duplicated code in __blk_bios_map_sg() function, add
one parameter to distinguish bio map or request map.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
block/blk-merge.c | 36 +++++++++++++++++++++++++++++++-----
include/linux/blkdev.h | 2 ++
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..badae44 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -376,7 +376,7 @@ new_segment:
static int __blk_bios_map_sg(struct request_queue *q, struct bio *bio,
struct scatterlist *sglist,
- struct scatterlist **sg)
+ struct scatterlist **sg, bool single_bio)
{
struct bio_vec bvec, bvprv = { NULL };
struct bvec_iter iter;
@@ -408,13 +408,39 @@ single_segment:
return 1;
}
- for_each_bio(bio)
+ if (!single_bio) {
+ for_each_bio(bio)
+ bio_for_each_segment(bvec, bio, iter)
+ __blk_segment_map_sg(q, &bvec, sglist, &bvprv,
+ sg, &nsegs, &cluster);
+ } else {
bio_for_each_segment(bvec, bio, iter)
- __blk_segment_map_sg(q, &bvec, sglist, &bvprv, sg,
- &nsegs, &cluster);
+ __blk_segment_map_sg(q, &bvec, sglist, &bvprv,
+ sg, &nsegs, &cluster);
+ }
+
+ return nsegs;
+}
+
+/*
+ * Map a bio to scatterlist, return number of sg entries setup. Caller must
+ * make sure sg can hold bio segments entries.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist)
+{
+ struct scatterlist *sg = NULL;
+ int nsegs = 0;
+
+ if (bio)
+ nsegs = __blk_bios_map_sg(q, bio, sglist, &sg, true);
+
+ if (sg)
+ sg_mark_end(sg);
return nsegs;
}
+EXPORT_SYMBOL(blk_bio_map_sg);
/*
* map a request to scatterlist, return number of sg entries setup. Caller
@@ -427,7 +453,7 @@ int blk_rq_map_sg(struct request_queue *q, struct request *rq,
int nsegs = 0;
if (rq->bio)
- nsegs = __blk_bios_map_sg(q, rq->bio, sglist, &sg);
+ nsegs = __blk_bios_map_sg(q, rq->bio, sglist, &sg, false);
if (unlikely(rq->cmd_flags & REQ_COPY_USER) &&
(blk_rq_bytes(rq) & q->dma_pad_mask)) {
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1fd8fdf..5868062 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1013,6 +1013,8 @@ extern void blk_queue_write_cache(struct request_queue *q, bool enabled, bool fu
extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device *bdev);
extern int blk_rq_map_sg(struct request_queue *, struct request *, struct scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist);
extern void blk_dump_rq_flags(struct request *, char *);
extern long nr_blockdev_pages(void);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] crypto: s5p-sss - Use consistent indentation for variables and members
From: Krzysztof Kozlowski @ 2016-05-27 11:49 UTC (permalink / raw)
To: Herbert Xu, davem, Vladimir Zapolskiy, linux-crypto, linux-kernel,
linux-samsung-soc
Cc: Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
Bring some consistency by:
1. Replacing fixed-space indentation of structure members with just
tabs.
2. Remove indentation in declaration of local variable between type and
name. Driver was mixing usage of such indentation and lack of it.
When removing indentation, reorder variables in
reversed-christmas-tree order with first variables being initialized
ones.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
drivers/crypto/s5p-sss.c | 80 ++++++++++++++++++++++++------------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 2b3a0cfe3331..dce1af0ce85c 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -155,43 +155,43 @@
* expansion of its usage.
*/
struct samsung_aes_variant {
- unsigned int aes_offset;
+ unsigned int aes_offset;
};
struct s5p_aes_reqctx {
- unsigned long mode;
+ unsigned long mode;
};
struct s5p_aes_ctx {
- struct s5p_aes_dev *dev;
+ struct s5p_aes_dev *dev;
- uint8_t aes_key[AES_MAX_KEY_SIZE];
- uint8_t nonce[CTR_RFC3686_NONCE_SIZE];
- int keylen;
+ uint8_t aes_key[AES_MAX_KEY_SIZE];
+ uint8_t nonce[CTR_RFC3686_NONCE_SIZE];
+ int keylen;
};
struct s5p_aes_dev {
- struct device *dev;
- struct clk *clk;
- void __iomem *ioaddr;
- void __iomem *aes_ioaddr;
- int irq_fc;
+ struct device *dev;
+ struct clk *clk;
+ void __iomem *ioaddr;
+ void __iomem *aes_ioaddr;
+ int irq_fc;
- struct ablkcipher_request *req;
- struct s5p_aes_ctx *ctx;
- struct scatterlist *sg_src;
- struct scatterlist *sg_dst;
+ struct ablkcipher_request *req;
+ struct s5p_aes_ctx *ctx;
+ struct scatterlist *sg_src;
+ struct scatterlist *sg_dst;
/* In case of unaligned access: */
- struct scatterlist *sg_src_cpy;
- struct scatterlist *sg_dst_cpy;
+ struct scatterlist *sg_src_cpy;
+ struct scatterlist *sg_dst_cpy;
- struct tasklet_struct tasklet;
- struct crypto_queue queue;
- bool busy;
- spinlock_t lock;
+ struct tasklet_struct tasklet;
+ struct crypto_queue queue;
+ bool busy;
+ spinlock_t lock;
- struct samsung_aes_variant *variant;
+ struct samsung_aes_variant *variant;
};
static struct s5p_aes_dev *s5p_dev;
@@ -421,11 +421,11 @@ static bool s5p_aes_rx(struct s5p_aes_dev *dev)
static irqreturn_t s5p_aes_interrupt(int irq, void *dev_id)
{
struct platform_device *pdev = dev_id;
- struct s5p_aes_dev *dev = platform_get_drvdata(pdev);
- uint32_t status;
- unsigned long flags;
- bool set_dma_tx = false;
- bool set_dma_rx = false;
+ struct s5p_aes_dev *dev = platform_get_drvdata(pdev);
+ bool set_dma_tx = false;
+ bool set_dma_rx = false;
+ unsigned long flags;
+ uint32_t status;
spin_lock_irqsave(&dev->lock, flags);
@@ -538,10 +538,10 @@ static int s5p_set_outdata_start(struct s5p_aes_dev *dev,
static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode)
{
- struct ablkcipher_request *req = dev->req;
- uint32_t aes_control;
- int err;
- unsigned long flags;
+ struct ablkcipher_request *req = dev->req;
+ uint32_t aes_control;
+ unsigned long flags;
+ int err;
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
@@ -653,10 +653,10 @@ exit:
static int s5p_aes_crypt(struct ablkcipher_request *req, unsigned long mode)
{
- struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
- struct s5p_aes_ctx *ctx = crypto_ablkcipher_ctx(tfm);
- struct s5p_aes_reqctx *reqctx = ablkcipher_request_ctx(req);
- struct s5p_aes_dev *dev = ctx->dev;
+ struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
+ struct s5p_aes_reqctx *reqctx = ablkcipher_request_ctx(req);
+ struct s5p_aes_ctx *ctx = crypto_ablkcipher_ctx(tfm);
+ struct s5p_aes_dev *dev = ctx->dev;
if (!IS_ALIGNED(req->nbytes, AES_BLOCK_SIZE)) {
dev_err(dev->dev, "request size is not exact amount of AES blocks\n");
@@ -671,7 +671,7 @@ static int s5p_aes_crypt(struct ablkcipher_request *req, unsigned long mode)
static int s5p_aes_setkey(struct crypto_ablkcipher *cipher,
const uint8_t *key, unsigned int keylen)
{
- struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
+ struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
struct s5p_aes_ctx *ctx = crypto_tfm_ctx(tfm);
if (keylen != AES_KEYSIZE_128 &&
@@ -763,11 +763,11 @@ static struct crypto_alg algs[] = {
static int s5p_aes_probe(struct platform_device *pdev)
{
- int i, j, err = -ENODEV;
- struct s5p_aes_dev *pdata;
- struct device *dev = &pdev->dev;
- struct resource *res;
+ struct device *dev = &pdev->dev;
+ int i, j, err = -ENODEV;
struct samsung_aes_variant *variant;
+ struct s5p_aes_dev *pdata;
+ struct resource *res;
if (s5p_dev)
return -EEXIST;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Sudip Mukherjee @ 2016-05-27 9:00 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: linux-crypto, linux-kernel, Herbert Xu, Maxime Coquelin,
Matt Mackall
In-Reply-To: <7211115.EdoBLRGZ1i@wuerfel>
On Wednesday 25 May 2016 03:36 PM, Arnd Bergmann wrote:
> On Wednesday, May 25, 2016 7:35:17 AM CEST Sudip Mukherjee wrote:
>> On Tuesday 24 May 2016 02:05 AM, Arnd Bergmann wrote:
>>> On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
>>>> We have been getting build warning about:
>>>> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
>>>> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
>>>> uninitialized in this function
>>>>
>>>> On checking the code it turns out that sr can never be used
>>>> uninitialized as sr is getting initialized in the while loop and while
>>>> loop will always execute as the minimum value of max can be 32.
>>>> So just initialize sr to 0 while declaring it to silence the compiler.
>>>>
>>>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>>>> ---
>>>
>snip>
>
> BTW, regarding your build infrastructure, I'd also recommend building
> with 'make -s' to make the output more compact.
travis is having a timeout and if there is no output from the build
within a time limit then it will cancel the build. I can use the option
if i can increase the timeout limit. I will have a look at the options.
Thanks for the idea.
Regards
Sudip
^ permalink raw reply
* Re: [PATCH] hwrng: stm32: fix maybe uninitialized variable warning
From: Daniel Thompson @ 2016-05-27 13:46 UTC (permalink / raw)
To: Maxime Coquelin, Matt Mackall, Herbert Xu, Sudip Mukherjee,
Arnd Bergmann
Cc: linux-kernel, linux-crypto, linux-arm-kernel
In-Reply-To: <1464255297-21090-1-git-send-email-mcoquelin.stm32@gmail.com>
On 26/05/16 10:34, Maxime Coquelin wrote:
> This patch fixes the following warning:
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> uninitialized in this function
>
> Reported-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
> drivers/char/hw_random/stm32-rng.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..63d84e6f1891 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -69,8 +69,12 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> }
>
> /* If error detected or data not ready... */
> - if (sr != RNG_SR_DRDY)
> + if (sr != RNG_SR_DRDY) {
> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + "bad RNG status - %x\n", sr))
> + writel_relaxed(0, priv->base + RNG_SR);
> break;
> + }
>
> *(u32 *)data = readl_relaxed(priv->base + RNG_DR);
>
> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> max -= sizeof(u32);
> }
>
> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> - "bad RNG status - %x\n", sr))
> - writel_relaxed(0, priv->base + RNG_SR);
> -
> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
>
>
^ permalink raw reply
* Could this be applied to random(4)?
From: Sandy Harris @ 2016-05-27 17:38 UTC (permalink / raw)
To: linux-crypto; +Cc: Theodore Ts'o, Stephan Mueller, John Denker
A theoretical paper on getting provably excellent randomness from two
relatively weak input sources.
https://www.sciencenews.org/article/new-technique-produces-real-randomness
^ permalink raw reply
* Re: Could this be applied to random(4)?
From: Stephan Mueller @ 2016-05-27 18:30 UTC (permalink / raw)
To: Sandy Harris; +Cc: linux-crypto, Theodore Ts'o, John Denker
In-Reply-To: <CACXcFm=Feh_V_AMMYwdAjx4SiVh1eSeQnu1eujjv4S6-LD9Pag@mail.gmail.com>
Am Freitag, 27. Mai 2016, 13:38:05 schrieb Sandy Harris:
Hi Sandy,
> A theoretical paper on getting provably excellent randomness from two
> relatively weak input sources.
> https://www.sciencenews.org/article/new-technique-produces-real-randomness
This document describes extractors. Those extractors are intended to combine
*independent* sources with weak entropy.
None of our sources we have in add_*_randomness are independent.
In addition, I am not sure why this research is so hyped. I think that the 3-
source extractor described in [1] is more efficient and easier to implement
[1] "Extracting Randomness Using Few Independent Sources" by Boaz Barak,
Russell Impagliazzo, Avi Wigderson
Ciao
Stephan
^ permalink raw reply
* Re: Could this be applied to random(4)?
From: Sandy Harris @ 2016-05-27 20:09 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto, Theodore Ts'o, John Denker
In-Reply-To: <1536831.omfD4HBPSy@tauon.atsec.com>
On Fri, May 27, 2016 at 2:30 PM, Stephan Mueller <smueller@chronox.de> wrote:
> This document describes extractors. Those extractors are intended to combine
> *independent* sources with weak entropy.
>
> None of our sources we have in add_*_randomness are independent.
No, but it would be easy to get two independent sources, interrupts
and some sort of timer jitter thing as in my maxwell, your jitter
driver, havege, ...
^ permalink raw reply
* Re: AES-NI: slower than aes-generic?
From: Jeffrey Walton @ 2016-05-27 20:40 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-crypto
In-Reply-To: <20160527021429.GA21331@thunk.org>
> If we implement something which happens to result in a 2 minute stall
> in boot times, the danger is that a clueless engineer at Sony, or LGE,
> or Motorola, or BMW, or Toyota, etc, will "fix" the problem without
> telling anyone about what they did, and we might not notice right away
> that the fix was in fact catastrophically bad.
This is an non-trivial threat. +1 for recognizing it.
I know of one VM hypervisor used in US Financial that was effectively
doing "One thing you should not do is the following..." from
http://lwn.net/Articles/525459/.
Jeff
^ permalink raw reply
* Re: AES-NI: slower than aes-generic?
From: Aaron Zauner @ 2016-05-28 0:28 UTC (permalink / raw)
To: Stephan Mueller
Cc: Sandy Harris, Stephan Mueller, linux-crypto, Theodore Ts'o
In-Reply-To: <4972668.UQ1QRNriDb@positron.chronox.de>
[-- Attachment #1: Type: text/plain, Size: 4103 bytes --]
Heya,
> On 27 May 2016, at 01:49, Stephan Mueller <smueller@chronox.de> wrote:
> Then, the use of the DRBG offers users to choose between a Hash/HMAC and CTR
> implementation to suit their needs. The DRBG code is agnostic of the
> underlying cipher. So, you could even use Blowfish instead of AES or whirlpool
> instead of SHA -- these changes are just one entry in drbg_cores[] away
> without any code change.
That's a really nice change and something I've been thinking about for a couple of months as well. Then I came across tytso's ChaCha patches to urandom and was thinking ISA dependent switches between ciphers would make sense, i.e. you get AESNI performance when there's support.
> Finally, the LRNG code is completely agnostic of the underlying deterministic
> RNG. You only need a replacement of two small functions to invoke the seeding
> and generate operation of a DRNG. So, if one wants a Chacha20, he can have it.
> If one wants X9.31, he can have it. See section 2.8.3 [1] -- note, that DRNG
> does not even need to be a kernel crypto API registered implementation.
It's valid criticism that the number of algorithms should be limited. Algorithmic agility is an issue and has caused many real-world security problems in protocols liberally granting crypto primitives to be chosen by the user isn't a good idea. We should think about algorithms that make sense. E.g. TLS 1.3 and HTTP/2 have been moving into this direction. TLS 1.3 will only allow a couple off cipher-suites as opposed to combinatorial explosion with previous iterations of the protocol.
I'd suggest sticking to AES-CTR and ChaCha20 for DRNG designs. That should fit almost all platforms with great performance, keep code-base small etc.
There's now heavily optimised assembly in OpenSSL for ChaCha20 if you want to take a look: https://github.com/openssl/openssl/tree/master/crypto/chacha/asm
But as mentioned in the ChaCha/urandom thread: architecture specific optimisation may be painful and error-prone.
> Bottom line, I want to give folks a full flexibility. That said, the LRNG code
> is more of a logic to collect entropy and maintain two DRNG types which are
> seeded according to a defined schedule than it is a tightly integrated RNG.
>
> Also, I am not so sure that simply taking a cipher, sprinkling some
> backtracking logic on it implies you have a good DRNG. As of now, I have not
> seen assessments from others for the Chacha20 DRNG approach. I personally
> would think that the Chacha20 approach from Ted is good. Yet others may have a
> more conservative approach of using a DRNG implementation that has been
> reviewed by a lot of folks.
>
> [1] http://www.chronox.de/lrng/doc/lrng.pdf
Currently reading that paper, it seems like a solid approach.
I don't like the approach that user-space programs may modify entropy. It's a myth that `haveged` etc. provide more security, and EGDs have been barely audited, usually written as academic work and have been completely unmaintained. I regularly end up in randomness[sic!] discussions with core language maintainers [0] [1] - they seem to have little understanding of what's going on in the kernel and either use /dev/random as a seed or a Userspace RNG (most of which aren't particularly safe to begin with -- OpenSSL is not fork safe [2] [3], a recent paper found weaknesses in the OpenSSL RNG at low entropy state leaking secrets [4] et cetera). This seems to be mostly the case because of the infamous `random(4)` man-page. With end-users (protocol implementers, core language designers,..) always pointing to upstream, which - of course - is the Linux kernel.
I can't really tell from the paper if /dev/random would still be blocking in some cases? If so that's unfortunate.
Thanks for your work on this,
Aaron
[0] https://bugs.ruby-lang.org/issues/9569
[1] https://github.com/nodejs/node/issues/5798
[2] https://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
[3] https://wiki.openssl.org/index.php/Random_fork-safety
[4] https://eprint.iacr.org/2016/367.pdf
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] crypto: s5p-sss - Use consistent indentation for variables and members
From: Vladimir Zapolskiy @ 2016-05-28 19:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Herbert Xu, davem, linux-crypto,
linux-kernel, linux-samsung-soc
Cc: Bartlomiej Zolnierkiewicz
In-Reply-To: <1464349780-27674-1-git-send-email-k.kozlowski@samsung.com>
Hi Krzysztof,
On 27.05.2016 14:49, Krzysztof Kozlowski wrote:
> Bring some consistency by:
> 1. Replacing fixed-space indentation of structure members with just
> tabs.
> 2. Remove indentation in declaration of local variable between type and
> name. Driver was mixing usage of such indentation and lack of it.
> When removing indentation, reorder variables in
> reversed-christmas-tree order with first variables being initialized
> ones.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
it looks like a trivial and nice change, thank you.
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
^ permalink raw reply
* Re: Could this be applied to random(4)?
From: Stephan Mueller @ 2016-05-29 19:20 UTC (permalink / raw)
To: Sandy Harris; +Cc: linux-crypto, Theodore Ts'o, John Denker
In-Reply-To: <CACXcFmm1q-Z3JSE79m5ak-a+tO50uQNUPwvq_ueei_b19qycJw@mail.gmail.com>
Am Freitag, 27. Mai 2016, 16:09:53 schrieb Sandy Harris:
Hi Sandy,
> On Fri, May 27, 2016 at 2:30 PM, Stephan Mueller <smueller@chronox.de>
wrote:
> > This document describes extractors. Those extractors are intended to
> > combine *independent* sources with weak entropy.
> >
> > None of our sources we have in add_*_randomness are independent.
>
> No, but it would be easy to get two independent sources, interrupts
> and some sort of timer jitter thing as in my maxwell, your jitter
> driver, havege, ...
I think I would concur with you here. From my LRNG code:
static int lrng_pdrbg_seed_internal(u8 *outbuf, u32 outbuflen, bool
fullentropy,
bool drain)
{
...
/*
* Concatenate the output of the noise sources. This would be the
* spot to add an entropy extractor logic if desired.
...
> --
> 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
Ciao
Stephan
^ permalink raw reply
* Re: AES-NI: slower than aes-generic?
From: Stephan Mueller @ 2016-05-29 19:51 UTC (permalink / raw)
To: Aaron Zauner, linux-crypto; +Cc: Sandy Harris, Theodore Ts'o
In-Reply-To: <FEA29793-B67A-4C0D-A904-909A62BB3E65@azet.org>
Am Samstag, 28. Mai 2016, 07:28:25 schrieb Aaron Zauner:
Hi Aaron,
> Heya,
>
> > On 27 May 2016, at 01:49, Stephan Mueller <smueller@chronox.de> wrote:
> > Then, the use of the DRBG offers users to choose between a Hash/HMAC and
> > CTR implementation to suit their needs. The DRBG code is agnostic of the
> > underlying cipher. So, you could even use Blowfish instead of AES or
> > whirlpool instead of SHA -- these changes are just one entry in
> > drbg_cores[] away without any code change.
>
> That's a really nice change and something I've been thinking about for a
> couple of months as well. Then I came across tytso's ChaCha patches to
> urandom and was thinking ISA dependent switches between ciphers would make
> sense, i.e. you get AESNI performance when there's support.
> > Finally, the LRNG code is completely agnostic of the underlying
> > deterministic RNG. You only need a replacement of two small functions to
> > invoke the seeding and generate operation of a DRNG. So, if one wants a
> > Chacha20, he can have it. If one wants X9.31, he can have it. See section
> > 2.8.3 [1] -- note, that DRNG does not even need to be a kernel crypto API
> > registered implementation.
> It's valid criticism that the number of algorithms should be limited.
> Algorithmic agility is an issue and has caused many real-world security
> problems in protocols liberally granting crypto primitives to be chosen by
> the user isn't a good idea. We should think about algorithms that make
> sense. E.g. TLS 1.3 and HTTP/2 have been moving into this direction. TLS
> 1.3 will only allow a couple off cipher-suites as opposed to combinatorial
> explosion with previous iterations of the protocol.
I cannot agree more with you, if the attacker can choose the algo. However, I
would think that a compile time selection of one specific algo is not prone to
this issue. Also, the code of the LRNG provides a pre-defined set of DRBGs
that should not leave any wish open. Hence, I am not sure that too many folks
would change the code here.
Though, if folks really want to, they have the option to do so.
>
> I'd suggest sticking to AES-CTR and ChaCha20 for DRNG designs. That should
> fit almost all platforms with great performance, keep code-base small etc.
Regarding the CTR DRBG: I did not make it default out of two reasons:
- it is not the fastest -- as I just found a drag on the CTR DRBG performance
that I want to push upstream after closing the merge window. With that patch
the CTR DRBG now is the fastest by orders of magnitude. So, this issue does
not apply any more.
- the DF/BCC function in the DRBG is critical as I think it looses entropy
IMHO. When you seed the DRBG with, say 256 or 384 bits of data, the BCC acts
akin a MAC by taking the 256 or 384 bits and collapse it into one AES block of
128 bits. Then he DF function expands this one block into the DRBG internal
state including the AES key of 256 / 384 bits depending on the type of AES you
use. So, if you have 256 bits of entropy in the seed, you have 128 bits left
after the BCC operation.
Given that criticism, I am asking whether the use of the CTR DRBG with AES >
128 should be used as default. Also, the CTR DRBG is the most complex of all
three DRBGs (with the HMAC, the current default, is the leanest and cleanest).
But if folks think that the CTR DRBG should be made the default, I would
listen and make it so.
>
> There's now heavily optimised assembly in OpenSSL for ChaCha20 if you want
> to take a look:
> https://github.com/openssl/openssl/tree/master/crypto/chacha/asm But as
> mentioned in the ChaCha/urandom thread: architecture specific optimisation
> may be painful and error-prone.
I personally am not sure that taking some arbitrary cipher and turning it into
a DRNG by simply using a self-feeding loop based on the ideas of X9.31
Appendix A2.4 is good. Chacha20 is a good cipher, but is it equally good for a
DRNG? I do not know. There are too little assessments from mathematicians out
there regarding that topic.
Hence, I rather like to stick to DRNG designs that have been analyzed by
different folks.
> > Bottom line, I want to give folks a full flexibility. That said, the LRNG
> > code is more of a logic to collect entropy and maintain two DRNG types
> > which are seeded according to a defined schedule than it is a tightly
> > integrated RNG.
> >
> > Also, I am not so sure that simply taking a cipher, sprinkling some
> > backtracking logic on it implies you have a good DRNG. As of now, I have
> > not seen assessments from others for the Chacha20 DRNG approach. I
> > personally would think that the Chacha20 approach from Ted is good. Yet
> > others may have a more conservative approach of using a DRNG
> > implementation that has been reviewed by a lot of folks.
> >
> > [1] http://www.chronox.de/lrng/doc/lrng.pdf
>
> Currently reading that paper, it seems like a solid approach.
There was criticism on the entropy maintenance. I have now reverted it to the
classical, yet lockless, LFSR approach. Once the merge window closes, I will
release the new version.
>
> I don't like the approach that user-space programs may modify entropy. It's
> a myth that `haveged` etc. provide more security, and EGDs have been barely
> audited, usually written as academic work and have been completely
> unmaintained. I regularly end up in randomness[sic!] discussions with core
> language maintainers [0] [1] - they seem to have little understanding of
> what's going on in the kernel and either use /dev/random as a seed or a
> Userspace RNG (most of which aren't particularly safe to begin with --
> OpenSSL is not fork safe [2] [3], a recent paper found weaknesses in the
> OpenSSL RNG at low entropy state leaking secrets [4] et cetera). This seems
> to be mostly the case because of the infamous `random(4)` man-page. With
> end-users (protocol implementers, core language designers,..) always
> pointing to upstream, which - of course - is the Linux kernel.
Point taken, but I cannot simply change the existing user space interface.
Hence, I modified it such that the data does not end up in some entropy pool,
but is mixed into the DRBGs which are designed to handle date with and without
entropy.
>
> I can't really tell from the paper if /dev/random would still be blocking in
> some cases? If so that's unfortunate.
It is blocking, that is its nature: one bit of output data from /dev/random
shall be backed by one bit of entropy from the noise sources. As the noise
sources are not fast, it will block.
However, the /dev/urandom is now seeded with 256 bits of entropy very fast
during boot cycle. Hence, if you use getrandom(2) which blocks until the 256
bits of initial seed is reached, you should be good for any standard
cryptographic purposes.
With the new up-and-coming release of the LRNG code, I also provide an updated
documentation. That documentation contains a test of the entropy contained in
the first 50 interrupt events after boot. With that test I record the timing
of the first 50 interrupts for a test batch of 50,000 boots. That test shall
demonstrate that the basic entropy estimate behind the LRNG is sound even
during boot times. Hence, I think that when the LRNG defines that the DRBG
behind /dev/urandom is seeded with 256 bits of entropy, it really received
that amount of entropy.
>
> Thanks for your work on this,
> Aaron
>
> [0] https://bugs.ruby-lang.org/issues/9569
> [1] https://github.com/nodejs/node/issues/5798
> [2]
> https://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-sa
> fe/ [3] https://wiki.openssl.org/index.php/Random_fork-safety
> [4] https://eprint.iacr.org/2016/367.pdf
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] crypto: omap: convert to the new cryptoengine API
From: Baolin Wang @ 2016-05-30 2:20 UTC (permalink / raw)
To: LABBE Corentin; +Cc: Herbert Xu, David Miller, linux-crypto, LKML
In-Reply-To: <1463563285-11742-3-git-send-email-clabbe.montjoie@gmail.com>
On 18 May 2016 at 17:21, LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> Since the crypto engine has been converted to use crypto_async_request
> instead of ablkcipher_request, minor changes are needed to use it.
I think you missed the conversion for omap des driver, please rebase
your patch. Beyond that I think you did a good job for crypto engine
if Herbert applied it.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/omap-aes.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
> index d420ec7..1368ab1 100644
> --- a/drivers/crypto/omap-aes.c
> +++ b/drivers/crypto/omap-aes.c
> @@ -530,7 +530,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
>
> pr_debug("err: %d\n", err);
>
> - crypto_finalize_request(dd->engine, req, err);
> + crypto_finalize_request(dd->engine, &req->base, err);
> }
>
> static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
> @@ -603,14 +603,15 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
> struct ablkcipher_request *req)
> {
> if (req)
> - return crypto_transfer_request_to_engine(dd->engine, req);
> + return crypto_transfer_request_to_engine(dd->engine, &req->base);
>
> return 0;
> }
>
> static int omap_aes_prepare_req(struct crypto_engine *engine,
> - struct ablkcipher_request *req)
> + struct crypto_async_request *areq)
> {
> + struct ablkcipher_request *req = ablkcipher_request_cast(areq);
> struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
> crypto_ablkcipher_reqtfm(req));
> struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
> @@ -653,8 +654,9 @@ static int omap_aes_prepare_req(struct crypto_engine *engine,
> }
>
> static int omap_aes_crypt_req(struct crypto_engine *engine,
> - struct ablkcipher_request *req)
> + struct crypto_async_request *areq)
> {
> + struct ablkcipher_request *req = ablkcipher_request_cast(areq);
> struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
> crypto_ablkcipher_reqtfm(req));
> struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
> --
> 2.7.3
>
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: AES-NI: slower than aes-generic?
From: Theodore Ts'o @ 2016-05-30 4:08 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Aaron Zauner, linux-crypto, Sandy Harris
In-Reply-To: <7574982.B7hkDJezet@positron.chronox.de>
On Sun, May 29, 2016 at 09:51:59PM +0200, Stephan Mueller wrote:
>
> I personally am not sure that taking some arbitrary cipher and turning it into
> a DRNG by simply using a self-feeding loop based on the ideas of X9.31
> Appendix A2.4 is good. Chacha20 is a good cipher, but is it equally good for a
> DRNG? I do not know. There are too little assessments from mathematicians out
> there regarding that topic.
If ChCha20 is a good (stream) cipher, it must be a good DRNG by
definition. In other words, if you can predict the output of
ChaCha20-base DRNG with any accuracy greater than chance, this can be
used as a wedge to attack the stream cipher..
I will note that OpenBSD's "ARC4" random number generator is currently
using ChaCha20, BTW.
Regards,
- Ted
^ permalink raw reply
* [PATCH-v3 0/5] random: replace urandom pool with a CRNG
From: Theodore Ts'o @ 2016-05-30 5:39 UTC (permalink / raw)
To: Linux Kernel Developers List
Cc: smueller, herbert, andi, sandyinchina, cryptography, jsd, hpa,
linux-crypto, Theodore Ts'o
By using a CRNG to replace the urandom pool, we address a number of
complaints which Stephan Mueller has been concerned about. We now use
a much more aggressive interrupt sampling system to quickly initialize
a CRNG which gets used in place of the original non-blocking pool.
This tends to get initialized *very* quickly (before the devices are
finished being proved.) Like Stephan's proposal, this assumes that we
can get a bit of entropy per interrupt, which may be problematic on
some architectures. So after we do this quick-and-dirty
initialization, we then fall back to the slower, more conservative
interrupt sampling system to fill the input pool, and we will do a
catastrophic reseeding once we get 128 bits using the slower but more
conservative system, and every five minutes afterwards, if possible.
In addition, on NUMA systems we make the CRNG state per-NUMA socket, to
address the NUMA locking contention problem which Andi Kleen has been
complaining about. I'm not entirely sure this will work well on the
crazy big SGI systems, but they are rare. Whether they are rarer than
abusive userspace programs that are continuously pounding /dev/urandom
is unclear. If necessary we can make a config option to turn off the
per-NUMA socket hack if it proves to be problematic.
Note: I didn't propose this for merging in 4.7 because I wanted to
further refine the reseeding logic and because I wanted to get more
feedback. My plan is to merge these changes for the 4.8 merge
window.
These patches are also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git
Changes since -v2:
* Rebased to v4.7-rc1
* Improved/reworked CRNG reseeding and backtracking protection
* Preseed the CRNG state from system data
* Added fix to properly align the get_random_int_hash[] array
Eric Biggers (1):
random: properly align get_random_int_hash
Stephan Mueller (1):
random: add interrupt callback to VMBus IRQ handler
Theodore Ts'o (3):
random: replace non-blocking pool with a Chacha20-based CRNG
random: make /dev/urandom scalable for silly userspace programs
random: add backtracking protection to the CRNG
crypto/chacha20_generic.c | 61 -------
drivers/char/random.c | 446 ++++++++++++++++++++++++++++++++++++----------
drivers/hv/vmbus_drv.c | 3 +
include/crypto/chacha20.h | 1 +
lib/Makefile | 2 +-
lib/chacha20.c | 79 ++++++++
6 files changed, 438 insertions(+), 154 deletions(-)
create mode 100644 lib/chacha20.c
--
2.5.0
^ permalink raw reply
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