* [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
* Re: Question - seeding the hw pseudo random number generator
From: Stephan Müller @ 2017-03-20 13:39 UTC (permalink / raw)
To: Herbert Xu
Cc: PrasannaKumar Muralidharan, Krzysztof Kozlowski, Matt Mackall,
linux-crypto, linux-arm-kernel, Jan Glauber, Harald Freudenberger
In-Reply-To: <20170320132858.GA27044@gondor.apana.org.au>
Am Montag, 20. März 2017, 14:28:58 CET schrieb Herbert Xu:
Hi Herbert,
> 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.
IMHO this not only applies to the PRNGs in drivers/crypto (which should simply
register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/
s390/crypto/prng.c which exports a /dev/prandom file.
For the seeding, it may make sense to follow the example given with crypto/
drbg.c using the add_random_ready_callback function.
Ciao
Stephan
^ permalink raw reply
* Re: Question - seeding the hw pseudo random number generator
From: Herbert Xu @ 2017-03-20 13:28 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: linux-arm-kernel, linux-crypto, Krzysztof Kozlowski, Matt Mackall
In-Reply-To: <CANc+2y5gv2ygSM4HF69XCW7Bb8UUHN+qJKq0os-mOvYknH+SeQ@mail.gmail.com>
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.
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
* [PATCH] crypto: zip - add a cast for printing atomic64_t values
From: Arnd Bergmann @ 2017-03-20 12:39 UTC (permalink / raw)
To: Herbert Xu
Cc: Arnd Bergmann, David S. Miller, Mahipal Challa, Jan Glauber,
linux-crypto, linux-kernel
kernelci.org reports a build-time regression on linux-next, with a harmless
warning in x86 allmodconfig:
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
The return type for atomic64_read() unfortunately differs between
architectures, with some defining it as atomic_long_read() and others
returning a 64-bit type explicitly. Fixing this in general would be nice,
but also require changing other users of these functions, so the simpler
workaround is to add a cast here that avoids the warnings on the default
build.
Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/cavium/zip/zip_main.c | 40 ++++++++++++++++++------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_main.c b/drivers/crypto/cavium/zip/zip_main.c
index 0951e20b395b..49f50c0e0308 100644
--- a/drivers/crypto/cavium/zip/zip_main.c
+++ b/drivers/crypto/cavium/zip/zip_main.c
@@ -488,32 +488,32 @@ static int zip_show_stats(struct seq_file *s, void *unused)
atomic64_read(&st->comp_out_bytes));
seq_printf(s, " ZIP Device %d Stats\n"
"-----------------------------------\n"
- "Comp Req Submitted : \t%ld\n"
- "Comp Req Completed : \t%ld\n"
- "Compress In Bytes : \t%ld\n"
- "Compressed Out Bytes : \t%ld\n"
+ "Comp Req Submitted : \t%lld\n"
+ "Comp Req Completed : \t%lld\n"
+ "Compress In Bytes : \t%lld\n"
+ "Compressed Out Bytes : \t%lld\n"
"Average Chunk size : \t%llu\n"
"Average Compression ratio : \t%llu\n"
- "Decomp Req Submitted : \t%ld\n"
- "Decomp Req Completed : \t%ld\n"
- "Decompress In Bytes : \t%ld\n"
- "Decompressed Out Bytes : \t%ld\n"
- "Decompress Bad requests : \t%ld\n"
- "Pending Req : \t%ld\n"
+ "Decomp Req Submitted : \t%lld\n"
+ "Decomp Req Completed : \t%lld\n"
+ "Decompress In Bytes : \t%lld\n"
+ "Decompressed Out Bytes : \t%lld\n"
+ "Decompress Bad requests : \t%lld\n"
+ "Pending Req : \t%lld\n"
"---------------------------------\n",
index,
- atomic64_read(&st->comp_req_submit),
- atomic64_read(&st->comp_req_complete),
- atomic64_read(&st->comp_in_bytes),
- atomic64_read(&st->comp_out_bytes),
+ (u64)atomic64_read(&st->comp_req_submit),
+ (u64)atomic64_read(&st->comp_req_complete),
+ (u64)atomic64_read(&st->comp_in_bytes),
+ (u64)atomic64_read(&st->comp_out_bytes),
avg_chunk,
avg_cr,
- atomic64_read(&st->decomp_req_submit),
- atomic64_read(&st->decomp_req_complete),
- atomic64_read(&st->decomp_in_bytes),
- atomic64_read(&st->decomp_out_bytes),
- atomic64_read(&st->decomp_bad_reqs),
- atomic64_read(&st->pending_req));
+ (u64)atomic64_read(&st->decomp_req_submit),
+ (u64)atomic64_read(&st->decomp_req_complete),
+ (u64)atomic64_read(&st->decomp_in_bytes),
+ (u64)atomic64_read(&st->decomp_out_bytes),
+ (u64)atomic64_read(&st->decomp_bad_reqs),
+ (u64)atomic64_read(&st->pending_req));
/* Reset pending requests count */
atomic64_set(&st->pending_req, 0);
--
2.9.0
^ permalink raw reply related
* [PATCH v2 07/10] x86: assembly, annotate aliases
From: Jiri Slaby @ 2017-03-20 12:32 UTC (permalink / raw)
To: mingo
Cc: tglx, hpa, x86, jpoimboe, linux-kernel, Jiri Slaby, Herbert Xu,
David S. Miller, Boris Ostrovsky, Juergen Gross, linux-crypto,
xen-devel
In-Reply-To: <20170320123222.15453-1-jslaby@suse.cz>
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com> [xen parts]
Cc: <linux-crypto@vger.kernel.org>
Cc: <xen-devel@lists.xenproject.org>
---
arch/x86/crypto/aesni-intel_asm.S | 5 ++---
arch/x86/lib/memcpy_64.S | 4 ++--
arch/x86/lib/memmove_64.S | 4 ++--
arch/x86/lib/memset_64.S | 4 ++--
arch/x86/xen/xen-asm_64.S | 4 ++--
5 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index 8913ea70323c..ea247bfed89d 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
#endif
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b11111111, %xmm1, %xmm1
shufps $0b00010000, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
ENDPROC(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 779782f58324..2d6518b4dbd6 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
* Output:
* rax original destination
*/
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
"jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
EXPORT_SYMBOL(memcpy)
EXPORT_SYMBOL(__memcpy)
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
*/
.weak memmove
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
ENTRY(__memmove)
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
13:
retq
ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
EXPORT_SYMBOL(__memmove)
EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
*
* rax original destination
*/
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
ENTRY(__memset)
/*
* Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
EXPORT_SYMBOL(memset)
EXPORT_SYMBOL(__memset)
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 2a968c087269..b3bf662a4f6a 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
#else /* !CONFIG_IA32_EMULATION */
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
#endif /* CONFIG_IA32_EMULATION */
--
2.12.0
^ permalink raw reply related
* [PATCH v2 06/10] x86: crypto, annotate local functions
From: Jiri Slaby @ 2017-03-20 12:32 UTC (permalink / raw)
To: mingo
Cc: tglx, hpa, x86, jpoimboe, linux-kernel, Jiri Slaby, Herbert Xu,
David S. Miller, linux-crypto
In-Reply-To: <20170320123222.15453-1-jslaby@suse.cz>
Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all
functions which do not have ".globl" annotation, but their ends are
annotated by ENDPROC. This is needed to balance ENDPROC for tools that
are about to generate debuginfo.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <x86@kernel.org>
Cc: <linux-crypto@vger.kernel.org>
---
arch/x86/crypto/aesni-intel_asm.S | 29 ++++++++++------------------
arch/x86/crypto/camellia-aesni-avx-asm_64.S | 10 +++++-----
arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 10 +++++-----
arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 4 ++--
arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 4 ++--
arch/x86/crypto/ghash-clmulni-intel_asm.S | 2 +-
arch/x86/crypto/serpent-avx-x86_64-asm_64.S | 4 ++--
arch/x86/crypto/serpent-avx2-asm_64.S | 4 ++--
arch/x86/crypto/twofish-avx-x86_64-asm_64.S | 4 ++--
9 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index 3c465184ff8a..8913ea70323c 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1746,7 +1746,7 @@ ENDPROC(aesni_gcm_enc)
.align 4
_key_expansion_128:
-_key_expansion_256a:
+SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b11111111, %xmm1, %xmm1
shufps $0b00010000, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1759,8 +1759,7 @@ _key_expansion_256a:
ENDPROC(_key_expansion_128)
ENDPROC(_key_expansion_256a)
-.align 4
-_key_expansion_192a:
+SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
shufps $0b00010000, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1784,8 +1783,7 @@ _key_expansion_192a:
ret
ENDPROC(_key_expansion_192a)
-.align 4
-_key_expansion_192b:
+SYM_FUNC_START_LOCAL(_key_expansion_192b)
pshufd $0b01010101, %xmm1, %xmm1
shufps $0b00010000, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1804,8 +1802,7 @@ _key_expansion_192b:
ret
ENDPROC(_key_expansion_192b)
-.align 4
-_key_expansion_256b:
+SYM_FUNC_START_LOCAL(_key_expansion_256b)
pshufd $0b10101010, %xmm1, %xmm1
shufps $0b00010000, %xmm2, %xmm4
pxor %xmm4, %xmm2
@@ -1968,8 +1965,7 @@ ENDPROC(aesni_enc)
* KEY
* TKEYP (T1)
*/
-.align 4
-_aesni_enc1:
+SYM_FUNC_START_LOCAL(_aesni_enc1)
movaps (KEYP), KEY # key
mov KEYP, TKEYP
pxor KEY, STATE # round 0
@@ -2032,8 +2028,7 @@ ENDPROC(_aesni_enc1)
* KEY
* TKEYP (T1)
*/
-.align 4
-_aesni_enc4:
+SYM_FUNC_START_LOCAL(_aesni_enc4)
movaps (KEYP), KEY # key
mov KEYP, TKEYP
pxor KEY, STATE1 # round 0
@@ -2160,8 +2155,7 @@ ENDPROC(aesni_dec)
* KEY
* TKEYP (T1)
*/
-.align 4
-_aesni_dec1:
+SYM_FUNC_START_LOCAL(_aesni_dec1)
movaps (KEYP), KEY # key
mov KEYP, TKEYP
pxor KEY, STATE # round 0
@@ -2224,8 +2218,7 @@ ENDPROC(_aesni_dec1)
* KEY
* TKEYP (T1)
*/
-.align 4
-_aesni_dec4:
+SYM_FUNC_START_LOCAL(_aesni_dec4)
movaps (KEYP), KEY # key
mov KEYP, TKEYP
pxor KEY, STATE1 # round 0
@@ -2591,8 +2584,7 @@ ENDPROC(aesni_cbc_dec)
* INC: == 1, in little endian
* BSWAP_MASK == endian swapping mask
*/
-.align 4
-_aesni_inc_init:
+SYM_FUNC_START_LOCAL(_aesni_inc_init)
movaps .Lbswap_mask, BSWAP_MASK
movaps IV, CTR
PSHUFB_XMM BSWAP_MASK CTR
@@ -2617,8 +2609,7 @@ ENDPROC(_aesni_inc_init)
* CTR: == output IV, in little endian
* TCTR_LOW: == lower qword of CTR
*/
-.align 4
-_aesni_inc:
+SYM_FUNC_START_LOCAL(_aesni_inc)
paddq INC, CTR
add $1, TCTR_LOW
jnc .Linc_low
diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
index f7c495e2863c..5964d98c4448 100644
--- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S
+++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
@@ -188,7 +188,7 @@
* larger and would only be 0.5% faster (on sandy-bridge).
*/
.align 8
-roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
+SYM_FUNC_START_LOCAL(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
roundsm16(%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
%xmm8, %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm15,
%rcx, (%r9));
@@ -196,7 +196,7 @@ roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
ENDPROC(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
.align 8
-roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab:
+SYM_FUNC_START_LOCAL(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
roundsm16(%xmm4, %xmm5, %xmm6, %xmm7, %xmm0, %xmm1, %xmm2, %xmm3,
%xmm12, %xmm13, %xmm14, %xmm15, %xmm8, %xmm9, %xmm10, %xmm11,
%rax, (%r9));
@@ -721,7 +721,7 @@ ENDPROC(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
.text
.align 8
-__camellia_enc_blk16:
+SYM_FUNC_START_LOCAL(__camellia_enc_blk16)
/* input:
* %rdi: ctx, CTX
* %rax: temporary storage, 256 bytes
@@ -808,7 +808,7 @@ __camellia_enc_blk16:
ENDPROC(__camellia_enc_blk16)
.align 8
-__camellia_dec_blk16:
+SYM_FUNC_START_LOCAL(__camellia_dec_blk16)
/* input:
* %rdi: ctx, CTX
* %rax: temporary storage, 256 bytes
@@ -1119,7 +1119,7 @@ ENDPROC(camellia_ctr_16way)
vpxor tmp, iv, iv;
.align 8
-camellia_xts_crypt_16way:
+SYM_FUNC_START_LOCAL(camellia_xts_crypt_16way)
/* input:
* %rdi: ctx, CTX
* %rsi: dst (16 blocks)
diff --git a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
index eee5b3982cfd..b3dc6fd6868a 100644
--- a/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
+++ b/arch/x86/crypto/camellia-aesni-avx2-asm_64.S
@@ -227,7 +227,7 @@
* larger and would only marginally faster.
*/
.align 8
-roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
+SYM_FUNC_START_LOCAL(roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
roundsm32(%ymm0, %ymm1, %ymm2, %ymm3, %ymm4, %ymm5, %ymm6, %ymm7,
%ymm8, %ymm9, %ymm10, %ymm11, %ymm12, %ymm13, %ymm14, %ymm15,
%rcx, (%r9));
@@ -235,7 +235,7 @@ roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
ENDPROC(roundsm32_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
.align 8
-roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab:
+SYM_FUNC_START_LOCAL(roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
roundsm32(%ymm4, %ymm5, %ymm6, %ymm7, %ymm0, %ymm1, %ymm2, %ymm3,
%ymm12, %ymm13, %ymm14, %ymm15, %ymm8, %ymm9, %ymm10, %ymm11,
%rax, (%r9));
@@ -764,7 +764,7 @@ ENDPROC(roundsm32_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)
.text
.align 8
-__camellia_enc_blk32:
+SYM_FUNC_START_LOCAL(__camellia_enc_blk32)
/* input:
* %rdi: ctx, CTX
* %rax: temporary storage, 512 bytes
@@ -851,7 +851,7 @@ __camellia_enc_blk32:
ENDPROC(__camellia_enc_blk32)
.align 8
-__camellia_dec_blk32:
+SYM_FUNC_START_LOCAL(__camellia_dec_blk32)
/* input:
* %rdi: ctx, CTX
* %rax: temporary storage, 512 bytes
@@ -1226,7 +1226,7 @@ ENDPROC(camellia_ctr_32way)
vpxor tmp1, iv, iv;
.align 8
-camellia_xts_crypt_32way:
+SYM_FUNC_START_LOCAL(camellia_xts_crypt_32way)
/* input:
* %rdi: ctx, CTX
* %rsi: dst (32 blocks)
diff --git a/arch/x86/crypto/cast5-avx-x86_64-asm_64.S b/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
index b4a8806234ea..eb99d6b810f7 100644
--- a/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/cast5-avx-x86_64-asm_64.S
@@ -224,7 +224,7 @@
.text
.align 16
-__cast5_enc_blk16:
+SYM_FUNC_START_LOCAL(__cast5_enc_blk16)
/* input:
* %rdi: ctx, CTX
* RL1: blocks 1 and 2
@@ -296,7 +296,7 @@ __cast5_enc_blk16:
ENDPROC(__cast5_enc_blk16)
.align 16
-__cast5_dec_blk16:
+SYM_FUNC_START_LOCAL(__cast5_dec_blk16)
/* input:
* %rdi: ctx, CTX
* RL1: encrypted blocks 1 and 2
diff --git a/arch/x86/crypto/cast6-avx-x86_64-asm_64.S b/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
index 952d3156a933..4f15c83e0118 100644
--- a/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/cast6-avx-x86_64-asm_64.S
@@ -262,7 +262,7 @@
.text
.align 8
-__cast6_enc_blk8:
+SYM_FUNC_START_LOCAL(__cast6_enc_blk8)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -308,7 +308,7 @@ __cast6_enc_blk8:
ENDPROC(__cast6_enc_blk8)
.align 8
-__cast6_dec_blk8:
+SYM_FUNC_START_LOCAL(__cast6_dec_blk8)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: encrypted blocks
diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S
index f94375a8dcd1..6d5d80074394 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_asm.S
+++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S
@@ -47,7 +47,7 @@
* T2
* T3
*/
-__clmul_gf128mul_ble:
+SYM_FUNC_START_LOCAL(__clmul_gf128mul_ble)
movaps DATA, T1
pshufd $0b01001110, DATA, T2
pshufd $0b01001110, SHASH, T3
diff --git a/arch/x86/crypto/serpent-avx-x86_64-asm_64.S b/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
index 2925077f8c6a..8301f918c50f 100644
--- a/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/serpent-avx-x86_64-asm_64.S
@@ -570,7 +570,7 @@
transpose_4x4(x0, x1, x2, x3, t0, t1, t2)
.align 8
-__serpent_enc_blk8_avx:
+SYM_FUNC_START_LOCAL(__serpent_enc_blk8_avx)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -624,7 +624,7 @@ __serpent_enc_blk8_avx:
ENDPROC(__serpent_enc_blk8_avx)
.align 8
-__serpent_dec_blk8_avx:
+SYM_FUNC_START_LOCAL(__serpent_dec_blk8_avx)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: encrypted blocks
diff --git a/arch/x86/crypto/serpent-avx2-asm_64.S b/arch/x86/crypto/serpent-avx2-asm_64.S
index d67888f2a52a..b011a7ff1d9c 100644
--- a/arch/x86/crypto/serpent-avx2-asm_64.S
+++ b/arch/x86/crypto/serpent-avx2-asm_64.S
@@ -566,7 +566,7 @@
transpose_4x4(x0, x1, x2, x3, t0, t1, t2)
.align 8
-__serpent_enc_blk16:
+SYM_FUNC_START_LOCAL(__serpent_enc_blk16)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: plaintext
@@ -620,7 +620,7 @@ __serpent_enc_blk16:
ENDPROC(__serpent_enc_blk16)
.align 8
-__serpent_dec_blk16:
+SYM_FUNC_START_LOCAL(__serpent_dec_blk16)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: ciphertext
diff --git a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
index b3f49d286348..cf771166b04a 100644
--- a/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
+++ b/arch/x86/crypto/twofish-avx-x86_64-asm_64.S
@@ -249,7 +249,7 @@
vpxor x3, wkey, x3;
.align 8
-__twofish_enc_blk8:
+SYM_FUNC_START_LOCAL(__twofish_enc_blk8)
/* input:
* %rdi: ctx, CTX
* RA1, RB1, RC1, RD1, RA2, RB2, RC2, RD2: blocks
@@ -291,7 +291,7 @@ __twofish_enc_blk8:
ENDPROC(__twofish_enc_blk8)
.align 8
-__twofish_dec_blk8:
+SYM_FUNC_START_LOCAL(__twofish_dec_blk8)
/* input:
* %rdi: ctx, CTX
* RC1, RD1, RA1, RB1, RC2, RD2, RA2, RB2: encrypted blocks
--
2.12.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox