* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Herbert Xu @ 2017-03-22 2:57 UTC (permalink / raw)
To: Stephan Müller; +Cc: Harsh Jain, linux-crypto
In-Reply-To: <1593289.epxWzXFfWH@positron.chronox.de>
On Tue, Mar 21, 2017 at 04:00:04PM +0100, Stephan Müller wrote:
> Am Dienstag, 21. März 2017, 14:23:31 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
> > Yes, Driver can figure out when to discard dst SGL but for that Driver
> > has to put checks before accessing dst SGL. Isn't better if AF_ALG
> > sends NULL for dst SGL.
>
> With the code in [1], the first longer patch is planned to be merged after the
> memory management changes are agreed upon. That patch contains:
>
> + /* chain the areq TX SGL holding the tag with RX SGL */
> + if (!last_rsgl) {
> + /* no RX SGL present (e.g. only authentication) */
> + sg_init_table(areq->first_rsgl.sgl.sg, 2);
> + sg_chain(areq->first_rsgl.sgl.sg, 2, areq->tsgl);
> + } else {
> + /* RX SGL present */
> + struct af_alg_sgl *sgl_prev = &last_rsgl->sgl;
> +
> + sg_unmark_end(sgl_prev->sg + sgl_prev->npages - 1);
> + sg_chain(sgl_prev->sg, sgl_prev->npages + 1, areq-
> >tsgl);
> + }
>
>
> This code snipped would exactly do what you want: the SGL is always
> initialized. Besides, the code will do an in-place cipher operation.
>
> https://www.spinics.net/lists/linux-crypto/msg24343.html
Even if we fix this one user of the crypto API, new users could
still feed you bogus SG lists. The API does not require the user
to specify a NULL SG list so please fix this in the driver.
We should also strength testmgr so that it provides something
bogus to catch buggy drivers.
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 1/1] crypto: If two strings are exact match, they must have same length.
From: Herbert Xu @ 2017-03-22 3:00 UTC (permalink / raw)
To: Ming Ma; +Cc: davem, linux-crypto, linux-kernel
In-Reply-To: <1490132440-112761-1-git-send-email-mingma@micron.com>
On Tue, Mar 21, 2017 at 04:40:40PM -0500, Ming Ma wrote:
> When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm
> exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it
> has higher priority than "crct10dif-generic". However, both algorithms
> have the same cra_name "crct10dif". If we use "crct10dif" to find a
> matched algorithm in crypto_alg_list, it's possible "crct10dif-generic" is
> selected, because the code calls strcmp to decide if two string are exact
> match, but doesn't check if two strings have the same length.
>
> exact = !strcmp(q->cra_driver_name, name);
>
> So ,if "crct10dif-generic" is in front of "crct10dif-pclmul" in
> crypto_alg_list, it will be picked as the matched algorithm, even if it has
> lower priority than "crct10dif-pclmul".
> Signed-off-by: Ming Ma <mingma@micron.com>
> ---
> crypto/api.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index b16ce16..5b3d45a 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -76,7 +76,8 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
> ((struct crypto_larval *)q)->mask != mask)
> continue;
>
> - exact = !strcmp(q->cra_driver_name, name);
> + exact = (strlen(name) == strlen(q->cra_driver_name)) &&
> + !strcmp(q->cra_driver_name, name);
> fuzzy = !strcmp(q->cra_name, name);
> if (!exact && !(fuzzy && q->cra_priority > best))
> continue;
This is bogus. Please describe how you reproduced the problem.
The priority matching should work.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/1] crypto: If two strings are exact match, they must have same length.
From: Ming Ma @ 2017-03-21 21:40 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, linux-kernel, Ming Ma
When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm
exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it
has higher priority than "crct10dif-generic". However, both algorithms
have the same cra_name "crct10dif". If we use "crct10dif" to find a
matched algorithm in crypto_alg_list, it's possible "crct10dif-generic" is
selected, because the code calls strcmp to decide if two string are exact
match, but doesn't check if two strings have the same length.
exact = !strcmp(q->cra_driver_name, name);
So ,if "crct10dif-generic" is in front of "crct10dif-pclmul" in
crypto_alg_list, it will be picked as the matched algorithm, even if it has
lower priority than "crct10dif-pclmul".
Signed-off-by: Ming Ma <mingma@micron.com>
---
crypto/api.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/api.c b/crypto/api.c
index b16ce16..5b3d45a 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -76,7 +76,8 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
((struct crypto_larval *)q)->mask != mask)
continue;
- exact = !strcmp(q->cra_driver_name, name);
+ exact = (strlen(name) == strlen(q->cra_driver_name)) &&
+ !strcmp(q->cra_driver_name, name);
fuzzy = !strcmp(q->cra_name, name);
if (!exact && !(fuzzy && q->cra_priority > best))
continue;
--
2.4.11
^ permalink raw reply related
* [PATCH v2 5/5] ARM: configs: stm32: Add crypto support
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Add STM32 crypto support in stm32_defconfig file.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..03437f8 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -75,5 +75,7 @@ CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_FTRACE is not set
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_DEV_STM32=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC7=y
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: stm32: enable CRC on stm32746g-eval board
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Enable the CRC (CRC32 crypto) on stm32746g-eval board
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/boot/dts/stm32746g-eval.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index aa03fac..0dc18a0 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -89,6 +89,10 @@
clock-frequency = <25000000>;
};
+&crc {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: stm32: Add CRC support to stm32f746
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Add CRC (CRC32 crypto) support to stm32f746.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/boot/dts/stm32f746.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..755fb92 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -289,6 +289,13 @@
};
};
+ crc: crc@40023000 {
+ compatible = "st,stm32f7-crc";
+ reg = <0x40023000 0x400>;
+ clocks = <&rcc 0 12>;
+ status = "disabled";
+ };
+
rcc: rcc@40023800 {
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/5] crypto: stm32 - Support for STM32 CRC32 crypto module
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
This module registers a CRC32 ("Ethernet") and a CRC32C (Castagnoli)
algorithm that make use of the STMicroelectronics STM32 crypto hardware.
Theses algorithms are compatible with the little-endian generic ones.
Both algorithms use ~0 as default seed (key).
With CRC32C the output is xored with ~0.
Using TCRYPT CRC32C speed test, this shows up to 900% speedup compared
to the crc32c-generic algorithm.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
drivers/crypto/Kconfig | 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/stm32/Kconfig | 8 +
drivers/crypto/stm32/Makefile | 2 +
drivers/crypto/stm32/stm32_crc32.c | 324 +++++++++++++++++++++++++++++++++++++
5 files changed, 337 insertions(+)
create mode 100644 drivers/crypto/stm32/Kconfig
create mode 100644 drivers/crypto/stm32/Makefile
create mode 100644 drivers/crypto/stm32/stm32_crc32.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 473d312..922b323 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -619,4 +619,6 @@ config CRYPTO_DEV_BCM_SPU
Secure Processing Unit (SPU). The SPU driver registers ablkcipher,
ahash, and aead algorithms with the kernel cryptographic API.
+source "drivers/crypto/stm32/Kconfig"
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 7396094..95bf2f9 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
+obj-$(CONFIG_CRYPTO_DEV_STM32) += stm32/
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
new file mode 100644
index 0000000..792335b
--- /dev/null
+++ b/drivers/crypto/stm32/Kconfig
@@ -0,0 +1,8 @@
+config CRYPTO_DEV_STM32
+ tristate "Support for STM32 crypto accelerators"
+ depends on ARCH_STM32
+ select CRYPTO_HASH
+ help
+ This enables support for the CRC32 hw accelerator which can be found
+ on STMicroelectronis STM32 SOC.
+
diff --git a/drivers/crypto/stm32/Makefile b/drivers/crypto/stm32/Makefile
new file mode 100644
index 0000000..73b4c6e
--- /dev/null
+++ b/drivers/crypto/stm32/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_STM32) += stm32_cryp.o
+stm32_cryp-objs := stm32_crc32.o
diff --git a/drivers/crypto/stm32/stm32_crc32.c b/drivers/crypto/stm32/stm32_crc32.c
new file mode 100644
index 0000000..7652822
--- /dev/null
+++ b/drivers/crypto/stm32/stm32_crc32.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ * Author: Fabien Dessenne <fabien.dessenne@st.com>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/bitrev.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <crypto/internal/hash.h>
+
+#include <asm/unaligned.h>
+
+#define DRIVER_NAME "stm32-crc32"
+#define CHKSUM_DIGEST_SIZE 4
+#define CHKSUM_BLOCK_SIZE 1
+
+/* Registers */
+#define CRC_DR 0x00000000
+#define CRC_CR 0x00000008
+#define CRC_INIT 0x00000010
+#define CRC_POL 0x00000014
+
+/* Registers values */
+#define CRC_CR_RESET BIT(0)
+#define CRC_CR_REVERSE (BIT(7) | BIT(6) | BIT(5))
+#define CRC_INIT_DEFAULT 0xFFFFFFFF
+
+/* Polynomial reversed */
+#define POLY_CRC32 0xEDB88320
+#define POLY_CRC32C 0x82F63B78
+
+struct stm32_crc {
+ struct list_head list;
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *clk;
+ u8 pending_data[sizeof(u32)];
+ size_t nb_pending_bytes;
+};
+
+struct stm32_crc_list {
+ struct list_head dev_list;
+ spinlock_t lock; /* protect dev_list */
+};
+
+static struct stm32_crc_list crc_list = {
+ .dev_list = LIST_HEAD_INIT(crc_list.dev_list),
+ .lock = __SPIN_LOCK_UNLOCKED(crc_list.lock),
+};
+
+struct stm32_crc_ctx {
+ u32 key;
+ u32 poly;
+};
+
+struct stm32_crc_desc_ctx {
+ u32 partial; /* crc32c: partial in first 4 bytes of that struct */
+ struct stm32_crc *crc;
+};
+
+static int stm32_crc32_cra_init(struct crypto_tfm *tfm)
+{
+ struct stm32_crc_ctx *mctx = crypto_tfm_ctx(tfm);
+
+ mctx->key = CRC_INIT_DEFAULT;
+ mctx->poly = POLY_CRC32;
+ return 0;
+}
+
+static int stm32_crc32c_cra_init(struct crypto_tfm *tfm)
+{
+ struct stm32_crc_ctx *mctx = crypto_tfm_ctx(tfm);
+
+ mctx->key = CRC_INIT_DEFAULT;
+ mctx->poly = POLY_CRC32C;
+ return 0;
+}
+
+static int stm32_crc_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct stm32_crc_ctx *mctx = crypto_shash_ctx(tfm);
+
+ if (keylen != sizeof(u32)) {
+ crypto_shash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return -EINVAL;
+ }
+
+ mctx->key = get_unaligned_le32(key);
+ return 0;
+}
+
+static int stm32_crc_init(struct shash_desc *desc)
+{
+ struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc);
+ struct stm32_crc_ctx *mctx = crypto_shash_ctx(desc->tfm);
+ struct stm32_crc *crc;
+
+ spin_lock_bh(&crc_list.lock);
+ list_for_each_entry(crc, &crc_list.dev_list, list) {
+ ctx->crc = crc;
+ break;
+ }
+ spin_unlock_bh(&crc_list.lock);
+
+ /* Reset, set key, poly and configure in bit reverse mode */
+ writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
+ writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
+ writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+
+ /* Store partial result */
+ ctx->partial = readl(ctx->crc->regs + CRC_DR);
+ ctx->crc->nb_pending_bytes = 0;
+
+ return 0;
+}
+
+static int stm32_crc_update(struct shash_desc *desc, const u8 *d8,
+ unsigned int length)
+{
+ struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc);
+ struct stm32_crc *crc = ctx->crc;
+ u32 *d32;
+ unsigned int i;
+
+ if (unlikely(crc->nb_pending_bytes)) {
+ while (crc->nb_pending_bytes != sizeof(u32) && length) {
+ /* Fill in pending data */
+ crc->pending_data[crc->nb_pending_bytes++] = *(d8++);
+ length--;
+ }
+
+ if (crc->nb_pending_bytes == sizeof(u32)) {
+ /* Process completed pending data */
+ writel(*(u32 *)crc->pending_data, crc->regs + CRC_DR);
+ crc->nb_pending_bytes = 0;
+ }
+ }
+
+ d32 = (u32 *)d8;
+ for (i = 0; i < length >> 2; i++)
+ /* Process 32 bits data */
+ writel(*(d32++), crc->regs + CRC_DR);
+
+ /* Store partial result */
+ ctx->partial = readl(crc->regs + CRC_DR);
+
+ /* Check for pending data (non 32 bits) */
+ length &= 3;
+ if (likely(!length))
+ return 0;
+
+ if ((crc->nb_pending_bytes + length) >= sizeof(u32)) {
+ /* Shall not happen */
+ dev_err(crc->dev, "Pending data overflow\n");
+ return -EINVAL;
+ }
+
+ d8 = (const u8 *)d32;
+ for (i = 0; i < length; i++)
+ /* Store pending data */
+ crc->pending_data[crc->nb_pending_bytes++] = *(d8++);
+
+ return 0;
+}
+
+static int stm32_crc_final(struct shash_desc *desc, u8 *out)
+{
+ struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc);
+ struct stm32_crc_ctx *mctx = crypto_shash_ctx(desc->tfm);
+
+ /* Send computed CRC */
+ put_unaligned_le32(mctx->poly == POLY_CRC32C ?
+ ~ctx->partial : ctx->partial, out);
+
+ return 0;
+}
+
+static int stm32_crc_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int length, u8 *out)
+{
+ return stm32_crc_update(desc, data, length) ?:
+ stm32_crc_final(desc, out);
+}
+
+static int stm32_crc_digest(struct shash_desc *desc, const u8 *data,
+ unsigned int length, u8 *out)
+{
+ return stm32_crc_init(desc) ?: stm32_crc_finup(desc, data, length, out);
+}
+
+static struct shash_alg algs[] = {
+ /* CRC-32 */
+ {
+ .setkey = stm32_crc_setkey,
+ .init = stm32_crc_init,
+ .update = stm32_crc_update,
+ .final = stm32_crc_final,
+ .finup = stm32_crc_finup,
+ .digest = stm32_crc_digest,
+ .descsize = sizeof(struct stm32_crc_desc_ctx),
+ .digestsize = CHKSUM_DIGEST_SIZE,
+ .base = {
+ .cra_name = "crc32",
+ .cra_driver_name = DRIVER_NAME,
+ .cra_priority = 200,
+ .cra_blocksize = CHKSUM_BLOCK_SIZE,
+ .cra_alignmask = 3,
+ .cra_ctxsize = sizeof(struct stm32_crc_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = stm32_crc32_cra_init,
+ }
+ },
+ /* CRC-32Castagnoli */
+ {
+ .setkey = stm32_crc_setkey,
+ .init = stm32_crc_init,
+ .update = stm32_crc_update,
+ .final = stm32_crc_final,
+ .finup = stm32_crc_finup,
+ .digest = stm32_crc_digest,
+ .descsize = sizeof(struct stm32_crc_desc_ctx),
+ .digestsize = CHKSUM_DIGEST_SIZE,
+ .base = {
+ .cra_name = "crc32c",
+ .cra_driver_name = DRIVER_NAME,
+ .cra_priority = 200,
+ .cra_blocksize = CHKSUM_BLOCK_SIZE,
+ .cra_alignmask = 3,
+ .cra_ctxsize = sizeof(struct stm32_crc_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = stm32_crc32c_cra_init,
+ }
+ }
+};
+
+static int stm32_crc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct stm32_crc *crc;
+ struct resource *res;
+ int ret;
+
+ crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
+ if (!crc)
+ return -ENOMEM;
+
+ crc->dev = dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ crc->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(crc->regs)) {
+ dev_err(dev, "Cannot map CRC IO\n");
+ return PTR_ERR(crc->regs);
+ }
+
+ crc->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(crc->clk)) {
+ dev_err(dev, "Could not get clock\n");
+ return PTR_ERR(crc->clk);
+ }
+
+ ret = clk_prepare_enable(crc->clk);
+ if (ret) {
+ dev_err(crc->dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, crc);
+
+ spin_lock(&crc_list.lock);
+ list_add(&crc->list, &crc_list.dev_list);
+ spin_unlock(&crc_list.lock);
+
+ ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
+ if (ret) {
+ dev_err(dev, "Failed to register\n");
+ clk_disable_unprepare(crc->clk);
+ return ret;
+ }
+
+ dev_info(dev, "Initialized\n");
+
+ return 0;
+}
+
+static int stm32_crc_remove(struct platform_device *pdev)
+{
+ struct stm32_crc *crc = platform_get_drvdata(pdev);
+
+ spin_lock(&crc_list.lock);
+ list_del(&crc->list);
+ spin_unlock(&crc_list.lock);
+
+ crypto_unregister_shash(algs);
+
+ clk_disable_unprepare(crc->clk);
+
+ return 0;
+}
+
+static const struct of_device_id stm32_dt_ids[] = {
+ { .compatible = "st,stm32f7-crc", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sti_dt_ids);
+
+static struct platform_driver stm32_crc_driver = {
+ .probe = stm32_crc_probe,
+ .remove = stm32_crc_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = stm32_dt_ids,
+ },
+};
+
+module_platform_driver(stm32_crc_driver);
+
+MODULE_AUTHOR("Fabien Dessenne <fabien.dessenne@st.com>");
+MODULE_DESCRIPTION("STMicrolectronics STM32 CRC32 hardware driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: Document STM32 CRC bindings
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Document device tree bindings for the STM32 CRC (crypto CRC32)
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
.../devicetree/bindings/crypto/st,stm32-crc.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
new file mode 100644
index 0000000..3ba92a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
@@ -0,0 +1,16 @@
+* STMicroelectronics STM32 CRC
+
+Required properties:
+- compatible: Should be "st,stm32f7-crc".
+- reg: The address and length of the peripheral registers space
+- clocks: The input clock of the CRC instance
+
+Optional properties: none
+
+Example:
+
+crc: crc@40023000 {
+ compatible = "st,stm32f7-crc";
+ reg = <0x40023000 0x400>;
+ clocks = <&rcc 0 12>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] STM32 CRC crypto driver
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
This set of patches adds a new crypto driver for STMicroelectronics stm32f746.
The drivers uses the crypto API and provides with an HW-enabled CRC32 algorithm.
It was developed and tested (tcrypt / testmgr) on evaluation board stm32746g.
v2 changes:
- remove useless check of crc / crc->clk
- enable crypto in stm32 defconfig
- typo fix in dt-bindings
Fabien Dessenne (5):
dt-bindings: Document STM32 CRC bindings
crypto: stm32 - Support for STM32 CRC32 crypto module
ARM: dts: stm32: Add CRC support to stm32f746
ARM: dts: stm32: enable CRC on stm32746g-eval board
ARM: configs: stm32: Add crypto support
.../devicetree/bindings/crypto/st,stm32-crc.txt | 16 +
arch/arm/boot/dts/stm32746g-eval.dts | 4 +
arch/arm/boot/dts/stm32f746.dtsi | 7 +
arch/arm/configs/stm32_defconfig | 2 +
drivers/crypto/Kconfig | 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/stm32/Kconfig | 8 +
drivers/crypto/stm32/Makefile | 2 +
drivers/crypto/stm32/stm32_crc32.c | 324 +++++++++++++++++++++
9 files changed, 366 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
create mode 100644 drivers/crypto/stm32/Kconfig
create mode 100644 drivers/crypto/stm32/Makefile
create mode 100644 drivers/crypto/stm32/stm32_crc32.c
--
2.7.4
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Stephan Müller @ 2017-03-21 15:00 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <CAFXBA==5EOXOJV4UFaG+1AxAmuEo9PzFKsHe25YTMa8LGfKkkQ@mail.gmail.com>
Am Dienstag, 21. März 2017, 14:23:31 CET schrieb Harsh Jain:
Hi Harsh,
> Yes, Driver can figure out when to discard dst SGL but for that Driver
> has to put checks before accessing dst SGL. Isn't better if AF_ALG
> sends NULL for dst SGL.
With the code in [1], the first longer patch is planned to be merged after the
memory management changes are agreed upon. That patch contains:
+ /* chain the areq TX SGL holding the tag with RX SGL */
+ if (!last_rsgl) {
+ /* no RX SGL present (e.g. only authentication) */
+ sg_init_table(areq->first_rsgl.sgl.sg, 2);
+ sg_chain(areq->first_rsgl.sgl.sg, 2, areq->tsgl);
+ } else {
+ /* RX SGL present */
+ struct af_alg_sgl *sgl_prev = &last_rsgl->sgl;
+
+ sg_unmark_end(sgl_prev->sg + sgl_prev->npages - 1);
+ sg_chain(sgl_prev->sg, sgl_prev->npages + 1, areq-
>tsgl);
+ }
This code snipped would exactly do what you want: the SGL is always
initialized. Besides, the code will do an in-place cipher operation.
https://www.spinics.net/lists/linux-crypto/msg24343.html
Ciao
Stephan
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Harsh Jain @ 2017-03-21 13:23 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <3894659.2TbsNqkGul@tauon.atsec.com>
On Tue, Mar 21, 2017 at 5:13 PM, Stephan Müller <smueller@chronox.de> wrote:
> Am Dienstag, 21. März 2017, 11:59:54 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
>> > Executing this command on a 4.9 kernel, I get:
>> >
>> > bin/kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
>> > f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t
>> > "5f24c68cbe6f32c29652442bf5d483ad" -q ""
>> > EBADMSG
>>
>> Probably because s/w implementation is not trying to access dst sg
>> pointer because there's nothing to copy in destination buffer. 1
>> question If we don't have data to copy to destination buffer what
>> should dst pointer contains?
>
> The dst SGL should simply be discarded by implementations in the case you
> mention above.
>
> The implementation receives the tag size and the supplied input buffer. If
> that input buffer length is equal to the tag length (i.e. no AAD and no
> ciphertext), why would the dst SGL be ever touched during decrytion?
Yes, Driver can figure out when to discard dst SGL but for that Driver
has to put checks before accessing dst SGL. Isn't better if AF_ALG
sends NULL for dst SGL.
>
> Ciao
> Stephan
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Harsh Jain @ 2017-03-21 11:17 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <CAFXBA=m10UrBr1qqJ3j9F-hUXL6Bm+iEi6jLLEv9tVmCXc_p1A@mail.gmail.com>
On Tue, Mar 21, 2017 at 4:29 PM, Harsh Jain <harshjain.prof@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 3:34 PM, Stephan Müller <smueller@chronox.de> wrote:
>> Am Dienstag, 21. März 2017, 07:13:53 CET schrieb Harsh Jain:
>>
>> Hi Harsh,
>>
>>> Hi,
>>>
>>> For tag only AEAD decrypt operation(Zero length Payload). The dst sg
>>> list pointer panic with general protection fault. I think it should be
>>> NULL when output buffer is supposed to be empty.
>>>
>>> Kcapi command to re-produce the issue
>>>
>>> ./kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
>>> f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a ""
>>> -t "5f24c68cbe6f32c29652442bf5d483ad" -q ""
>>>
>>> Its decrypt operation. Expected result should be EBADMSG.
>>
>> Executing this command on a 4.9 kernel, I get:
>>
>> bin/kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
>> f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t
>> "5f24c68cbe6f32c29652442bf5d483ad" -q ""
>> EBADMSG
>
> Probably because s/w implementation is not trying to access dst sg
> pointer because there's nothing to copy in destination buffer. 1
> question If we don't have data to copy to destination buffer what
> should dst pointer contains? I think either NULL or null sg entry.
>
>>
>> There is no GP or other error. Can you please provide some details about your
>> system? I.e. which kernel version and what cipher implementation resolves to
>> gcm(aes)?
>
> I tried with 4.10.13. It's with gcm(aes-chcr). changes which trigger
> issue is not submitted to community yet.
typo Its 4.10.0-rc3+
>
>>
>> Thanks
>>
>> Ciao
>> Stephan
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Stephan Müller @ 2017-03-21 11:43 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <CAFXBA=m10UrBr1qqJ3j9F-hUXL6Bm+iEi6jLLEv9tVmCXc_p1A@mail.gmail.com>
Am Dienstag, 21. März 2017, 11:59:54 CET schrieb Harsh Jain:
Hi Harsh,
> > Executing this command on a 4.9 kernel, I get:
> >
> > bin/kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
> > f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t
> > "5f24c68cbe6f32c29652442bf5d483ad" -q ""
> > EBADMSG
>
> Probably because s/w implementation is not trying to access dst sg
> pointer because there's nothing to copy in destination buffer. 1
> question If we don't have data to copy to destination buffer what
> should dst pointer contains?
The dst SGL should simply be discarded by implementations in the case you
mention above.
The implementation receives the tag size and the supplied input buffer. If
that input buffer length is equal to the tag length (i.e. no AAD and no
ciphertext), why would the dst SGL be ever touched during decrytion?
Ciao
Stephan
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Harsh Jain @ 2017-03-21 10:59 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <5047201.43uXAH9qJG@positron.chronox.de>
On Tue, Mar 21, 2017 at 3:34 PM, Stephan Müller <smueller@chronox.de> wrote:
> Am Dienstag, 21. März 2017, 07:13:53 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
>> Hi,
>>
>> For tag only AEAD decrypt operation(Zero length Payload). The dst sg
>> list pointer panic with general protection fault. I think it should be
>> NULL when output buffer is supposed to be empty.
>>
>> Kcapi command to re-produce the issue
>>
>> ./kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
>> f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a ""
>> -t "5f24c68cbe6f32c29652442bf5d483ad" -q ""
>>
>> Its decrypt operation. Expected result should be EBADMSG.
>
> Executing this command on a 4.9 kernel, I get:
>
> bin/kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
> f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t
> "5f24c68cbe6f32c29652442bf5d483ad" -q ""
> EBADMSG
Probably because s/w implementation is not trying to access dst sg
pointer because there's nothing to copy in destination buffer. 1
question If we don't have data to copy to destination buffer what
should dst pointer contains?
>
> There is no GP or other error. Can you please provide some details about your
> system? I.e. which kernel version and what cipher implementation resolves to
> gcm(aes)?
I tried with 4.10.13. It's with gcm(aes-chcr). changes which trigger
issue is not submitted to community yet.
>
> Thanks
>
> Ciao
> Stephan
^ permalink raw reply
* Re: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Stephan Müller @ 2017-03-21 10:04 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto, Herbert Xu
In-Reply-To: <CAFXBA==w7CK_CiiVC37NN8=7p7=a=18sNd5VTnUkDCozrMvT+w@mail.gmail.com>
Am Dienstag, 21. März 2017, 07:13:53 CET schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> For tag only AEAD decrypt operation(Zero length Payload). The dst sg
> list pointer panic with general protection fault. I think it should be
> NULL when output buffer is supposed to be empty.
>
> Kcapi command to re-produce the issue
>
> ./kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
> f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a ""
> -t "5f24c68cbe6f32c29652442bf5d483ad" -q ""
>
> Its decrypt operation. Expected result should be EBADMSG.
Executing this command on a 4.9 kernel, I get:
bin/kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a "" -t
"5f24c68cbe6f32c29652442bf5d483ad" -q ""
EBADMSG
There is no GP or other error. Can you please provide some details about your
system? I.e. which kernel version and what cipher implementation resolves to
gcm(aes)?
Thanks
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 0/4] Broadcom SBA RAID support
From: Vinod Koul @ 2017-03-21 9:18 UTC (permalink / raw)
To: Anup Patel
Cc: Jassi Brar, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Dan Williams, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback, dmaengine, Device Tree,
Linux ARM Kernel, Linux Kernel, linux-crypto, linux-raid
In-Reply-To: <CAALAos-k_DBYAz49278wBr_GoceOKYVH_UuzTLn1h7QCiUd8pg@mail.gmail.com>
On Tue, Mar 21, 2017 at 02:17:21PM +0530, Anup Patel wrote:
> On Tue, Mar 21, 2017 at 2:00 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Mon, Mar 06, 2017 at 03:13:24PM +0530, Anup Patel wrote:
> >> The Broadcom SBA RAID is a stream-based device which provides
> >> RAID5/6 offload.
> >>
> >> It requires a SoC specific ring manager (such as Broadcom FlexRM
> >> ring manager) to provide ring-based programming interface. Due to
> >> this, the Broadcom SBA RAID driver (mailbox client) implements
> >> DMA device having one DMA channel using a set of mailbox channels
> >> provided by Broadcom SoC specific ring manager driver (mailbox
> >> controller).
> >>
> >> The Broadcom SBA RAID hardware requires PQ disk position instead
> >> of PQ disk coefficient. To address this, we have added raid_gflog
> >> table which will help driver to convert PQ disk coefficient to PQ
> >> disk position.
> >>
> >> This patchset is based on Linux-4.11-rc1 and depends on patchset
> >> "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
> >
> > Okay I applied and was about to push when I noticed this :(
> >
> > So what is the status of this..?
>
> PATCH2 is Acked but PATCH1 is under-review. Currently, its
> v6 of that patchset.
>
> The only dependency on that patchset is the changes in
> brcm-message.h which are required by this BCM-SBA-RAID
> driver.
>
> @Jassi,
> Can you please have a look at PATCH v6?
And I would need an immutable branch/tag once merged. I am going to keep
this series pending till then.
--
~Vinod
^ permalink raw reply
* Re: [PATCH v6 0/4] Broadcom SBA RAID support
From: Anup Patel @ 2017-03-21 8:47 UTC (permalink / raw)
To: Vinod Koul, Jassi Brar
Cc: Mark Rutland, Device Tree, Herbert Xu, Scott Branden, Jon Mason,
Ray Jui, Linux Kernel, linux-raid, Rob Herring,
BCM Kernel Feedback, linux-crypto, Rob Rice, dmaengine,
Dan Williams, David S . Miller, Linux ARM Kernel
In-Reply-To: <20170321083052.GY2843@localhost>
On Tue, Mar 21, 2017 at 2:00 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Mon, Mar 06, 2017 at 03:13:24PM +0530, Anup Patel wrote:
>> The Broadcom SBA RAID is a stream-based device which provides
>> RAID5/6 offload.
>>
>> It requires a SoC specific ring manager (such as Broadcom FlexRM
>> ring manager) to provide ring-based programming interface. Due to
>> this, the Broadcom SBA RAID driver (mailbox client) implements
>> DMA device having one DMA channel using a set of mailbox channels
>> provided by Broadcom SoC specific ring manager driver (mailbox
>> controller).
>>
>> The Broadcom SBA RAID hardware requires PQ disk position instead
>> of PQ disk coefficient. To address this, we have added raid_gflog
>> table which will help driver to convert PQ disk coefficient to PQ
>> disk position.
>>
>> This patchset is based on Linux-4.11-rc1 and depends on patchset
>> "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
>
> Okay I applied and was about to push when I noticed this :(
>
> So what is the status of this..?
PATCH2 is Acked but PATCH1 is under-review. Currently, its
v6 of that patchset.
The only dependency on that patchset is the changes in
brcm-message.h which are required by this BCM-SBA-RAID
driver.
@Jassi,
Can you please have a look at PATCH v6?
Regards,
Anup
^ permalink raw reply
* Re: [PATCH v6 0/4] Broadcom SBA RAID support
From: Vinod Koul @ 2017-03-21 8:30 UTC (permalink / raw)
To: Anup Patel
Cc: Rob Herring, Mark Rutland, Herbert Xu, David S . Miller,
Jassi Brar, Dan Williams, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, bcm-kernel-feedback-list, dmaengine, devicetree,
linux-arm-kernel, linux-kernel, linux-crypto, linux-raid
In-Reply-To: <1488793408-25592-1-git-send-email-anup.patel@broadcom.com>
On Mon, Mar 06, 2017 at 03:13:24PM +0530, Anup Patel wrote:
> The Broadcom SBA RAID is a stream-based device which provides
> RAID5/6 offload.
>
> It requires a SoC specific ring manager (such as Broadcom FlexRM
> ring manager) to provide ring-based programming interface. Due to
> this, the Broadcom SBA RAID driver (mailbox client) implements
> DMA device having one DMA channel using a set of mailbox channels
> provided by Broadcom SoC specific ring manager driver (mailbox
> controller).
>
> The Broadcom SBA RAID hardware requires PQ disk position instead
> of PQ disk coefficient. To address this, we have added raid_gflog
> table which will help driver to convert PQ disk coefficient to PQ
> disk position.
>
> This patchset is based on Linux-4.11-rc1 and depends on patchset
> "[PATCH v5 0/2] Broadcom FlexRM ring manager support"
Okay I applied and was about to push when I noticed this :(
So what is the status of this..?
--
~Vinod
^ permalink raw reply
* BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Harsh Jain @ 2017-03-21 6:13 UTC (permalink / raw)
To: linux-crypto, Herbert Xu, Stephan Mueller
Hi,
For tag only AEAD decrypt operation(Zero length Payload). The dst sg
list pointer panic with general protection fault. I think it should be
NULL when output buffer is supposed to be empty.
Kcapi command to re-produce the issue
./kcapi -x 2 -c "gcm(aes)" -i 0d92aa861746b324f20ee6b7 -k
f4a6a5e5f2066f6dd9ec6fc5169c29043560ef595c9e81e76f42d29212cc581c -a ""
-t "5f24c68cbe6f32c29652442bf5d483ad" -q ""
Its decrypt operation. Expected result should be EBADMSG.
Regards
Harsh Jain
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed
From: Stephan Müller @ 2017-03-20 20:32 UTC (permalink / raw)
To: Marcelo Henrique Cerri
Cc: linux-crypto, Herbert Xu, David S. Miller, linux-kernel
In-Reply-To: <1490041685-25947-1-git-send-email-marcelo.cerri@canonical.com>
Am Montag, 20. März 2017, 21:28:05 CET schrieb Marcelo Henrique Cerri:
Hi Marcelo,
> 3DES is missing the fips_allowed flag for CTR mode.
>
> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Stephan Mueller <smueller@chronox.de>
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed
From: Marcelo Henrique Cerri @ 2017-03-20 20:28 UTC (permalink / raw)
To: linux-crypto
Cc: Herbert Xu, David S. Miller, linux-kernel, Stephan Muller,
Marcelo Henrique Cerri
3DES is missing the fips_allowed flag for CTR mode.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
---
crypto/testmgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 89f1dd1f4b13..cd075c7d8ee1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2645,6 +2645,7 @@ static const struct alg_test_desc alg_test_descs[] = {
}, {
.alg = "ctr(des3_ede)",
.test = alg_test_skcipher,
+ .fips_allowed = 1,
.suite = {
.cipher = {
.enc = __VECS(des3_ede_ctr_enc_tv_template),
--
2.7.4
^ permalink raw reply related
* Re: Question - seeding the hw pseudo random number generator
From: Krzysztof Kozlowski @ 2017-03-20 18:24 UTC (permalink / raw)
To: Herbert Xu
Cc: PrasannaKumar Muralidharan, Matt Mackall, linux-crypto,
linux-arm-kernel, Stephan Müller
In-Reply-To: <20170320132858.GA27044@gondor.apana.org.au>
On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote:
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> >
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
>
> Yes. We should be converting PRNGs in hwrng over to algif_rng.
The actual hardware block can be seeded from true RNG (taking data
from thermal noise) so the solutions (if I understand correctly) for
exynos-rng might be:
1. Seed from internal TRNG making it a proper hwrandom device,
2. Convert to AF_ALG and seed with data from user-space through that
interface.
Thanks for explanation, I'll queue it to my tasks list.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Binoy Jayan @ 2017-03-20 14:38 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Milan Broz, Oded, Ofir, Herbert Xu, David S. Miller, linux-crypto,
Mark Brown, Arnd Bergmann, Linux kernel mailing list,
Alasdair Kergon, Mike Snitzer, dm-devel, Shaohua Li, linux-raid,
Rajendra, Ondrej Mosnacek
In-Reply-To: <CAOtvUMdrQA4okKhiCyVmosQ4Oc2PHO4k4wLrDz-_fCyWB1rWBw@mail.gmail.com>
On 6 March 2017 at 20:08, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>
> I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
> on Arm using CryptoCell hardware accelerator.
>
> There was no difference in performance between 512 and 4096 bytes
> cluster size on the x86_64 (800 MB loop file system)
>
> There was an improvement in latency of 3.2% between 512 and 4096 bytes
> cluster size on the Arm. I expect the performance benefits for this
> test for Binoy's patch to be the same.
>
> In both cases the very naive test was a simple dd with block size of
> 4096 bytes or the raw block device.
>
> I do not know what effect having a bigger cluster size would have on
> have on other more complex file system operations.
> Is there any specific benchmark worth testing with?
The multiple instances issue in /proc/crypto is fixed. It was because of
the IV code itself modifying the algorithm name inadvertently in the
global crypto algorithm lookup table when it was splitting up
"plain(cbc(aes))" into "plain" and "cbc(aes)" so as to invoke the child
algorithm.
I ran a few tests with dd, bonnie and FIO under Qemu - x86 using the
automated script [1] that I wrote to make the testing easy.
The tests were done on software implementations of the algorithms
as the real hardware was not available with me. According to the test,
I found that the sequential reads and writes have a good improvement
(5.7 %) in the data rate with the proposed solution while the random
reads shows a very little improvement. When tested with FIO, the
random writes also shows a small improvement (2.2%) but the random
reads show a little deterioration in performance (4 %).
When tested in arm hardware, only the sequential writes with bonnie
shows improvement (5.6%). All other tests shows degraded performance
in the absence of crypto hardware.
[1] https://github.com/binoyjayan/utilities/blob/master/utils/dmtest
Dependencies: dd [Full version], bonnie, fio
Thanks,
Binoy
^ permalink raw reply
* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Binoy Jayan @ 2017-03-20 14:31 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Rajendra, Herbert Xu, Oded, Ondrej Mosnacek, Mike Snitzer,
Linux kernel mailing list, Milan Broz, linux-raid, dm-devel,
Mark Brown, Arnd Bergmann, linux-crypto, Shaohua Li,
David S. Miller, Alasdair Kergon, Ofir
In-Reply-To: <CAOtvUMdrQA4okKhiCyVmosQ4Oc2PHO4k4wLrDz-_fCyWB1rWBw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2012 bytes --]
Hi,
On 8 March 2017 at 13:49, Binoy Jayan <binoy.jayan@linaro.org> wrote:
> Hi Gilad,
>
>> I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
>> on Arm using CryptoCell hardware accelerator.
>>
>> There was no difference in performance between 512 and 4096 bytes
>> cluster size on the x86_64 (800 MB loop file system)
>>
>> There was an improvement in latency of 3.2% between 512 and 4096 bytes
>> cluster size on the Arm. I expect the performance benefits for this
>> test for Binoy's patch to be the same.
>>
>> In both cases the very naive test was a simple dd with block size of
>> 4096 bytes or the raw block device.
>>
>> I do not know what effect having a bigger cluster size would have on
>> have on other more complex file system operations.
>> Is there any specific benchmark worth testing with?
The multiple instances issue in /proc/crypto is fixed. It was because of
the IV code itself modifying the algorithm name inadvertently in the
global crypto algorithm lookup table when it was splitting up
"plain(cbc(aes))" into "plain" and "cbc(aes)" so as to invoke the child
algorithm.
I ran a few tests with dd, bonnie and FIO under Qemu - x86 using the
automated script [1] that I wrote to make the testing easy.
The tests were done on software implementations of the algorithms
as the real hardware was not available with me. According to the test,
I found that the sequential reads and writes have a good improvement
(5.7 %) in the data rate with the proposed solution while the random
reads shows a very little improvement. When tested with FIO, the
random writes also shows a small improvement (2.2%) but the random
reads show a little deterioration in performance (4 %).
When tested in arm hardware, only the sequential writes with bonnie
shows improvement (5.6%). All other tests shows degraded performance
in the absence of crypto hardware.
[1] https://github.com/binoyjayan/utilities/blob/master/utils/dmtest
Dependencies: dd [Full version], bonnie, fio
Thanks,
Binoy
[-- Attachment #1.2: Type: text/html, Size: 2545 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] crypto: zip - Memory corruption in zip_clear_stats()
From: Mahipal Reddy @ 2017-03-20 14:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: walter harms, Herbert Xu, David S. Miller, Jan Glauber,
linux-crypto, kernel-janitors
In-Reply-To: <20170318105927.GA4343@mwanda>
On Sat, Mar 18, 2017 at 4:29 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Sat, Mar 18, 2017 at 11:24:34AM +0100, walter harms wrote:
>>
>>
>> Am 17.03.2017 21:46, schrieb Dan Carpenter:
>> > There is a typo here. It should be "stats" instead of "state". The
>> > impact is that we clear 224 bytes instead of 80 and we zero out memory
>> > that we shouldn't.
Thank you Dan for identifying the issue. Yes there is a typo and it needs a fix.
>> > Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
>> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>> >
>> > diff --git a/drivers/crypto/cavium/zip/zip_main.c b/drivers/crypto/cavium/zip/zip_main.c
>> > index 0951e20b395b..6ff13d80d82e 100644
>> > --- a/drivers/crypto/cavium/zip/zip_main.c
>> > +++ b/drivers/crypto/cavium/zip/zip_main.c
>> > @@ -530,7 +530,7 @@ static int zip_clear_stats(struct seq_file *s, void *unused)
>> > for (index = 0; index < MAX_ZIP_DEVICES; index++) {
>> > if (zip_dev[index]) {
>> > memset(&zip_dev[index]->stats, 0,
>> > - sizeof(struct zip_state));
>> > + sizeof(struct zip_stats));
Yes this resolves the issue.
Thanks for this fix.
Mahipal
>>
>> as future FIXME some show find a name that differ in more than just the last char.
>> NTL maybe
>> sizeof(zip_dev[index]->stats)
>> can be used here ?
>
> That's sort of unweildy. I don't fear that change because I'm confident
> I would catch it with static analysis.
>
> regards,
> dan carpenter
>
^ 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