* [PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure
From: Eric Biggers @ 2017-03-23 20:39 UTC (permalink / raw)
To: linux-crypto
Cc: Herbert Xu, David S . Miller, linux-kernel, Dmitry Vyukov,
syzkaller, Eric Biggers, stable
In-Reply-To: <CACT4Y+ZnQq9x7gXTpaRxnMSh_2Uk461J9CWnoq3i5KQBY-nLGw@mail.gmail.com>
From: Eric Biggers <ebiggers@google.com>
In the generic XTS and LRW algorithms, for input data > 128 bytes, a
temporary buffer is allocated to hold the values to be XOR'ed with the
data before and after encryption or decryption. If the allocation
fails, the fixed-size buffer embedded in the request buffer is meant to
be used as a fallback --- resulting in more calls to the ECB algorithm,
but still producing the correct result. However, we weren't correctly
limiting subreq->cryptlen in this case, resulting in pre_crypt()
overrunning the embedded buffer. Fix this by setting subreq->cryptlen
correctly.
Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Cc: stable@vger.kernel.org # v4.10+
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/lrw.c | 7 +++++--
crypto/xts.c | 7 +++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index ecd8474018e3..3ea095adafd9 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -286,8 +286,11 @@ static int init_crypt(struct skcipher_request *req, crypto_completion_t done)
subreq->cryptlen = LRW_BUFFER_SIZE;
if (req->cryptlen > LRW_BUFFER_SIZE) {
- subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
- rctx->ext = kmalloc(subreq->cryptlen, gfp);
+ unsigned int n = min(req->cryptlen, (unsigned int)PAGE_SIZE);
+
+ rctx->ext = kmalloc(n, gfp);
+ if (rctx->ext)
+ subreq->cryptlen = n;
}
rctx->src = req->src;
diff --git a/crypto/xts.c b/crypto/xts.c
index baeb34dd8582..c976bfac29da 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -230,8 +230,11 @@ static int init_crypt(struct skcipher_request *req, crypto_completion_t done)
subreq->cryptlen = XTS_BUFFER_SIZE;
if (req->cryptlen > XTS_BUFFER_SIZE) {
- subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
- rctx->ext = kmalloc(subreq->cryptlen, gfp);
+ unsigned int n = min(req->cryptlen, (unsigned int)PAGE_SIZE);
+
+ rctx->ext = kmalloc(n, gfp);
+ if (rctx->ext)
+ subreq->cryptlen = n;
}
rctx->src = req->src;
--
2.12.1.500.gab5fba24ee-goog
^ permalink raw reply related
* Re: [PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure
From: David Miller @ 2017-03-23 21:05 UTC (permalink / raw)
To: ebiggers3
Cc: linux-crypto, herbert, linux-kernel, dvyukov, syzkaller, ebiggers,
stable
In-Reply-To: <20170323203946.11242-1-ebiggers3@gmail.com>
From: Eric Biggers <ebiggers3@gmail.com>
Date: Thu, 23 Mar 2017 13:39:46 -0700
> From: Eric Biggers <ebiggers@google.com>
>
> In the generic XTS and LRW algorithms, for input data > 128 bytes, a
> temporary buffer is allocated to hold the values to be XOR'ed with the
> data before and after encryption or decryption. If the allocation
> fails, the fixed-size buffer embedded in the request buffer is meant to
> be used as a fallback --- resulting in more calls to the ECB algorithm,
> but still producing the correct result. However, we weren't correctly
> limiting subreq->cryptlen in this case, resulting in pre_crypt()
> overrunning the embedded buffer. Fix this by setting subreq->cryptlen
> correctly.
>
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
> Cc: stable@vger.kernel.org # v4.10+
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [ANNOUNCE] Linux Security Summit 2017 - CFP
From: James Morris @ 2017-03-24 1:26 UTC (permalink / raw)
To: linux-security-module, linux-kernel
Cc: lwn, fedora-selinux-list, selinux,
Linux Security Summit Program Committee, ubuntu-hardened,
netfilter-devel, linux-crypto, Audit-ML, gentoo-hardened,
keyrings, tpmdd-devel, kernel-hardening, oss-security, openxt,
tee-dev
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
==============================================================================
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT 2017
14-15 September
LOS ANGELES, USA
==============================================================================
DESCRIPTION
The Linux Security Summit (LSS) is a technical forum for collaboration
between Linux developers, researchers, and end users. Its primary aim is to
foster community efforts in analyzing and solving Linux security challenges.
LSS this year will be co-located with the Open Source Summit and the Linux
Plumbers Conference.
The program committee currently seeks proposals for:
* Refereed Presentations:
45 minutes in length, including at least 10 minutes of discussion.
* Discussion Topics:
30 minutes in length.
Topic areas include, but are not limited to:
* Kernel self-protection
* Access control
* Cryptography and key management
* Integrity control
* Hardware Security
* Iot and embedded security
* Virtualization and containers
* System-specific system hardening
* Case studies
* Security tools
* Security UX
* Emerging technologies, threats & techniques
Proposals should be submitted via:
http://events.linuxfoundation.org/events/linux-security-summit/program/cfp
DATES
* CFP Close: June 5, 2017
* CFP Notifications: June 12, 2017
* Schedule Announced: June 19, 2017
* Slide Submission: August 31, 2017
WHO SHOULD ATTEND
We're seeking a diverse range of attendees, and welcome participation by
people involved in Linux security development, operations, and research.
The LSS is a unique global event which provides the opportunity to present
and discuss your work or research with key Linux security community members
and maintainers. It’s also useful for those who wish to keep up with the
latest in Linux security development, and to provide input to the
development process.
WEB SITE
http://events.linuxfoundation.org/events/linux-security-summit
TWITTER
For event updates and announcements, follow:
https://twitter.com/LinuxSecSummit
PROGRAM COMMITTEE
The program committee for LSS 2017 is:
* James Morris, Oracle
* Serge Hallyn, Canonical
* Paul Moore, Red Hat
* Stephen Smalley, NSA
* Elena Reshetova, Intel
* John Johansen, Canonical
* Kees Cook, Google
* Casey Schaufler, Intel
* Mimi Zohar, IBM
* David A. Wheeler, Institute for Defense Analyses
The program committee may be contacted as a group via email:
lss-pc () lists.linuxfoundation.org
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1012a: add crypto node
From: Shawn Guo @ 2017-03-24 1:56 UTC (permalink / raw)
To: Horia Geantă
Cc: Rob Herring, Mark Rutland, devicetree, Herbert Xu, Harninder Rai,
Catalin Marinas, Bhaskar Upadhaya, Will Deacon, Dan Douglass,
linux-crypto, David S. Miller, linux-arm-kernel
In-Reply-To: <20170322122939.22117-1-horia.geanta@nxp.com>
On Wed, Mar 22, 2017 at 02:29:39PM +0200, Horia Geantă wrote:
> LS1012A has a SEC v5.4 security engine.
>
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 9 +++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 9 +++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 9 +++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 91 +++++++++++++++++++++-
> 4 files changed, 117 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> index a619f6496a4c..bab9e68947e4 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> @@ -49,6 +49,15 @@
> model = "LS1012A Freedom Board";
> compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
>
> + aliases {
> + crypto = &crypto;
> + rtic_a = &rtic_a;
> + rtic_b = &rtic_b;
> + rtic_c = &rtic_c;
> + rtic_d = &rtic_d;
> + sec_mon = &sec_mon;
> + };
> +
> sys_mclk: clock-mclk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> index 14a67f1709e7..5c4e84c7f20d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> @@ -49,6 +49,15 @@
> model = "LS1012A QDS Board";
> compatible = "fsl,ls1012a-qds", "fsl,ls1012a";
>
> + aliases {
> + crypto = &crypto;
> + rtic_a = &rtic_a;
> + rtic_b = &rtic_b;
> + rtic_c = &rtic_c;
> + rtic_d = &rtic_d;
> + sec_mon = &sec_mon;
> + };
> +
> sys_mclk: clock-mclk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> index 62c5c7123a15..ff9dd16aa65a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> @@ -48,6 +48,15 @@
> / {
> model = "LS1012A RDB Board";
> compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
> +
> + aliases {
> + crypto = &crypto;
> + rtic_a = &rtic_a;
> + rtic_b = &rtic_b;
> + rtic_c = &rtic_c;
> + rtic_d = &rtic_d;
> + sec_mon = &sec_mon;
> + };
What are these aliases used for? Are they board specific? If not, we
should probably have them in fsl-ls1012a.dtsi, since you are adding
them for all three fsl-ls1012a based boards.
> };
>
> &duart0 {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> index cffebb4b3df1..68f3012ae07e 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> @@ -42,7 +42,7 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> */
>
> -#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>
> / {
> compatible = "fsl,ls1012a";
> @@ -113,6 +113,95 @@
> big-endian;
> };
>
> + crypto: crypto@1700000 {
> + compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
> + "fsl,sec-v4.0";
> + fsl,sec-era = <8>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x1700000 0x100000>;
> + reg = <0x00 0x1700000 0x0 0x100000>;
> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> +
> + sec_jr0: jr@10000 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x10000 0x10000>;
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr1: jr@20000 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x20000 0x10000>;
> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr2: jr@30000 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x30000 0x10000>;
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + sec_jr3: jr@40000 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg = <0x40000 0x10000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + rtic@60000 {
> + compatible = "fsl,sec-v5.4-rtic",
> + "fsl,sec-v5.0-rtic",
> + "fsl,sec-v4.0-rtic";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x60000 0x100 0x60e00 0x18>;
> + ranges = <0x0 0x60100 0x500>;
> +
> + rtic_a: rtic-a@0 {
> + compatible = "fsl,sec-v5.4-rtic-memory",
> + "fsl,sec-v5.0-rtic-memory",
> + "fsl,sec-v4.0-rtic-memory";
> + reg = <0x00 0x20 0x100 0x100>;
> + };
> +
> + rtic_b: rtic-b@20 {
> + compatible = "fsl,sec-v5.4-rtic-memory",
> + "fsl,sec-v5.0-rtic-memory",
> + "fsl,sec-v4.0-rtic-memory";
> + reg = <0x20 0x20 0x200 0x100>;
> + };
> +
> + rtic_c: rtic-c@40 {
> + compatible = "fsl,sec-v5.4-rtic-memory",
> + "fsl,sec-v5.0-rtic-memory",
> + "fsl,sec-v4.0-rtic-memory";
> + reg = <0x40 0x20 0x300 0x100>;
> + };
> +
> + rtic_d: rtic-d@60 {
> + compatible = "fsl,sec-v5.4-rtic-memory",
> + "fsl,sec-v5.0-rtic-memory",
> + "fsl,sec-v4.0-rtic-memory";
> + reg = <0x60 0x20 0x400 0x100>;
> + };
> + };
> + };
> +
> + sec_mon: sec_mon@1e90000 {
Hyphen is more preferred to be used in node name than underscore.
Shawn
> + compatible = "fsl,sec-v5.4-mon", "fsl,sec-v5.0-mon",
> + "fsl,sec-v4.0-mon";
> + reg = <0x0 0x1e90000 0x0 0x10000>;
> + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> dcfg: dcfg@1ee0000 {
> compatible = "fsl,ls1012a-dcfg",
> "syscon";
> --
> 2.12.0.264.gd6db3f216544
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/5] crypto: stm32 - Support for STM32 CRC32 crypto module
From: PrasannaKumar Muralidharan @ 2017-03-24 4:28 UTC (permalink / raw)
To: Fabien Dessenne
Cc: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel, Benjamin Gaignard
In-Reply-To: <1490109211-4869-3-git-send-email-fabien.dessenne@st.com>
On 21 March 2017 at 20:43, Fabien Dessenne <fabien.dessenne@st.com> wrote:
> 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.
Comparing with crc3c-generic alogrithm does not sound like a good
metric for someone who has to decide between hw crypto or not.
Wouldn't it be better if the comparison is between crc32 using NEON
with hw crypto module? It will help in choosing between hw crypto or
arch optimised crc routiene.
> 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,
> + }
> + }
> +};
Will be better if the priority is based on benchmark result. ARM arch
optimised crc32 also defines its priority as 200. Choose a higher
priority if the hw crypto is either faster or consumes less power.
Regards,
PrasannaKumar
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1012a: add crypto node
From: Horia Geantă @ 2017-03-24 7:17 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Herbert Xu,
Harninder Rai, Catalin Marinas, Bhaskar U, Will Deacon,
Dan Douglass,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170324015606.GC30608@dragon>
On 3/24/2017 3:56 AM, Shawn Guo wrote:
> On Wed, Mar 22, 2017 at 02:29:39PM +0200, Horia Geantă wrote:
>> LS1012A has a SEC v5.4 security engine.
>>
>> Signed-off-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 9 +++
>> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 9 +++
>> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 9 +++
>> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 91 +++++++++++++++++++++-
>> 4 files changed, 117 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> index a619f6496a4c..bab9e68947e4 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
>> @@ -49,6 +49,15 @@
>> model = "LS1012A Freedom Board";
>> compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
>>
>> + aliases {
>> + crypto = &crypto;
>> + rtic_a = &rtic_a;
>> + rtic_b = &rtic_b;
>> + rtic_c = &rtic_c;
>> + rtic_d = &rtic_d;
>> + sec_mon = &sec_mon;
>> + };
>> +
>> sys_mclk: clock-mclk {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> index 14a67f1709e7..5c4e84c7f20d 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
>> @@ -49,6 +49,15 @@
>> model = "LS1012A QDS Board";
>> compatible = "fsl,ls1012a-qds", "fsl,ls1012a";
>>
>> + aliases {
>> + crypto = &crypto;
>> + rtic_a = &rtic_a;
>> + rtic_b = &rtic_b;
>> + rtic_c = &rtic_c;
>> + rtic_d = &rtic_d;
>> + sec_mon = &sec_mon;
>> + };
>> +
>> sys_mclk: clock-mclk {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> index 62c5c7123a15..ff9dd16aa65a 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
>> @@ -48,6 +48,15 @@
>> / {
>> model = "LS1012A RDB Board";
>> compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
>> +
>> + aliases {
>> + crypto = &crypto;
>> + rtic_a = &rtic_a;
>> + rtic_b = &rtic_b;
>> + rtic_c = &rtic_c;
>> + rtic_d = &rtic_d;
>> + sec_mon = &sec_mon;
>> + };
>
> What are these aliases used for? Are they board specific? If not, we
> should probably have them in fsl-ls1012a.dtsi, since you are adding
> them for all three fsl-ls1012a based boards.
>
Indeed, these can be shared and thus should be moved to
fsl-ls1012a.dtsi. Will be fixed in v2.
crypto alias is used in u-boot to fixup the crypto node with a
"fsl,sec-era" property.
rtic and sec_mon aliases have been added to be in line with the PPC
device trees, I am not aware how they are used.
>> };
>>
>> &duart0 {
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> index cffebb4b3df1..68f3012ae07e 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>> @@ -42,7 +42,7 @@
>> * OTHER DEALINGS IN THE SOFTWARE.
>> */
>>
>> -#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>
>> / {
>> compatible = "fsl,ls1012a";
>> @@ -113,6 +113,95 @@
>> big-endian;
>> };
>>
>> + crypto: crypto@1700000 {
>> + compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
>> + "fsl,sec-v4.0";
>> + fsl,sec-era = <8>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x00 0x1700000 0x100000>;
>> + reg = <0x00 0x1700000 0x0 0x100000>;
>> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + sec_jr0: jr@10000 {
>> + compatible = "fsl,sec-v5.4-job-ring",
>> + "fsl,sec-v5.0-job-ring",
>> + "fsl,sec-v4.0-job-ring";
>> + reg = <0x10000 0x10000>;
>> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + sec_jr1: jr@20000 {
>> + compatible = "fsl,sec-v5.4-job-ring",
>> + "fsl,sec-v5.0-job-ring",
>> + "fsl,sec-v4.0-job-ring";
>> + reg = <0x20000 0x10000>;
>> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + sec_jr2: jr@30000 {
>> + compatible = "fsl,sec-v5.4-job-ring",
>> + "fsl,sec-v5.0-job-ring",
>> + "fsl,sec-v4.0-job-ring";
>> + reg = <0x30000 0x10000>;
>> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + sec_jr3: jr@40000 {
>> + compatible = "fsl,sec-v5.4-job-ring",
>> + "fsl,sec-v5.0-job-ring",
>> + "fsl,sec-v4.0-job-ring";
>> + reg = <0x40000 0x10000>;
>> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + rtic@60000 {
>> + compatible = "fsl,sec-v5.4-rtic",
>> + "fsl,sec-v5.0-rtic",
>> + "fsl,sec-v4.0-rtic";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x60000 0x100 0x60e00 0x18>;
>> + ranges = <0x0 0x60100 0x500>;
>> +
>> + rtic_a: rtic-a@0 {
>> + compatible = "fsl,sec-v5.4-rtic-memory",
>> + "fsl,sec-v5.0-rtic-memory",
>> + "fsl,sec-v4.0-rtic-memory";
>> + reg = <0x00 0x20 0x100 0x100>;
>> + };
>> +
>> + rtic_b: rtic-b@20 {
>> + compatible = "fsl,sec-v5.4-rtic-memory",
>> + "fsl,sec-v5.0-rtic-memory",
>> + "fsl,sec-v4.0-rtic-memory";
>> + reg = <0x20 0x20 0x200 0x100>;
>> + };
>> +
>> + rtic_c: rtic-c@40 {
>> + compatible = "fsl,sec-v5.4-rtic-memory",
>> + "fsl,sec-v5.0-rtic-memory",
>> + "fsl,sec-v4.0-rtic-memory";
>> + reg = <0x40 0x20 0x300 0x100>;
>> + };
>> +
>> + rtic_d: rtic-d@60 {
>> + compatible = "fsl,sec-v5.4-rtic-memory",
>> + "fsl,sec-v5.0-rtic-memory",
>> + "fsl,sec-v4.0-rtic-memory";
>> + reg = <0x60 0x20 0x400 0x100>;
>> + };
>> + };
>> + };
>> +
>> + sec_mon: sec_mon@1e90000 {
>
> Hyphen is more preferred to be used in node name than underscore.
>
This would imply changing the
Documentation/devicetree/bindings/crypto/fsl-sec4.txt binding and
dealing with all the consequences, which IIUC is probably not worth.
Thanks,
Horia
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1012a: add crypto node
From: Shawn Guo @ 2017-03-24 7:34 UTC (permalink / raw)
To: Horia Geantă
Cc: Mark Rutland, devicetree@vger.kernel.org, Herbert Xu,
Harninder Rai, Catalin Marinas, Bhaskar U, Will Deacon,
Dan Douglass, Rob Herring, linux-crypto@vger.kernel.org,
David S. Miller, linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB4PR04MB0847D837CB2762D5094720CB983E0@DB4PR04MB0847.eurprd04.prod.outlook.com>
On Fri, Mar 24, 2017 at 07:17:50AM +0000, Horia Geantă wrote:
> >> + sec_mon: sec_mon@1e90000 {
> >
> > Hyphen is more preferred to be used in node name than underscore.
> >
> This would imply changing the
> Documentation/devicetree/bindings/crypto/fsl-sec4.txt binding and
> dealing with all the consequences, which IIUC is probably not worth.
I do not care the bindings doc that much, since I'm not the maintainer
of it. What are the consequences specifically, if we use a better node
name in dts than bindings example?
Shawn
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1012a: add crypto node
From: Horia Geantă @ 2017-03-24 8:29 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree@vger.kernel.org, Herbert Xu,
Harninder Rai, Catalin Marinas, Bhaskar U, Will Deacon,
Dan Douglass, Rob Herring, linux-crypto@vger.kernel.org,
David S. Miller, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170324073420.GM30608@dragon>
On 3/24/2017 9:35 AM, Shawn Guo wrote:
> On Fri, Mar 24, 2017 at 07:17:50AM +0000, Horia Geantă wrote:
>>>> + sec_mon: sec_mon@1e90000 {
>>>
>>> Hyphen is more preferred to be used in node name than underscore.
>>>
>> This would imply changing the
>> Documentation/devicetree/bindings/crypto/fsl-sec4.txt binding and
>> dealing with all the consequences, which IIUC is probably not worth.
>
> I do not care the bindings doc that much, since I'm not the maintainer
> of it. What are the consequences specifically, if we use a better node
> name in dts than bindings example?
>
Users relying on finding the sec_mon node will obviously stop working.
I don't see any in-kernel users, however there could be others I am not
aware of and DT bindings should provide for backwards compatibility.
I could deprecate "sec_mon" in the bindings and suggest "sec-mon"
instead, while leaving all existing dts files as-is.
The risk is breaking LS1012A users relying on "sec_mon".
I see that ePAPR:
-allows both for hyphen and underline in case of node names
-allows only for hyphen (i.e. forbids underline) in case of alias nodes
In the first case, I understand there's an (undocumented?) agreement to
prefer hyphen over underline.
For the 2nd one, does this mean I should change alias names?
Thanks,
Horia
^ permalink raw reply
* Re: [PATCH] padata: avoid race in reordering
From: Steffen Klassert @ 2017-03-24 9:41 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Linux Crypto Mailing List, LKML, Netdev
In-Reply-To: <20170323112443.30843-1-Jason@zx2c4.com>
On Thu, Mar 23, 2017 at 12:24:43PM +0100, Jason A. Donenfeld wrote:
> Under extremely heavy uses of padata, crashes occur, and with list
> debugging turned on, this happens instead:
>
> [87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
> __list_add+0xae/0x130
> [87487.301868] list_add corruption. prev->next should be next
> (ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
> [87487.339011] [<ffffffff9a53d075>] dump_stack+0x68/0xa3
> [87487.342198] [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
> [87487.345364] [<ffffffff99d6b91f>] __warn+0xff/0x140
> [87487.348513] [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
> [87487.351659] [<ffffffff9a58b5de>] __list_add+0xae/0x130
> [87487.354772] [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
> [87487.357915] [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
> [87487.361084] [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
>
> padata_reorder calls list_add_tail with the list to which its adding
> locked, which seems correct:
>
> spin_lock(&squeue->serial.lock);
> list_add_tail(&padata->list, &squeue->serial.list);
> spin_unlock(&squeue->serial.lock);
>
> This therefore leaves only place where such inconsistency could occur:
> if padata->list is added at the same time on two different threads.
> This pdata pointer comes from the function call to
> padata_get_next(pd), which has in it the following block:
>
> next_queue = per_cpu_ptr(pd->pqueue, cpu);
> padata = NULL;
> reorder = &next_queue->reorder;
> if (!list_empty(&reorder->list)) {
> padata = list_entry(reorder->list.next,
> struct padata_priv, list);
> spin_lock(&reorder->lock);
> list_del_init(&padata->list);
> atomic_dec(&pd->reorder_objects);
> spin_unlock(&reorder->lock);
>
> pd->processed++;
>
> goto out;
> }
> out:
> return padata;
>
> I strongly suspect that the problem here is that two threads can race
> on reorder list. Even though the deletion is locked, call to
> list_entry is not locked, which means it's feasible that two threads
> pick up the same padata object and subsequently call list_add_tail on
> them at the same time. The fix is thus be hoist that lock outside of
> that block.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] crypto: stm32 - Support for STM32 CRC32 crypto module
From: Fabien DESSENNE @ 2017-03-24 9:56 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
Russell King, Rob Herring, linux-crypto@vger.kernel.org,
Maxime Coquelin, Benjamin GAIGNARD, David S . Miller,
linux-arm-kernel@lists.infradead.org, Herbert Xu
In-Reply-To: <CANc+2y4w=HhB230CD4MfxhvFZ2vM7Wsphz0zawhr0nVDSkREzQ@mail.gmail.com>
On 24/03/17 05:28, PrasannaKumar Muralidharan wrote:
> On 21 March 2017 at 20:43, Fabien Dessenne <fabien.dessenne@st.com> wrote:
>> 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.
> Comparing with crc3c-generic alogrithm does not sound like a good
> metric for someone who has to decide between hw crypto or not.
> Wouldn't it be better if the comparison is between crc32 using NEON
> with hw crypto module? It will help in choosing between hw crypto or
> arch optimised crc routiene.
The STM32 microcontrollers are based on ARM Cortex-M7 (or older core)
that do not have NEON support.
Moreover, the purpose of this introduction is not to provide with a
(full) benchmark. It just gives a hint of the HW performance.
>> 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,
>> + }
>> + }
>> +};
> Will be better if the priority is based on benchmark result. ARM arch
> optimised crc32 also defines its priority as 200. Choose a higher
> priority if the hw crypto is either faster or consumes less power.
>
> Regards,
> PrasannaKumar
^ permalink raw reply
* Re: [PATCH v2 2/5] crypto: stm32 - Support for STM32 CRC32 crypto module
From: PrasannaKumar Muralidharan @ 2017-03-24 10:00 UTC (permalink / raw)
To: Fabien DESSENNE
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
Russell King, Rob Herring, linux-crypto@vger.kernel.org,
Maxime Coquelin, Benjamin GAIGNARD, David S . Miller,
linux-arm-kernel@lists.infradead.org, Herbert Xu
In-Reply-To: <a6c05e57-bdcc-4396-4a72-4d1b2977b8e4@st.com>
On 24 March 2017 at 15:26, Fabien DESSENNE <fabien.dessenne@st.com> wrote:
> On 24/03/17 05:28, PrasannaKumar Muralidharan wrote:
>> On 21 March 2017 at 20:43, Fabien Dessenne <fabien.dessenne@st.com> wrote:
>>> 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.
>> Comparing with crc3c-generic alogrithm does not sound like a good
>> metric for someone who has to decide between hw crypto or not.
>> Wouldn't it be better if the comparison is between crc32 using NEON
>> with hw crypto module? It will help in choosing between hw crypto or
>> arch optimised crc routiene.
>
> The STM32 microcontrollers are based on ARM Cortex-M7 (or older core)
> that do not have NEON support.
I was not aware of the absence of NEON support. Sorry for the noise.
^ permalink raw reply
* Crypto Fixes for 4.11
From: Herbert Xu @ 2017-03-24 13:46 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20170315063151.GA6767@gondor.apana.org.au>
Hi Linus:
This push fixes regressions in the crypto ccp driver and the
hwrng drivers amd and geode.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Gary R Hook (1):
crypto: ccp - Assign DMA commands to the channel's CCP
Prarit Bhargava (2):
hwrng: amd - Revert managed API changes
hwrng: geode - Revert managed API changes
drivers/char/hw_random/amd-rng.c | 42 ++++++++++++++++++++++++------
drivers/char/hw_random/geode-rng.c | 50 +++++++++++++++++++++++++-----------
drivers/crypto/ccp/ccp-dev.c | 5 +++-
drivers/crypto/ccp/ccp-dmaengine.c | 1 +
include/linux/ccp.h | 2 +-
5 files changed, 75 insertions(+), 25 deletions(-)
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 6/7] md/raid10, LLVM: get rid of variable length array
From: Dmitry Vyukov @ 2017-03-24 13:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, Michael Davidson, Alexander Potapenko,
Michal Marek, Thomas Gleixner, Ingo Molnar, Herbert Xu,
David S. Miller, Shaohua Li, Matthias Kaehlcke, x86@kernel.org,
open list:KERNEL BUILD + fi..., LKML, linux-crypto, linux-raid
In-Reply-To: <96158847-4F1F-4293-8435-E111F39E3260@zytor.com>
On Fri, Mar 17, 2017 at 9:04 PM, <hpa@zytor.com> wrote:
> On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>>On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
>>> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra
>><peterz@infradead.org> wrote:
>>> >
>>> > Be that as it may; what you construct above is disgusting. Surely
>>the
>>> > code can be refactored to not look like dog vomit?
>>> >
>>> > Also; its not immediately obvious conf->copies is 'small' and this
>>> > doesn't blow up the stack; I feel that deserves a comment
>>somewhere.
>>> >
>>>
>>> I agree that the code is horrible.
>>>
>>> It is, in fact, exactly the same solution that was used to remove
>>> variable length arrays in structs from several of the crypto drivers
>>a
>>> few years ago - see the definition of SHASH_DESC_ON_STACK() in
>>> "crypto/hash.h" - I did not, however, hide the horrors in a macro
>>> preferring to leave the implementation visible as a warning to
>>whoever
>>> might touch the code next.
>>>
>>> I believe that the actual stack usage is exactly the same as it was
>>previously.
>>>
>>> I can certainly wrap this up in a macro and add comments with
>>> appropriately dire warnings in it if you feel that is both necessary
>>> and sufficient.
>>
>>We got away with ugly in the past, so we should get to do it again?
>
> Seriously, you should have taken the hack the first time that this needs to be fixed. Just because this is a fairly uncommon construct in the kernel doesn't mean it is not in userspace.
There is a reason why it is fairly uncommon in kernel.
Initially it was used more widely, but then there was a decision to
drop all uses of this feature. Namely:
Linus: "We should definitely drop it. The feature is an abomination".
https://lkml.org/lkml/2013/9/23/500
I really don't understand why you cling onto this last use of the
feature. Having a single use of a compiler extension on an error path
of a non-mandatory driver does not look like a great idea to me. Let's
just kill it off outside of clang discussion.
^ permalink raw reply
* Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array
From: Dmitry Vyukov @ 2017-03-24 13:50 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Borislav Petkov, Alexander Potapenko, Michael Davidson,
Michal Marek, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Herbert Xu, David S. Miller, Shaohua Li, Matthias Kaehlcke,
x86@kernel.org, open list:KERNEL BUILD + fi..., LKML,
linux-crypto, linux-raid, kbuild-all, Fengguang Wu
In-Reply-To: <20170317192935.d5almj4brat6uvlt@hirez.programming.kicks-ass.net>
On Fri, Mar 17, 2017 at 8:29 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Mar 17, 2017 at 08:26:42PM +0100, Peter Zijlstra wrote:
>> On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
>> > You can also find some reasons in the Why section of LLVM-Linux project:
>> > http://llvm.linuxfoundation.org/index.php/Main_Page
>>
>> From that:
>>
>> - LLVM/Clang is a fast moving project with many things fixed quickly
>> and features added.
>>
>> So what's the deal with that 5 year old bug you want us to work around?
>>
>> Also, clang doesn't support asm cc flags output and a few other
>> extensions last time I checked.
>>
>
> Another great one:
>
> - BSD License (some people prefer this license to the GPL)
>
> Seems a very weak argument to make when talking about the Linux Kernel
> which is very explicitly GPLv2 (and not later).
OK, I guess should not have referenced the llvm-linux page.
So here are reasons on our side that I am ready to vouch:
- clang make it possible to implement KMSAN (dynamic detection of
uses of uninit memory)
- better code coverage for fuzzing
- why simpler and faster development (e.g. we can port our user-space
hardening technologies -- CFI and SafeStack)
Michael is on a different team and has own reasons to do this.
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: rng: clocks property on omap_rng not always mandatory
From: Rob Herring @ 2017-03-24 13:52 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: devicetree, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
Herbert Xu, linux-crypto, romain.perier, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, stable
In-Reply-To: <1489755519-32664-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Fri, Mar 17, 2017 at 01:58:39PM +0100, Thomas Petazzoni wrote:
> Commit 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76
> device variant") update the omap_rng Device Tree binding to add support
> for the IP-76 variation of the IP. As part of this change, a "clocks"
> property was added, but is indicated as "Required", without indicated
> it's actually only required for some compatible strings.
>
> This commit fixes that, by explicitly stating that the clocks property
> is only required with the inside-secure,safexcel-eip76 compatible
> string.
>
> Fixes: 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76 device variant")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> Changes since v1:
> - Instead of indicating the property as optional, indicate it as
> mandatory for the inside-secure,safexcel-eip76 compatible string, as
> suggested by Rob Herring.
> ---
> Documentation/devicetree/bindings/rng/omap_rng.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1012a: add crypto node
From: Shawn Guo @ 2017-03-24 14:03 UTC (permalink / raw)
To: Horia Geantă
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Herbert Xu, Harninder Rai, Catalin Marinas, Bhaskar U,
Will Deacon, Dan Douglass, Rob Herring,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <DB4PR04MB0847E3EE8F7FAC11DD85FAA8983E0-tLF+feb1Bz4/w1fYxD+T089NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Fri, Mar 24, 2017 at 08:29:17AM +0000, Horia Geantă wrote:
> On 3/24/2017 9:35 AM, Shawn Guo wrote:
> > On Fri, Mar 24, 2017 at 07:17:50AM +0000, Horia Geantă wrote:
> >>>> + sec_mon: sec_mon@1e90000 {
> >>>
> >>> Hyphen is more preferred to be used in node name than underscore.
> >>>
> >> This would imply changing the
> >> Documentation/devicetree/bindings/crypto/fsl-sec4.txt binding and
> >> dealing with all the consequences, which IIUC is probably not worth.
> >
> > I do not care the bindings doc that much, since I'm not the maintainer
> > of it. What are the consequences specifically, if we use a better node
> > name in dts than bindings example?
> >
> Users relying on finding the sec_mon node will obviously stop working.
> I don't see any in-kernel users, however there could be others I am not
> aware of and DT bindings should provide for backwards compatibility.
Okay, point taken. You can keep the node name as it is.
> I could deprecate "sec_mon" in the bindings and suggest "sec-mon"
> instead, while leaving all existing dts files as-is.
> The risk is breaking LS1012A users relying on "sec_mon".
For existing bindings, I do not care that much. But for new ones, I do
hope that we recommend to use hyphen, as that's more idiomatic at least
for Linux kernel.
> I see that ePAPR:
> -allows both for hyphen and underline in case of node names
> -allows only for hyphen (i.e. forbids underline) in case of alias nodes
>
> In the first case, I understand there's an (undocumented?) agreement to
> prefer hyphen over underline.
Both are valid, but hyphen is more idiomatic for Linux kernel.
> For the 2nd one, does this mean I should change alias names?
This is something I see difference between specification and DTC.
aliases {
alias-name = &label_name;
};
label_name: node-name {
...
};
The spec says that only hyphen is valid for alias name, but DTC works
happily with underscore too. From my experience with DTC playing, both
hyphen and underscore are valid for alias and node name. But for label
name, only underscore is valid. Using hyphen in label name will cause
DTC to report syntax error.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array
From: Peter Zijlstra @ 2017-03-24 14:09 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: H. Peter Anvin, Michael Davidson, Alexander Potapenko,
Michal Marek, Thomas Gleixner, Ingo Molnar, Herbert Xu,
David S. Miller, Shaohua Li, Matthias Kaehlcke, x86@kernel.org,
open list:KERNEL BUILD + fi..., LKML, linux-crypto, linux-raid
In-Reply-To: <CACT4Y+awYCAwoCkh8PQ-i2BdkxeuFp9meVXp=Yv6hGY8YjDnQg@mail.gmail.com>
On Fri, Mar 24, 2017 at 02:47:15PM +0100, Dmitry Vyukov wrote:
> > Seriously, you should have taken the hack the first time that this
> > needs to be fixed. Just because this is a fairly uncommon construct
> > in the kernel doesn't mean it is not in userspace.
>
> There is a reason why it is fairly uncommon in kernel.
So first off; its not entirely clear that the code as it exists it
correct. From a cursory reading of it and surrounding code, there is no
actual upper limit on the variable. If I were stupid enough to make a
raid with 64 devices I'd get a huge on-stack structure.
Since you're touching it; you should check these things.
And secondly, refactor the code to not look like dog vomit. You can do
more than the absolute minimal patch to make it compile, I'm sure.
^ permalink raw reply
* Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array
From: Peter Zijlstra @ 2017-03-24 14:10 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Borislav Petkov, Alexander Potapenko, Michael Davidson,
Michal Marek, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Herbert Xu, David S. Miller, Shaohua Li, Matthias Kaehlcke,
x86@kernel.org, open list:KERNEL BUILD + fi..., LKML,
linux-crypto, linux-raid, kbuild-all, Fengguang Wu
In-Reply-To: <CACT4Y+bRWePGuZB-HCGBhHuENHAM=uDDv3i81fwZjNUKhNY2UA@mail.gmail.com>
On Fri, Mar 24, 2017 at 02:50:24PM +0100, Dmitry Vyukov wrote:
> OK, I guess should not have referenced the llvm-linux page.
> So here are reasons on our side that I am ready to vouch:
>
> - clang make it possible to implement KMSAN (dynamic detection of
> uses of uninit memory)
How does GCC make this impossible?
> - better code coverage for fuzzing
How so? Why can't the same be achieved using GCC?
> - why simpler and faster development (e.g. we can port our user-space
> hardening technologies -- CFI and SafeStack)
That's just because you've already implemented this in clang, right? So
less work for you. Not because its impossible.
^ permalink raw reply
* Re: [PATCH V3 0/3] Support new function in new CCPs
From: Herbert Xu @ 2017-03-24 14:12 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20170315182014.29335.93268.stgit@taos>
On Wed, Mar 15, 2017 at 01:20:34PM -0500, Gary R Hook wrote:
> The following series implements new function in a version 5 coprocessor.
> New features are:
> - Support for SHA-2 384-bit and 512-bit hashing
> - Support for 3DES encryption
> - Support for AES GCM encryption
>
> Changes from V2:
> - Correct a comment in the GCM support code.
> - Ensure the patches apply to the current repo
All patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm
From: Herbert Xu @ 2017-03-24 14:12 UTC (permalink / raw)
To: Daniel Axtens; +Cc: linuxppc-dev, linux-crypto, anton, dja
In-Reply-To: <20170315123737.20234-1-dja@axtens.net>
Daniel Axtens <dja@axtens.net> wrote:
> The core nuts and bolts of the crc32c vpmsum algorithm will
> also work for a number of other CRC algorithms with different
> polynomials. Factor out the function into a new asm file.
>
> To handle multiple users of the function, a user simply
> provides constants, defines the name of their CRC function,
> and then #includes the core algorithm file.
>
> Cc: Anton Blanchard <anton@samba.org>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
All patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] md5: remove from lib and only live in crypto
From: Herbert Xu @ 2017-03-24 14:13 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-crypto, linux-kernel
In-Reply-To: <20170316141857.20910-1-Jason@zx2c4.com>
On Thu, Mar 16, 2017 at 03:18:57PM +0100, Jason A. Donenfeld wrote:
> The md5_transform function is no longer used any where in the tree,
> except for the crypto api's actual implementation of md5, so we can drop
> the function from lib and put it as a static function of the crypto
> file, where it belongs. There should be no new users of md5_transform,
> anyway, since there are more modern ways of doing what it once achieved.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/7] crypto: caam - add Queue Interface (QI) support
From: Herbert Xu @ 2017-03-24 14:13 UTC (permalink / raw)
To: Horia Geantă
Cc: Alexandru Porosanu, Roy Pledge, Claudiu Manoil, Cristian Stoica,
Scott Wood, Dan Douglass, linux-crypto, Vakul Garg,
David S. Miller, linux-arm-kernel
In-Reply-To: <20170317100602.2837-1-horia.geanta@nxp.com>
On Fri, Mar 17, 2017 at 12:05:55PM +0200, Horia Geantă wrote:
> RFC -> v1:
> -rebased on latest cryptodev-2.6 tree
> open-code tsk_cpus_allowed() - sync with commit
> 0c98d344fe5c "sched/core: Remove the tsk_cpus_allowed() wrapper"
> -addressed Scott's feedback - removed most of the accessors
> added in soc/qman (patch 4) and instead open-coded them in caam/qi
>
>
> The patchset adds support for CAAM Queue Interface (QI), the additional
> interface (besides job ring) available for submitting jobs to the engine
> on platforms having DPAA (Datapath Acceleration Architecture).
>
> Patches 1-4 are QMan dependencies.
> During RFC stage, we agreed to go with them through the crypto tree:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg24105.html
>
> Patch 5 adds a missing double inclusion guard in desc_constr.h.
>
> Patch 6 adds the caam/qi job submission backend.
>
> Patch 7 adds algorithms (ablkcipher and authenc) that run on top
> of caam/qi. For now, their priority is set lower than caam/jr.
All patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] crypto, x86: aesni - fix token pasting for clang
From: Herbert Xu @ 2017-03-24 14:12 UTC (permalink / raw)
To: Michael Davidson
Cc: David S . Miller, Thomas Gleixner, Ingo Molnar, H . Peter Anvin,
Alexander Potapenko, Dmitry Vyukov, x86, linux-crypto,
linux-kernel
In-Reply-To: <20170315223600.131367-1-md@google.com>
On Wed, Mar 15, 2017 at 03:36:00PM -0700, Michael Davidson wrote:
> aes_ctrby8_avx-x86_64.S uses the C preprocessor for token pasting
> of character sequences that are not valid preprocessor tokens.
> While this is allowed when preprocessing assembler files it exposes
> an incompatibilty between the clang and gcc preprocessors where
> clang does not strip leading white space from macro parameters,
> leading to the CONCAT(%xmm, i) macro expansion on line 96 resulting
> in a token with a space character embedded in it.
>
> While this could be resolved by deleting the offending space character,
> the assembler is perfectly capable of doing the token pasting correctly
> for itself so we can just get rid of the preprocessor macros.
>
> Signed-off-by: Michael Davidson <md@google.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] crypto: s5p-sss - Fix and minor improvements
From: Herbert Xu @ 2017-03-24 14:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David S. Miller, linux-crypto, linux-kernel, Vladimir Zapolskiy,
Nathan Royce
In-Reply-To: <20170317144922.27379-1-krzk@kernel.org>
On Fri, Mar 17, 2017 at 04:49:18PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> I still did not fix the NULL pointer dereference reported by
> Nathan Royce [1], but I got some other improvements.
>
> Testing done on Odroid U3 (Exynos4412) with tcrypt and cryptsetup.
>
> Best regards,
> Krzysztof
Patches 1-3 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: zip - add a cast for printing atomic64_t values
From: Herbert Xu @ 2017-03-24 14:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Mahipal Challa, Jan Glauber, linux-crypto,
linux-kernel
In-Reply-To: <20170320123955.4061033-1-arnd@arndb.de>
On Mon, Mar 20, 2017 at 01:39:16PM +0100, Arnd Bergmann wrote:
> 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>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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