xts(ecb(aes-asm))
Hi Herbert, while testing the current cryptodev-2.6 tree, I noticed that instead of the driver name of xts(aes-asm) (which used to be there), I now see xts(ecb(aes- asm)). Is that intentional? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: simd ciphers
Am Donnerstag, 8. Dezember 2016, 19:32:03 CET schrieb Stephan Müller: Hi Herbert, > Hi Herbert, > > with the addition of the simd cipher change I seem to be unable to use the > AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and > CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the AES-NI (with "always worked" I meant the CONFIG_CRYPTO_AES_NI_INTEL=y option of course, that always ensured AES-NI to be present and usable) > implementation. But now, I do not see the AES-NI implementations any more > in / proc/crypto. > > Ciao > Stephan > -- > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
simd ciphers
Hi Herbert, with the addition of the simd cipher change I seem to be unable to use the AESNI ciphers. My .config contains CONFIG_CRYPTO_SIMD=y and CONFIG_CRYPTO_AES_NI_INTEL=y. Those options always worked to load the AES-NI implementation. But now, I do not see the AES-NI implementations any more in / proc/crypto. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> >> would remain possible to check such drivers with sparse without enabling
> >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> >> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> >
> > The right thing is probably just to fix these, isn't it?
> > Until then, why not just ignore the warnings?
>
> Neither option is realistic. With endian-checking enabled the qla2xxx
> driver triggers so many warnings that it becomes a real challenge to
> filter the non-endian warnings out manually:
>
> $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
> $f | &grep -c ': warning:'; done
> 4
> 752
You can always revert this patch in your tree, or whatever. It does not
look like this will get fixed otherwise.
> If you think it would be easy to fix the endian warnings triggered by
> the qla2xxx driver, you are welcome to try to fix these.
>
> Bart.
Yea, this hardware was designed by someone who thought mixing
LE and BE all over the place is a good idea.
But who said it should be easy?
Maybe this change will be enough to motivate the maintainers.
Here's a minor buglet for you as a motivator:
if (ct_rsp->header.response !=
cpu_to_be16(CT_ACCEPT_RESPONSE)) {
ql_dbg(ql_dbg_disc + ql_dbg_buffer, vha, 0x2077,
"%s failed rejected request on port_id:
%02x%02x%02x Compeltion status 0x%x, response 0x%x\n",
routine, vha->d_id.b.domain,
vha->d_id.b.area, vha->d_id.b.al_pa,
comp_status, ct_rsp->header.response);
response is BE and isn't printed correctly.
another:
eiter->a.max_frame_size = cpu_to_be32(eiter->a.max_frame_size);
size += 4 + 4;
ql_dbg(ql_dbg_disc, vha, 0x20bc,
"Max_Frame_Size = %x.\n", eiter->a.max_frame_size);
printed too late, it's be by that time.
Here's another suspicious line
ctio24->u.status1.flags = (atio->u.isp24.attr << 9) |
cpu_to_le16(CTIO7_FLAGS_STATUS_MODE_1 |
CTIO7_FLAGS_TERMINATE);
shifting attr by 9 bits gives different results on BE and LE,
mixing it with le16 looks rather strange.
Another:
ha->flags.dport_enabled =
(mid_init_cb->init_cb.firmware_options_1 & BIT_7) != 0;
BIT_7 is native endian, firmware_options_1 is LE I think.
Look at qla27xx_find_valid_image as well.
if (pri_image_status.signature != QLA27XX_IMG_STATUS_SIGN)
qla27xx_image_status seems to be data coming from flash, but is
somehow native-endian? Maybe ...
lun = a->u.isp24.fcp_cmnd.lun;
I think lun here is in hardware format (le?), code treats it
as native.
Not to speak about interface abuse all over the place.
How about this:
uint32_t *
qla24xx_read_flash_data(scsi_qla_host_t *vha, uint32_t *dwptr, uint32_t
faddr,
uint32_t dwords)
{
uint32_t i;
struct qla_hw_data *ha = vha->hw;
/* Dword reads to flash. */
for (i = 0; i < dwords; i++, faddr++)
dwptr[i] = cpu_to_le32(qla24xx_read_flash_dword(ha,
flash_data_addr(ha, faddr)));
return dwptr;
}
OK so we convert to LE ...
qla24xx_read_flash_data(vha, dcode, faddr, 4);
risc_addr = be32_to_cpu(dcode[2]);
*srisc_addr = *srisc_addr == 0 ? risc_addr : *srisc_addr;
risc_size = be32_to_cpu(dcode[3]);
then happily assume it's BE.
And again, coming from flash, it's unlikely to actually be in the native
endian-ness as callers seem to assume. I'm guessing it's all BE.
I poked at it a bit and was able to cut down # of warnings
from 1700 to 1400 in an hour. Someone familiar with the code
should look at it.
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] crypto: arm64/chacha20 - implement NEON version based on SSE3 code
This is a straight port to arm64/NEON of the x86 SSE3 implementation
of the ChaCha20 stream cipher.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 6 +
arch/arm64/crypto/Makefile | 3 +
arch/arm64/crypto/chacha20-neon-core.S | 480
arch/arm64/crypto/chacha20-neon-glue.c | 131 ++
4 files changed, 620 insertions(+)
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 450a85df041a..0bf0f531f539 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -72,4 +72,10 @@ config CRYPTO_CRC32_ARM64
depends on ARM64
select CRYPTO_HASH
+config CRYPTO_CHACHA20_NEON
+ tristate "NEON accelerated ChaCha20 symmetric cipher"
+ depends on KERNEL_MODE_NEON
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_CHACHA20
+
endif
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index aad7b744..9d2826c5fccf 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -41,6 +41,9 @@ sha256-arm64-y := sha256-glue.o sha256-core.o
obj-$(CONFIG_CRYPTO_SHA512_ARM64) += sha512-arm64.o
sha512-arm64-y := sha512-glue.o sha512-core.o
+obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
+chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
+
AFLAGS_aes-ce.o:= -DINTERLEAVE=4
AFLAGS_aes-neon.o := -DINTERLEAVE=4
diff --git a/arch/arm64/crypto/chacha20-neon-core.S
b/arch/arm64/crypto/chacha20-neon-core.S
new file mode 100644
index ..e2cd65580807
--- /dev/null
+++ b/arch/arm64/crypto/chacha20-neon-core.S
@@ -0,0 +1,480 @@
+/*
+ * ChaCha20 256-bit cipher algorithm, RFC7539, arm64 NEON functions
+ *
+ * Copyright (C) 2016 Linaro, Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Based on:
+ * ChaCha20 256-bit cipher algorithm, RFC7539, x64 SSSE3 functions
+ *
+ * Copyright (C) 2015 Martin Willi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+
+ .text
+ .align 6
+
+ENTRY(chacha20_block_xor_neon)
+ // x0: Input state matrix, s
+ // x1: 1 data block output, o
+ // x2: 1 data block input, i
+
+ //
+ // This function encrypts one ChaCha20 block by loading the state matrix
+ // in four NEON registers. It performs matrix operation on four words in
+ // parallel, but requires shuffling to rearrange the words after each
+ // round.
+ //
+
+ // x0..3 = s0..3
+ ld1 {v0.4s-v3.4s}, [x0]
+ ld1 {v8.4s-v11.4s}, [x0]
+
+ mov x3, #10
+
+.Ldoubleround:
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
+ add v0.4s, v0.4s, v1.4s
+ eor v3.16b, v3.16b, v0.16b
+ rev32 v3.8h, v3.8h
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
+ add v2.4s, v2.4s, v3.4s
+ eor v4.16b, v1.16b, v2.16b
+ shl v1.4s, v4.4s, #12
+ sri v1.4s, v4.4s, #20
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 8)
+ add v0.4s, v0.4s, v1.4s
+ eor v4.16b, v3.16b, v0.16b
+ shl v3.4s, v4.4s, #8
+ sri v3.4s, v4.4s, #24
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 7)
+ add v2.4s, v2.4s, v3.4s
+ eor v4.16b, v1.16b, v2.16b
+ shl v1.4s, v4.4s, #7
+ sri v1.4s, v4.4s, #25
+
+ // x1 = shuffle32(x1, MASK(0, 3, 2, 1))
+ ext v1.16b, v1.16b, v1.16b, #4
+ // x2 = shuffle32(x2, MASK(1, 0, 3, 2))
+ ext v2.16b, v2.16b, v2.16b, #8
+ // x3 = shuffle32(x3, MASK(2, 1, 0, 3))
+ ext v3.16b, v3.16b, v3.16b, #12
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
+ add v0.4s, v0.4s, v1.4s
+ eor v3.16b, v3.16b, v0.16b
+ rev32 v3.8h, v3.8h
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
+ add v2.4s, v2.4s, v3.4s
+ eor v4.16b, v1.16b, v2.16b
+ shl v1.4s, v4.4s, #12
+ sri v1.4s, v4.4s, #20
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 8)
+ add v0.4s, v0.4s, v1.4s
+ eor v4.16b, v3.16b, v0.16b
+ shl v3.4s, v4.4s, #8
+ sri v3.4s, v4.4s, #24
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 7)
+ add v2.4s, v2.4s, v3.4s
+ eor v4.16b, v1.16b, v2.16b
+ shl v1.4s, v4.4s, #7
+ sri v1.4s, v4.4s, #25
+
+ // x1 = shuffle32(x1,
[PATCH 2/2] crypto: arm/chacha20 - implement NEON version based on SSE3 code
This is a straight port to ARM/NEON of the x86 SSE3 implementation
of the ChaCha20 stream cipher.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig | 6 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/chacha20-neon-core.S | 524
arch/arm/crypto/chacha20-neon-glue.c | 136 +
4 files changed, 668 insertions(+)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 13f1b4c289d4..2f3339f015d3 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -130,4 +130,10 @@ config CRYPTO_CRC32_ARM_CE
depends on KERNEL_MODE_NEON && CRC32
select CRYPTO_HASH
+config CRYPTO_CHACHA20_NEON
+ tristate "NEON accelerated ChaCha20 symmetric cipher"
+ depends on KERNEL_MODE_NEON
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_CHACHA20
+
endif
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b578a1820ab1..8d74e55eacd4 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
obj-$(CONFIG_CRYPTO_SHA256_ARM) += sha256-arm.o
obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
+obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
@@ -40,6 +41,7 @@ aes-arm-ce-y := aes-ce-core.o aes-ce-glue.o
ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
+chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o
quiet_cmd_perl = PERL$@
cmd_perl = $(PERL) $(<) > $(@)
diff --git a/arch/arm/crypto/chacha20-neon-core.S
b/arch/arm/crypto/chacha20-neon-core.S
new file mode 100644
index ..9f315041f521
--- /dev/null
+++ b/arch/arm/crypto/chacha20-neon-core.S
@@ -0,0 +1,524 @@
+/*
+ * ChaCha20 256-bit cipher algorithm, RFC7539, ARM NEON functions
+ *
+ * Copyright (C) 2016 Linaro, Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Based on:
+ * ChaCha20 256-bit cipher algorithm, RFC7539, x64 SNEON3 functions
+ *
+ * Copyright (C) 2015 Martin Willi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+
+ .text
+ .fpuneon
+ .align 5
+
+ENTRY(chacha20_block_xor_neon)
+ // r0: Input state matrix, s
+ // r1: 1 data block output, o
+ // r2: 1 data block input, i
+
+ //
+ // This function encrypts one ChaCha20 block by loading the state matrix
+ // in four NEON registers. It performs matrix operation on four words in
+ // parallel, but requireds shuffling to rearrange the words after each
+ // round.
+ //
+
+ // x0..3 = s0..3
+ add ip, r0, #0x20
+ vld1.32 {q0-q1}, [r0]
+ vld1.32 {q2-q3}, [ip]
+
+ vmovq8, q0
+ vmovq9, q1
+ vmovq10, q2
+ vmovq11, q3
+
+ mov r3, #10
+
+.Ldoubleround:
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
+ vadd.i32q0, q0, q1
+ veorq4, q3, q0
+ vshl.u32q3, q4, #16
+ vsri.u32q3, q4, #16
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
+ vadd.i32q2, q2, q3
+ veorq4, q1, q2
+ vshl.u32q1, q4, #12
+ vsri.u32q1, q4, #20
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 8)
+ vadd.i32q0, q0, q1
+ veorq4, q3, q0
+ vshl.u32q3, q4, #8
+ vsri.u32q3, q4, #24
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 7)
+ vadd.i32q2, q2, q3
+ veorq4, q1, q2
+ vshl.u32q1, q4, #7
+ vsri.u32q1, q4, #25
+
+ // x1 = shuffle32(x1, MASK(0, 3, 2, 1))
+ vext.8 q1, q1, q1, #4
+ // x2 = shuffle32(x2, MASK(1, 0, 3, 2))
+ vext.8 q2, q2, q2, #8
+ // x3 = shuffle32(x3, MASK(2, 1, 0, 3))
+ vext.8 q3, q3, q3, #12
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 16)
+ vadd.i32q0, q0, q1
+ veorq4, q3, q0
+ vshl.u32q3, q4, #16
+ vsri.u32q3, q4, #16
+
+ // x2 += x3, x1 = rotl32(x1 ^ x2, 12)
+ vadd.i32q2, q2, q3
+ veorq4, q1, q2
+ vshl.u32q1, q4, #12
+ vsri.u32q1, q4, #20
+
+ // x0 += x1, x3 = rotl32(x3 ^ x0, 8)
+ vadd.i32q0, q0, q1
+
[PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
Another port of existing x86 SSE code to NEON, again both for arm64 and ARM. ChaCha20 is a stream cipher described in RFC 7539, and is intended to be an efficient software implementable 'standby cipher', in case AES cannot be used. This NEON implementation is almost 2x as fast as the generic C code (measured on Cortex-A57 using the arm64 version) I'm aware that blkciphers are deprecated in favor of skciphers, but this code (like the x86 version) uses the init and setkey routines of the generic version, so it is probably better to port all implementations at once. Ard Biesheuvel (2): crypto: arm64/chacha20 - implement NEON version based on SSE3 code crypto: arm/chacha20 - implement NEON version based on SSE3 code arch/arm/crypto/Kconfig| 6 + arch/arm/crypto/Makefile | 2 + arch/arm/crypto/chacha20-neon-core.S | 524 arch/arm/crypto/chacha20-neon-glue.c | 136 + arch/arm64/crypto/Kconfig | 6 + arch/arm64/crypto/Makefile | 3 + arch/arm64/crypto/chacha20-neon-core.S | 480 ++ arch/arm64/crypto/chacha20-neon-glue.c | 131 + 8 files changed, 1288 insertions(+) create mode 100644 arch/arm/crypto/chacha20-neon-core.S create mode 100644 arch/arm/crypto/chacha20-neon-glue.c create mode 100644 arch/arm64/crypto/chacha20-neon-core.S create mode 100644 arch/arm64/crypto/chacha20-neon-glue.c -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: testmgr - fix overlap in chunked tests again
On Thu, Dec 08, 2016 at 08:23:52AM +, Ard Biesheuvel wrote:
> Commit 7e4c7f17cde2 ("crypto: testmgr - avoid overlap in chunked tests")
> attempted to address a problem in the crypto testmgr code where chunked
> test cases are copied to memory in a way that results in overlap.
>
> However, the fix recreated the exact same issue for other chunked tests,
> by putting IDX3 within 492 bytes of IDX1, which causes overlap if the
> first chunk exceeds 492 bytes, which is the case for at least one of
> the xts(aes) test cases.
>
> So increase IDX3 by another 1000 bytes.
>
> Signed-off-by: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: algif_aead - fix uninitialized variable warning
On Thu, Dec 08, 2016 at 07:09:44AM +0100, Stephan Müller wrote: > In case the user provided insufficient data, the code may return > prematurely without any operation. In this case, the processed > data indicated with outlen is zero. > > Reported-by: Stephen Rothwell > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, 8 Dec 2016 04:29:39 +0200 "Michael S. Tsirkin" wrote: > By now, linux is mostly endian-clean. Enabling endian-ness > checks for everyone produces about 200 new sparse warnings for me - > less than 10% over the 2000 sparse warnings already there. Out of curiousity: Where do most of those warnings show up? > > Not a big deal, OTOH enabling this helps people notice > they are introducing new bugs. > > So let's just drop __CHECK_ENDIAN__. Follow-up patches > can drop distinction between __bitwise and __bitwise__. > > Cc: Linus Torvalds > Suggested-by: Christoph Hellwig > Signed-off-by: Michael S. Tsirkin > --- > > Linus, could you ack this for upstream? If yes I'll > merge through my tree as a replacement for enabling > this just for virtio. > > include/uapi/linux/types.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h > index acf0979..41e5914 100644 > --- a/include/uapi/linux/types.h > +++ b/include/uapi/linux/types.h > @@ -23,11 +23,7 @@ > #else > #define __bitwise__ > #endif > -#ifdef __CHECK_ENDIAN__ > #define __bitwise __bitwise__ > -#else > -#define __bitwise > -#endif > > typedef __u16 __bitwise __le16; > typedef __u16 __bitwise __be16; FWIW, I like this better than just enabling it for the virtio code. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
On Thu, Dec 08, 2016 at 06:38:11AM +, Bart Van Assche wrote: > On 12/07/16 21:54, Michael S. Tsirkin wrote: > > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: > >> Additionally, there are notable exceptions to the rule that most drivers > >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it > >> would remain possible to check such drivers with sparse without enabling > >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ > >> into e.g. #ifndef __DONT_CHECK_ENDIAN__? > > > > The right thing is probably just to fix these, isn't it? > > Until then, why not just ignore the warnings? > > Neither option is realistic. With endian-checking enabled the qla2xxx > driver triggers so many warnings that it becomes a real challenge to > filter the non-endian warnings out manually: > > $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\ > $f | &grep -c ': warning:'; done > 4 > 752 > > If you think it would be easy to fix the endian warnings triggered by > the qla2xxx driver, you are welcome to try to fix these. Please don't let one crappy, obviously broken, driver prevent this good change from happening which will help ensure that the rest of the kernel (i.e. 99% of it) can be easily tested and fixed for endian issues. Sounds like you should just fix the driver up if it has so many problems, and it annoys you so much that you have to filter out some warnings to see the others :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
>> The hwrng interface was always meant to be an interface for real >> hardware random number generators. People rely on that so we >> should not provide bogus entropy sources through this interface. >> > > Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ? > Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ? > With that it will be much easier to convert in-tree PRNG that you want to > remove. I do have driver for a PRNG that I was planning to post in sometime. Upon seeing this thread I think the code has to be changed. I completely agree with Corentin, adding /dev/prng or /dev/hw_prng will make it easier to move existing code. It can be made explicit that using new device will provide only pseudo random number. Thanks, PrasannaKumar -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto regression?
On Thu, Dec 08, 2016 at 11:41:55AM +0100, Cyrille Pitchen wrote: > Hi Herbert, > > Let me report a potential regression I've noticed this morning when testing > linux-next. > > I've set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n when compiling both kernel > images. > > > On 4.9.0-rc2-next-20161028, /proc/crypto displays: > driver : atmel-xts-aes Thanks for the report. This should be fixed once I push this out https://patchwork.kernel.org/patch/9465979/ Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto regression?
Hi Herbert, Let me report a potential regression I've noticed this morning when testing linux-next. I've set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n when compiling both kernel images. On 4.9.0-rc2-next-20161028, /proc/crypto displays: driver : atmel-xts-aes module : kernel priority : 300 refcnt : 1 selftest : passed internal : no type : ablkcipher async: yes blocksize: 16 min keysize : 32 max keysize : 64 ivsize : 16 geniv: and no output from the test manager in the boot log. Whereas on 4.9.0-rc8-next-20161208, we get: driver : atmel-xts-aes module : kernel priority : 300 refcnt : 1 selftest : unknown internal : no type : ablkcipher async: yes blocksize: 16 min keysize : 32 max keysize : 64 ivsize : 16 geniv: Also I see the following traces during the boot: alg: skcipher: Chunk test 1 failed on encryption at page 0 for atmel-xts-aes : 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b 0010: ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b 0020: 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44 0030: 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd 0040: 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70 0050: aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0 0060: c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75 0070: 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca 0080: 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d 0090: e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0 00a0: b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34 00b0: f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f 00c0: 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a 00d0: 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec 00e0: 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6 00f0: dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a 0100: 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f 0110: bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1 0120: 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84 0130: f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae 0140: 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b 0150: 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29 0160: a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52 0170: 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac 0180: 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0 0190: dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f 01a0: 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93 01b0: c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85 01c0: 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a 01d0: b5 32 fd 6f 01 77 3d 53 f7 a4 70 83 46 bc 5f c4 01e0: f3 6f fd a9 fc ea 70 b9 c6 e6 93 e1 The output is a little bit long for test 1, isn't it? When I look at aes_xts_enc_tv_template[] from crypto/testmgr.h I see .rlen = 32 . I didn't bisect to find out exactly since when the regression is there. I wanted to warn you quickly since we are close to the merge window. Also if you have already been notified about this issue, please, sorry for the noise! Best regards, Cyrille -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote: > On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote: > > > > So I must expose it as a crypto_rng ? > > If it is to be exposed at all then algif_rng would be the best > place. > I have badly said my question. So I need to use the HW PRNG in a crypto_rng "provider" that could be thereafter used from user space via algif_rng. right ? > > Could you explain why PRNG must not be used as hw_random ? > > The hwrng interface was always meant to be an interface for real > hardware random number generators. People rely on that so we > should not provide bogus entropy sources through this interface. > Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ? Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ? With that it will be much easier to convert in-tree PRNG that you want to remove. Regards Corentin Labbe -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation
Hello,
On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote:
>
> On 05/12/16 08:01, Ryder Lee wrote:
> > Add DT bindings documentation for the crypto driver
> >
> > Signed-off-by: Ryder Lee
> > ---
> > .../devicetree/bindings/crypto/mediatek-crypto.txt | 32
> > ++
> > 1 file changed, 32 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> > b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> > new file mode 100644
> > index 000..8b1db08
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> > @@ -0,0 +1,32 @@
> > +MediaTek cryptographic accelerators
> > +
> > +Required properties:
> > +- compatible: Should be "mediatek,mt7623-crypto"
>
> Do you know how big the difference is between the crypto engine for
> mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
> Do this SoCs have a crypot engine? If so and they are quite similar, we
> might think of adding a mtk-crypto binding and add soc specific bindings.
This engine is just available in mt7623/mt2701/mt8521p series SoCs and
they have no difference.
But there are still other crypto IPs in MTK, i think maybe we could use
"mediatek,{IP name}-crypto” to distinguish them ?
> Regards,
> Matthias
>
> > +- reg: Address and length of the register set for the device
> > +- interrupts: Should contain the five crypto engines interrupts in numeric
> > + order. These are global system and four descriptor rings.
> > +- clocks: the clock used by the core
> > +- clock-names: the names of the clock listed in the clocks property. These
> > are
> > + "ethif", "cryp"
> > +- power-domains: Must contain a reference to the PM domain.
> > +
> > +
> > +Optional properties:
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > + that services interrupts for this device
> > +
> > +
> > +Example:
> > + crypto: crypto@1b24 {
> > + compatible = "mediatek,mt7623-crypto";
> > + reg = <0 0x1b24 0 0x2>;
> > + interrupts = ,
> > +,
> > +,
> > +,
> > +;
> > + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> > +<ðsys CLK_ETHSYS_CRYPTO>;
> > + clock-names = "ethif","cryp";
> > + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> > + };
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote: > > So I must expose it as a crypto_rng ? If it is to be exposed at all then algif_rng would be the best place. > Could you explain why PRNG must not be used as hw_random ? The hwrng interface was always meant to be an interface for real hardware random number generators. People rely on that so we should not provide bogus entropy sources through this interface. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/2] Add crypto driver support for some MediaTek chips
Hello,
On Mon, 2016-12-05 at 09:52 +0100, Corentin Labbe wrote:
> Hello
>
> I have two minor comment.
>
> On Mon, Dec 05, 2016 at 03:01:23PM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
>
> There is a typo for algorithms.
>
> [...]
> > +/**
> > + * struct mtk_desc - DMA descriptor
> > + * @hdr: the descriptor control header
> > + * @buf: DMA address of input buffer segment
> > + * @ct:DMA address of command token that control operation flow
> > + * @ct_hdr:the command token control header
> > + * @tag: the user-defined field
> > + * @tfm: DMA address of transform state
> > + * @bound: align descriptors offset boundary
> > + *
> > + * Structure passed to the crypto engine to describe where source
> > + * data needs to be fetched and how it needs to be processed.
> > + */
> > +struct mtk_desc {
> > + u32 hdr;
> > + u32 buf;
> > + u32 ct;
> > + u32 ct_hdr;
> > + u32 tag;
> > + u32 tfm;
> > + u32 bound[2];
> > +};
>
> Do you have tested this descriptor with BE/LE kernel ?
I did not test it with BE kernel, because both CPU and accelerator in
our SoC just run on LE system.
Thanks for reminding me, i will use byteorder conversion macros and type
identifiers.
> Regards
> Corentin Labbe
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: testmgr - fix overlap in chunked tests again
Commit 7e4c7f17cde2 ("crypto: testmgr - avoid overlap in chunked tests")
attempted to address a problem in the crypto testmgr code where chunked
test cases are copied to memory in a way that results in overlap.
However, the fix recreated the exact same issue for other chunked tests,
by putting IDX3 within 492 bytes of IDX1, which causes overlap if the
first chunk exceeds 492 bytes, which is the case for at least one of
the xts(aes) test cases.
So increase IDX3 by another 1000 bytes.
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 670893bcf361..157a415097f2 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -63,7 +63,7 @@ int alg_test(const char *driver, const char *alg, u32 type,
u32 mask)
*/
#define IDX1 32
#define IDX2 32400
-#define IDX3 511
+#define IDX3 1511
#define IDX4 8193
#define IDX5 2
#define IDX6 17101
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
On 12/07/16 21:54, Michael S. Tsirkin wrote: > On Thu, Dec 08, 2016 at 05:21:47AM +, Bart Van Assche wrote: >> Additionally, there are notable exceptions to the rule that most drivers >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it >> would remain possible to check such drivers with sparse without enabling >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__ >> into e.g. #ifndef __DONT_CHECK_ENDIAN__? > > The right thing is probably just to fix these, isn't it? > Until then, why not just ignore the warnings? Neither option is realistic. With endian-checking enabled the qla2xxx driver triggers so many warnings that it becomes a real challenge to filter the non-endian warnings out manually: $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\ $f | &grep -c ': warning:'; done 4 752 If you think it would be easy to fix the endian warnings triggered by the qla2xxx driver, you are welcome to try to fix these. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
