Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling
On Mon, 16 Mar 2015 12:02:51 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
Only potential problem is getting the crypto API to set the GFP_DMA
flag in the allocation request, but presumably a
CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
Seems there are quite a few places that do not use the
{aead,ablkcipher_ahash}_request_alloc() API to allocate crypto requests.
Among them, IPsec and dm-crypt.
I've looked at the code and I don't think it can be converted to use
crypto API.
why not?
This means that the CRYPTO_TFM_REQ_DMA would be visible to all of these
places. Some of the maintainers do not agree, as you've seen.
would modifying the crypto API to either have a different
*_request_alloc() API, and/or adding calls to negotiate the GFP mask
between crypto users and drivers, e.g., get/set_gfp_mask, work?
An alternative would be for talitos to use the page allocator to get 1 /
2 pages at probe time (4 channels x 32 entries/channel x 64B/descriptor
= 8 kB), dma_map_page the area and manage it internally for talitos_desc
hw descriptors.
What do you think?
There's a comment in esp_alloc_tmp(): Use spare space in skb for
this where possible, which is ideally where we'd want to be (esp.
because that memory could already be DMA-able). Your above
suggestion would be in the opposite direction of that.
Kim
--
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 V5 0/2] crypto: Add Imagination Technologies hw hash accelerator
On Thu, Mar 12, 2015 at 11:17:25PM +, James Hartley wrote: This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA244 SHA256 and MD5 hashes. Tested on silicon, using testmgr. All applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au 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 v2 5/5] crypto: talitos: Add software backlog queue handling
On 3/4/2015 2:23 AM, Kim Phillips wrote:
Only potential problem is getting the crypto API to set the GFP_DMA
flag in the allocation request, but presumably a
CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
Seems there are quite a few places that do not use the
{aead,ablkcipher_ahash}_request_alloc() API to allocate crypto requests.
Among them, IPsec and dm-crypt.
I've looked at the code and I don't think it can be converted to use
crypto API.
This means that the CRYPTO_TFM_REQ_DMA would be visible to all of these
places. Some of the maintainers do not agree, as you've seen.
An alternative would be for talitos to use the page allocator to get 1 /
2 pages at probe time (4 channels x 32 entries/channel x 64B/descriptor
= 8 kB), dma_map_page the area and manage it internally for talitos_desc
hw descriptors.
What do you think?
Thanks,
Horia
--
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 0/6] Introduce devm_hwrng_register and convert a few dirvers
On Thu, Mar 12, 2015 at 02:00:01PM -0700, Dmitry Torokhov wrote: A few drivers can benefit from devm-style interface for hwrng since it is quite often the last thing that isn't automatically managed. Using devm_hwrng_register() in such drivers allows get rid of manual error unwinding and drivers' remove() methods. I tested changes to iproc-rng200, the rest are compiled only. All applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au 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 12/12] crypto/sha-mb/sha1_mb.c : Syntax error
On Mon, 2015-03-16 at 21:50 +1100, Herbert Xu wrote: On Fri, Mar 13, 2015 at 11:38:21PM +0200, Ameen Ali wrote: fixing a syntax-error . Signed-off-by : Ameen Ali ameenali...@gmail.com Applied. The commit summary and the commit explanation are a bit misleading. This is not a syntax error: it actually compiles just fine with GCC 4.8. (I looked into that wondering whether this was stable material.) It's telling that the commit explanation doesn't contain a copy of the error message, which would have been very helpful if this really was a syntax error. The old code apparently works because the preprocessor converts time_before() into time_after(). And the code generated for time_after() will in its turn be wrapped in parentheses. That is, this generates valid syntax by, well, accident. So this could as well be labeled a style fix. A fix for a rather serious style defect, but still. Paul Bolle -- 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 4/4] crypto: talitos - add software backlog queue handling
On Sat, Mar 14, 2015 at 1:16 PM, Horia Geantă
horia.gea...@freescale.com wrote:
On 3/13/2015 8:37 PM, Tom Lendacky wrote:
+
+/* Try to backlog request (if allowed) */
+return crypto_enqueue_request(priv-chan[ch].queue, areq);
I'd remembered something about how hardware drivers should use their
own list element for queuing, searched back and found this:
http://marc.info/?l=linux-crypto-vgerm=137609769605139w=2
The crypto_async_request list field is used only for queuing using the
crypto API functions - crypto_{enqueue,dequeue}_request.
I am not sure I understand what is the problem.
Are crypto_{enqueue,dequeue}_request part of *internal* crypto API?
I don't believe that the enqueue/dequeue functions are internal API.
I based my code on the usage of other hardware offload drivers. Their
use is somewhat different because most of the other hardware can only
handle a single request at a time.
mh
--
Martin Hicks P.Eng. | m...@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
--
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] arm: crypto: Add NEON optimized SHA-256
Add Andy Polyakov's NEON optimized SHA-256 implementation.
On Nexus 6, this implementation is ~2x faster than sha256-generic.
Signed-off-by: Sami Tolvanen samitolva...@google.com
---
arch/arm/crypto/Makefile|2
arch/arm/crypto/sha256-armv7-neon.S | 819
arch/arm/crypto/sha256_neon_glue.c | 201
crypto/Kconfig | 12
4 files changed, 1034 insertions(+)
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b48fa34..316dba2 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -6,12 +6,14 @@ obj-$(CONFIG_CRYPTO_AES_ARM) += aes-arm.o
obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
+obj-$(CONFIG_CRYPTO_SHA256_ARM_NEON) += sha256-arm-neon.o
obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
aes-arm-y := aes-armv4.o aes_glue.o
aes-arm-bs-y := aesbs-core.o aesbs-glue.o
sha1-arm-y := sha1-armv4-large.o sha1_glue.o
sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
+sha256-arm-neon-y := sha256-armv7-neon.o sha256_neon_glue.o
sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
quiet_cmd_perl = PERL$@
diff --git a/arch/arm/crypto/sha256-armv7-neon.S
b/arch/arm/crypto/sha256-armv7-neon.S
new file mode 100644
index 000..5ce04c2
--- /dev/null
+++ b/arch/arm/crypto/sha256-armv7-neon.S
@@ -0,0 +1,819 @@
+@ sha256-armv7-neon.S - ARM/NEON assembly implementation of SHA-256 transform
+@
+@
+@ Written by Andy Polyakov ap...@openssl.org for the OpenSSL
+@ project. The module is, however, dual licensed under OpenSSL and
+@ CRYPTOGAMS licenses depending on where you obtain it. For further
+@ details see http://www.openssl.org/~appro/cryptogams/.
+@
+
+#include linux/linkage.h
+
+.text
+.code 32
+.fpu neon
+
+.type K256,%object
+.align 5
+K256:
+.word 0x428a2f98,0x71374491,0xb5c0fbcf,0xe9b5dba5
+.word 0x3956c25b,0x59f111f1,0x923f82a4,0xab1c5ed5
+.word 0xd807aa98,0x12835b01,0x243185be,0x550c7dc3
+.word 0x72be5d74,0x80deb1fe,0x9bdc06a7,0xc19bf174
+.word 0xe49b69c1,0xefbe4786,0x0fc19dc6,0x240ca1cc
+.word 0x2de92c6f,0x4a7484aa,0x5cb0a9dc,0x76f988da
+.word 0x983e5152,0xa831c66d,0xb00327c8,0xbf597fc7
+.word 0xc6e00bf3,0xd5a79147,0x06ca6351,0x14292967
+.word 0x27b70a85,0x2e1b2138,0x4d2c6dfc,0x53380d13
+.word 0x650a7354,0x766a0abb,0x81c2c92e,0x92722c85
+.word 0xa2bfe8a1,0xa81a664b,0xc24b8b70,0xc76c51a3
+.word 0xd192e819,0xd6990624,0xf40e3585,0x106aa070
+.word 0x19a4c116,0x1e376c08,0x2748774c,0x34b0bcb5
+.word 0x391c0cb3,0x4ed8aa4a,0x5b9cca4f,0x682e6ff3
+.word 0x748f82ee,0x78a5636f,0x84c87814,0x8cc70208
+.word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2
+.size K256,.-K256
+.word 0 @ terminator
+.word 0
+.align 5
+
+.align 5
+ENTRY(sha256_transform_neon)
+ /* Input:
+* %r0: SHA256_CONTEXT
+* %r1: data
+* %r2: nblks
+*/
+ sub r3,pc,#8@ sha256_transform_neon
+ add r2,r1,r2,lsl#6 @ len to point at the end of inp
+
+ stmdb sp!,{r4-r12,lr}
+
+ mov r12,sp
+ sub sp,sp,#16*4+16 @ alloca
+ sub r14,r3,#256+32 @ K256
+ bic sp,sp,#15 @ align for 128-bit stores
+
+ vld1.8 {q0},[r1]!
+ vld1.8 {q1},[r1]!
+ vld1.8 {q2},[r1]!
+ vld1.8 {q3},[r1]!
+ vld1.32 {q8},[r14,:128]!
+ vld1.32 {q9},[r14,:128]!
+ vld1.32 {q10},[r14,:128]!
+ vld1.32 {q11},[r14,:128]!
+ vrev32.8q0,q0 @ yes, even on
+ str r0,[sp,#64]
+ vrev32.8q1,q1 @ big-endian
+ str r1,[sp,#68]
+ mov r1,sp
+ vrev32.8q2,q2
+ str r2,[sp,#72]
+ vrev32.8q3,q3
+ str r12,[sp,#76]@ save original sp
+ vadd.i32q8,q8,q0
+ vadd.i32q9,q9,q1
+ vst1.32 {q8},[r1,:128]!
+ vadd.i32q10,q10,q2
+ vst1.32 {q9},[r1,:128]!
+ vadd.i32q11,q11,q3
+ vst1.32 {q10},[r1,:128]!
+ vst1.32 {q11},[r1,:128]!
+
+ ldmia r0,{r4-r11}
+ sub r1,r1,#64
+ ldr r2,[sp,#0]
+ eor r12,r12,r12
+ eor r3,r5,r6
+ b .L_00_48
+
+.align 4
+.L_00_48:
+ vext.8 q8,q0,q1,#4
+ add r11,r11,r2
+ eor r2,r9,r10
+ eor r0,r8,r8,ror#5
+ vext.8 q9,q2,q3,#4
+ add r4,r4,r12
+ and r2,r2,r8
+ eor r12,r0,r8,ror#19
+ vshr.u32q10,q8,#7
+ eor
[PATCH v2 net-next 0/4] Add support for async socket operations
After the iocb parameter has been removed from sendmsg() and recvmsg() ops the socket layer, and the network stack no longer support async operations. This patch set adds support for asynchronous operations on sockets back. -- Tadeusz Struk (4): net: socket: add support for async operations aio: prefer aio_op op over inter_op crypto: af_alg - Allow to link sgl crypto: algif - change algif_skcipher to be asynchronous Changes in v2: * removed redundant total_size param from aio_sendmsg and aio_recvmsg functions crypto/af_alg.c | 18 +++- crypto/algif_skcipher.c | 224 ++- fs/aio.c|8 +- include/crypto/if_alg.h |4 + include/linux/net.h |5 + net/socket.c| 63 + 6 files changed, 308 insertions(+), 14 deletions(-) -- -- 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 v2 net-next 1/4] net: socket: add support for async operations
Add support for async operations.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
include/linux/net.h |5
net/socket.c| 63 +++
2 files changed, 68 insertions(+)
diff --git a/include/linux/net.h b/include/linux/net.h
index e74114b..e9180bf 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -25,6 +25,7 @@
#include linux/kmemcheck.h
#include linux/rcupdate.h
#include linux/jump_label.h
+#include linux/aio.h
#include uapi/linux/net.h
struct poll_table_struct;
@@ -173,6 +174,10 @@ struct proto_ops {
*/
int (*recvmsg) (struct socket *sock, struct msghdr *m,
size_t total_len, int flags);
+ int (*aio_sendmsg)(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m);
+ int (*aio_recvmsg)(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, int flags);
int (*mmap) (struct file *file, struct socket *sock,
struct vm_area_struct * vma);
ssize_t (*sendpage) (struct socket *sock, struct page *page,
diff --git a/net/socket.c b/net/socket.c
index 95d3085..1364dfb 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -132,6 +132,11 @@ static ssize_t sock_splice_read(struct file *file, loff_t
*ppos,
struct pipe_inode_info *pipe, size_t len,
unsigned int flags);
+static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
+unsigned long nr_segs, loff_t loff);
+static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t loff);
+
/*
* Socket files have a set of 'special' operations as well as the generic
file ones. These don't appear
* in the operation structures but are done directly via the socketcall()
multiplexor.
@@ -144,6 +149,8 @@ static const struct file_operations socket_file_ops = {
.write =new_sync_write,
.read_iter =sock_read_iter,
.write_iter = sock_write_iter,
+ .aio_read = sock_aio_read,
+ .aio_write =sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
#ifdef CONFIG_COMPAT
@@ -836,6 +843,62 @@ static ssize_t sock_write_iter(struct kiocb *iocb, struct
iov_iter *from)
return res;
}
+static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
+unsigned long nr_segs, loff_t loff)
+{
+ struct file *file = iocb-ki_filp;
+ struct socket *sock = file-private_data;
+ struct iov_iter iter;
+ struct msghdr msg = {0};
+ ssize_t res;
+
+ if (file-f_flags O_NONBLOCK)
+ msg.msg_flags = MSG_DONTWAIT;
+
+ if (iocb-ki_pos != 0)
+ return -ESPIPE;
+
+ if (iocb-ki_nbytes == 0)
+ return 0;
+
+ if (sock-ops-aio_recvmsg) {
+ iov_iter_init(iter, READ, iov, nr_segs, iocb-ki_nbytes);
+ msg.msg_iter = iter;
+ res = sock-ops-aio_recvmsg(iocb, sock, msg, msg.msg_flags);
+ } else {
+ res = -EOPNOTSUPP;
+ }
+ return res;
+}
+
+static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t loff)
+{
+ struct file *file = iocb-ki_filp;
+ struct socket *sock = file-private_data;
+ struct iov_iter iter;
+ struct msghdr msg = {0};
+ ssize_t res;
+
+ if (iocb-ki_pos != 0)
+ return -ESPIPE;
+
+ if (file-f_flags O_NONBLOCK)
+ msg.msg_flags = MSG_DONTWAIT;
+
+ if (sock-type == SOCK_SEQPACKET)
+ msg.msg_flags |= MSG_EOR;
+
+ if (sock-ops-aio_sendmsg) {
+ iov_iter_init(iter, WRITE, iov, nr_segs, iocb-ki_nbytes);
+ msg.msg_iter = iter;
+ res = sock-ops-aio_sendmsg(iocb, sock, msg);
+ } else {
+ res = -EOPNOTSUPP;
+ }
+ return res;
+}
+
/*
* Atomic setting of ioctl hooks to avoid race
* with module unload.
--
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 v2 net-next 2/4] aio: prefer aio_op op over iter_op
AIO interface should prefer AIO operations over iter_op
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
fs/aio.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index f8e52a1..389f4dd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1449,11 +1449,15 @@ rw_common:
if (rw == WRITE)
file_start_write(file);
- if (iter_op) {
+ if (rw_op) {
+ ret = rw_op(req, iovec, nr_segs, req-ki_pos);
+ } else if (iter_op) {
iov_iter_init(iter, rw, iovec, nr_segs,
req-ki_nbytes);
ret = iter_op(req, iter);
} else {
- ret = rw_op(req, iovec, nr_segs, req-ki_pos);
+ if (iovec != inline_vecs)
+ kfree(iovec);
+ return -EINVAL;
}
if (rw == WRITE)
--
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 v2 net-next 3/4] crypto: af_alg - Allow to link sgl
From: Tadeusz Struk tadeusz.st...@intel.com
Allow to link af_alg sgls.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/af_alg.c | 18 +-
include/crypto/if_alg.h |4 +++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 7f8b7edc..26089d1 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -358,8 +358,8 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter
*iter, int len)
npages = (off + n + PAGE_SIZE - 1) PAGE_SHIFT;
if (WARN_ON(npages == 0))
return -EINVAL;
-
- sg_init_table(sgl-sg, npages);
+ /* Add one extra for linking */
+ sg_init_table(sgl-sg, npages + 1);
for (i = 0, len = n; i npages; i++) {
int plen = min_t(int, len, PAGE_SIZE - off);
@@ -369,18 +369,26 @@ int af_alg_make_sg(struct af_alg_sgl *sgl, struct
iov_iter *iter, int len)
off = 0;
len -= plen;
}
+ sg_mark_end(sgl-sg + npages - 1);
+ sgl-npages = npages;
+
return n;
}
EXPORT_SYMBOL_GPL(af_alg_make_sg);
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new)
+{
+ sg_unmark_end(sgl_prev-sg + sgl_prev-npages - 1);
+ sg_chain(sgl_prev-sg, sgl_prev-npages + 1, sgl_new-sg);
+}
+EXPORT_SYMBOL(af_alg_link_sg);
+
void af_alg_free_sg(struct af_alg_sgl *sgl)
{
int i;
- i = 0;
- do {
+ for (i = 0; i sgl-npages; i++)
put_page(sgl-pages[i]);
- } while (!sg_is_last(sgl-sg + (i++)));
}
EXPORT_SYMBOL_GPL(af_alg_free_sg);
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 178525e..018afb2 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -58,8 +58,9 @@ struct af_alg_type {
};
struct af_alg_sgl {
- struct scatterlist sg[ALG_MAX_PAGES];
+ struct scatterlist sg[ALG_MAX_PAGES + 1];
struct page *pages[ALG_MAX_PAGES];
+ unsigned int npages;
};
int af_alg_register_type(const struct af_alg_type *type);
@@ -70,6 +71,7 @@ int af_alg_accept(struct sock *sk, struct socket *newsock);
int af_alg_make_sg(struct af_alg_sgl *sgl, struct iov_iter *iter, int len);
void af_alg_free_sg(struct af_alg_sgl *sgl);
+void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new);
int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con);
--
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] arm: crypto: Add NEON optimized SHA-256
Hello Sami,
On 16 March 2015 at 16:48, Sami Tolvanen samitolva...@google.com wrote:
Add Andy Polyakov's NEON optimized SHA-256 implementation.
On Nexus 6, this implementation is ~2x faster than sha256-generic.
Signed-off-by: Sami Tolvanen samitolva...@google.com
Have you tested this code with the tcrypt.ko module?
Some more comments below
---
arch/arm/crypto/Makefile|2
arch/arm/crypto/sha256-armv7-neon.S | 819
arch/arm/crypto/sha256_neon_glue.c | 201
crypto/Kconfig | 12
4 files changed, 1034 insertions(+)
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index b48fa34..316dba2 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -6,12 +6,14 @@ obj-$(CONFIG_CRYPTO_AES_ARM) += aes-arm.o
obj-$(CONFIG_CRYPTO_AES_ARM_BS) += aes-arm-bs.o
obj-$(CONFIG_CRYPTO_SHA1_ARM) += sha1-arm.o
obj-$(CONFIG_CRYPTO_SHA1_ARM_NEON) += sha1-arm-neon.o
+obj-$(CONFIG_CRYPTO_SHA256_ARM_NEON) += sha256-arm-neon.o
obj-$(CONFIG_CRYPTO_SHA512_ARM_NEON) += sha512-arm-neon.o
aes-arm-y := aes-armv4.o aes_glue.o
aes-arm-bs-y := aesbs-core.o aesbs-glue.o
sha1-arm-y := sha1-armv4-large.o sha1_glue.o
sha1-arm-neon-y:= sha1-armv7-neon.o sha1_neon_glue.o
+sha256-arm-neon-y := sha256-armv7-neon.o sha256_neon_glue.o
sha512-arm-neon-y := sha512-armv7-neon.o sha512_neon_glue.o
quiet_cmd_perl = PERL$@
diff --git a/arch/arm/crypto/sha256-armv7-neon.S
b/arch/arm/crypto/sha256-armv7-neon.S
new file mode 100644
index 000..5ce04c2
--- /dev/null
+++ b/arch/arm/crypto/sha256-armv7-neon.S
@@ -0,0 +1,819 @@
+@ sha256-armv7-neon.S - ARM/NEON assembly implementation of SHA-256
transform
+@
+@
+@ Written by Andy Polyakov ap...@openssl.org for the OpenSSL
+@ project. The module is, however, dual licensed under OpenSSL and
+@ CRYPTOGAMS licenses depending on where you obtain it. For further
+@ details see http://www.openssl.org/~appro/cryptogams/.
+@
+
Did you talk to Andy about the license? I don't think this is
permissible for the kernel as-is.
+#include linux/linkage.h
+
+.text
+.code 32
+.fpu neon
+
+.type K256,%object
+.align 5
+K256:
+.word 0x428a2f98,0x71374491,0xb5c0fbcf,0xe9b5dba5
+.word 0x3956c25b,0x59f111f1,0x923f82a4,0xab1c5ed5
+.word 0xd807aa98,0x12835b01,0x243185be,0x550c7dc3
+.word 0x72be5d74,0x80deb1fe,0x9bdc06a7,0xc19bf174
+.word 0xe49b69c1,0xefbe4786,0x0fc19dc6,0x240ca1cc
+.word 0x2de92c6f,0x4a7484aa,0x5cb0a9dc,0x76f988da
+.word 0x983e5152,0xa831c66d,0xb00327c8,0xbf597fc7
+.word 0xc6e00bf3,0xd5a79147,0x06ca6351,0x14292967
+.word 0x27b70a85,0x2e1b2138,0x4d2c6dfc,0x53380d13
+.word 0x650a7354,0x766a0abb,0x81c2c92e,0x92722c85
+.word 0xa2bfe8a1,0xa81a664b,0xc24b8b70,0xc76c51a3
+.word 0xd192e819,0xd6990624,0xf40e3585,0x106aa070
+.word 0x19a4c116,0x1e376c08,0x2748774c,0x34b0bcb5
+.word 0x391c0cb3,0x4ed8aa4a,0x5b9cca4f,0x682e6ff3
+.word 0x748f82ee,0x78a5636f,0x84c87814,0x8cc70208
+.word 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2
+.size K256,.-K256
+.word 0 @ terminator
+.word 0
+.align 5
+
+.align 5
+ENTRY(sha256_transform_neon)
+ /* Input:
+* %r0: SHA256_CONTEXT
+* %r1: data
+* %r2: nblks
+*/
+ sub r3,pc,#8@ sha256_transform_neon
This is broken on thumb-2, use adr instead
+ add r2,r1,r2,lsl#6 @ len to point at the end of inp
+
+ stmdb sp!,{r4-r12,lr}
+
+ mov r12,sp
+ sub sp,sp,#16*4+16 @ alloca
+ sub r14,r3,#256+32 @ K256
+ bic sp,sp,#15 @ align for 128-bit stores
+
+ vld1.8 {q0},[r1]!
+ vld1.8 {q1},[r1]!
+ vld1.8 {q2},[r1]!
+ vld1.8 {q3},[r1]!
+ vld1.32 {q8},[r14,:128]!
+ vld1.32 {q9},[r14,:128]!
+ vld1.32 {q10},[r14,:128]!
+ vld1.32 {q11},[r14,:128]!
+ vrev32.8q0,q0 @ yes, even on
+ str r0,[sp,#64]
+ vrev32.8q1,q1 @ big-endian
+ str r1,[sp,#68]
+ mov r1,sp
+ vrev32.8q2,q2
+ str r2,[sp,#72]
+ vrev32.8q3,q3
+ str r12,[sp,#76]@ save original sp
+ vadd.i32q8,q8,q0
+ vadd.i32q9,q9,q1
+ vst1.32 {q8},[r1,:128]!
+ vadd.i32q10,q10,q2
+ vst1.32 {q9},[r1,:128]!
+ vadd.i32q11,q11,q3
+ vst1.32 {q10},[r1,:128]!
+ vst1.32 {q11},[r1,:128]!
+
+ ldmia r0,{r4-r11}
+ sub r1,r1,#64
+ ldr
Re: [PATCH] arm: crypto: Add NEON optimized SHA-256
On Mon, Mar 16, 2015 at 05:08:03PM +0100, Ard Biesheuvel wrote: Have you tested this code with the tcrypt.ko module? I have not, but I can look into it. Did you talk to Andy about the license? I don't think this is permissible for the kernel as-is. Unless I have misunderstood something, the license at the Cryptogams website includes an option to license the code under the GNU GPL. However, I can certainly contact Andy to clarify his intentions. This is broken on thumb-2, use adr instead You can also implement SHA-224 using the same core transform, it's just some trivial glue code. Could you please rebase this onto Herbert's cryptodev tree and move this to arch/arm/crypto/Kconfig? Thanks for the comments, I will submit a second version once we have a clarification on the license. Sami -- 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 06/10] ARM: dts: omap3: Add missing dmas for crypto
* Pavel Machek pa...@ucw.cz [150228 08:49]: On Thu 2015-02-26 14:49:56, Pali Rohár wrote: This patch adds missing dma DTS definitions for omap aes and sham drivers. Without it kernel drivers do not work. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: PavelMachek pa...@ucw.cz Applying this into omap-for-v4.0/fixes to remove the regression for legacy vs DT based booting for GP omap3 boards. Tony -- 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 v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0e1abe8..ebca296 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10923,6 +10923,12 @@ L: linux...@kvack.org S: Maintained F: mm/zswap.c +ALLWINNER SECURITY SYSTEM +M: Corentin Labbe clabbe.montj...@gmail.com +L: linux-crypto@vger.kernel.org +S: Maintained +F: drivers/crypto/sunxi-ss/ + THE REST M: Linus Torvalds torva...@linux-foundation.org L: linux-ker...@vger.kernel.org -- 2.0.5 -- 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 v6 1/4] ARM: sun7i: dt: Add Security System to A20 SoC DTS
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3a8530b..8995bec 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -680,6 +680,14 @@
status = disabled;
};
+ crypto: crypto-engine@01c15000 {
+ compatible = allwinner,sun7i-a20-crypto;
+ reg = 0x01c15000 0x1000;
+ interrupts = 0 86 4;
+ clocks = ahb_gates 5, ss_clk;
+ clock-names = ahb, mod;
+ };
+
spi2: spi@01c17000 {
compatible = allwinner,sun4i-a10-spi;
reg = 0x01c17000 0x1000;
--
2.0.5
--
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 v6 4/4] crypto: Add Allwinner Security System crypto accelerator
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC mode
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
drivers/crypto/Kconfig| 17 ++
drivers/crypto/Makefile | 1 +
drivers/crypto/sunxi-ss/Makefile | 2 +
drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 408 +
drivers/crypto/sunxi-ss/sunxi-ss-core.c | 339 +
drivers/crypto/sunxi-ss/sunxi-ss-hash.c | 475 ++
drivers/crypto/sunxi-ss/sunxi-ss.h| 200 +
7 files changed, 1442 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/Makefile
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..9ba9759 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
hardware. To compile this driver as a module, choose M here. The
module will be called qcrypto.
+config CRYPTO_DEV_SUNXI_SS
+ tristate Support for Allwinner Security System cryptographic
accelerator
+ depends on ARCH_SUNXI
+ select CRYPTO_MD5
+ select CRYPTO_SHA1
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+ help
+ Some Allwinner SoC have a crypto accelerator named
+ Security System. Select this if you want to use it.
+ The Security System handle AES/DES/3DES ciphers in CBC mode
+ and SHA1 and MD5 hash algorithms.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunxi-ss.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..856545c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
new file mode 100644
index 000..8bb287d
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
+sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
new file mode 100644
index 000..3ed0ad0
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
@@ -0,0 +1,408 @@
+/*
+ * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 SoC
+ *
+ * Copyright (C) 2013-2015 Corentin LABBE clabbe.montj...@gmail.com
+ *
+ * This file add support for AES cipher with 128,192,256 bits
+ * keysize in CBC mode.
+ * Add support also for DES and 3DES in CBC mode.
+ *
+ * You could find the datasheet in Documentation/arm/sunxi/README
+ *
+ * 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 sunxi-ss.h
+
+static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
+{
+ struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+ struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
+ const char *cipher_type;
+ struct sunxi_ss_ctx *ss = op-ss;
+
+ if (areq-nbytes == 0)
+ return 0;
+
+ if (areq-info == NULL) {
+ dev_err(ss-dev, ERROR: Empty IV\n);
+ return -EINVAL;
+ }
+
+ if (areq-src == NULL || areq-dst == NULL) {
+ dev_err(ss-dev, ERROR: Some SGs are NULL\n);
+ return -EINVAL;
+ }
+
+ cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
+
+ if (strcmp(cbc(aes), cipher_type) == 0) {
+ mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_aes_poll(areq, mode);
+ }
+
+ if (strcmp(cbc(des), cipher_type) == 0) {
+ mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_des_poll(areq, mode);
+ }
+
+ if (strcmp(cbc(des3_ede), cipher_type) == 0) {
+ mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op-keymode;
+ return sunxi_ss_des_poll(areq, mode);
+ }
+
+ dev_err(ss-dev, ERROR: Cipher %s not handled\n, cipher_type);
+ return
[PATCH v6] crypto: Add Allwinner Security System crypto accelerator
Hello This is the driver for the Security System included in Allwinner SoC A20. The Security System (SS for short) is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. It could be found on others Allwinner SoC: - A10s, A33 and A31 diagram speak about it with precisions (AES/DES/3DES/Md5/SHA1/PRNG) - A10 and A13 manual give the same datasheet for SS than A20 - A23 speak about a security system but without precisions - A80 datasheet speak about a security system with more functions (SHA224/SHA256/RSA/CRC) but without precisions But I do not have access on any of those hardware, tests are welcome. This driver currently supports: - MD5 and SHA1 hash algorithms - AES block cipher in CBC mode with 128/196/256bits keys. - DES and 3DES block cipher in CBC mode The driver exposes all those algorithms through the kernel cryptographic API. The driver support only CPU driven (aka poll mode) transfer mode, since the DMA engine of the A20 does not have a mainline driver yet. Changes since v5: - Hash functions now keep partial hash states in sunxi_ss structures - Use of spinlock instead of mutex - Remove the static sunxi_ss structures by using container of - Add export/import functions - replace lots of writel by writesl - replace lots of readl by readsl Changes since v4: - Rework all mutex path - Use ahash_request_ctx() in hash functions - Major rework of hash functions for solving mutex problems - Split sunxi_req_ctx in two since ciphers now use struct sunxi_tfm_ctx - Hash functions now test FIFO space register Changes since v3: - Remove all algorithms options from Kconfig, so now only one module is used - Add the sunxi_ss_cipher function to unify mode calculation - Remove the sunxi_cipher_exit empty function - Add some missing mutex_unlock() - Drop PRNG support, I wait for more comment on its results before re-enabling it. Changes since v2: - Fix Makefile and Kconfig for static kernel. Changes since v1: - annotate ss-base as __iomem - regroup all mutex in the ss_ctx structure - splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss directory - use dev_exit_p() for .remove - added missing CRYPTO_BLKCIPHER dep in Kconfig - use ahash instead of shash - use ablkcipher instead of blkcipher - use crypto_rng_ctx instead of crypto_tfm_ctx - set seed as an u32 - drop useless comment decoration - drop useless debug - ss_ctx is now a static pointer and whole structure being allocated - fix the platform_get_resource/devm_ioremap_resource pattern - invert getting die id and configuring clock - set clock value as a const unsigned long - add MODULE_ALIAS - use define names more consistency (SS_xxx) - fix PRNG errors - respell SS to Security System in DT documentation -- 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 0/2] crypto: talitos: Add AES-XTS mode
On 3/13/2015 4:08 PM, Martin Hicks wrote:
Hi Horia,
On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
horia.gea...@freescale.com wrote:
While here: note that xts-talitos supports only two key lengths - 256
and 512 bits. There are tcrypt speed tests that check also for 384-bit
keys (which is out-of-spec, but still...), leading to a Key Size Error
- see below (KSE bit in AESU Interrupt Status Register is set)
Ok. I've limited the keysize to 32 or 64 bytes for AES-XTS in the
talitos driver.
This was my first experiments with the tcrypt module. It also brought
up another issue related to the IV limitations of this hardware. The
latest patch that I have returns an error when there is a non-zero
value in the second 8 bytes of the IV:
+ /*
+* AES-XTS uses the first two AES Context registers for:
+*
+* Register 1: Sector Number (Little Endian)
+* Register 2: Sector Size (Big Endian)
+*
+* Whereas AES-CBC uses registers 1/2 as a 16-byte IV.
+*/
+ if ((ctx-desc_hdr_template
+(DESC_HDR_SEL0_MASK | DESC_HDR_MODE0_MASK)) ==
+(DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XTS)) {
+ u64 *aesctx2 = (u64 *)areq-info + 1;
+
+ if (*aesctx2 != 0) {
+ dev_err(ctx-dev,
+ IV length limited to the first 8 bytes.);
+ return ERR_PTR(-EINVAL);
+ }
+
+ /* Fixed sized sector */
+ *aesctx2 = cpu_to_be64(1 SECTOR_SHIFT);
+ }
This approach causes the tcrypt tests to fail because tcrypt sets all
16 bytes of the IV to 0xff. I think returning an error is the right
approach for the talitos module, but it would be nice if tcrypt still
worked. Should tcrypt just set the IV bytes to 0 instead of 0xff?
Isn't one IV just as good as another? I think adding exceptions to
the tcrypt code would be ugly, but maybe one should be made for XTS
since the standard dictates that the IV should be plain or plain64?
AFAICT xts-aes standard does not mandate for plain or plain64.
The requirements are the following (below IV = tweak value, sector =
data unit):
-IV size: 16 bytes
-IV format: little endian byte array
-IV values: non-negative; consecutive IV values for consecutive sectors
In practice, an 8-byte IV should be enough to represent the sector index
even for large capacity storage devices.
However, dm-crypt has support for a user-provided iv_offset that is
added to the sector index: IV = sector_index + iv_offset.
While in most of the cases user would choose iv_offset = 0, in theory
anything is possible.
IMHO the correct approach would be to use a fallback tfm that would
handle all the requests with IVs 8 bytes.
We can take this off-list if you prefer.
Horia
--
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 v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System
On Mon, 2015-03-16 at 20:01 +0100, LABBE Corentin wrote: [] diff --git a/MAINTAINERS b/MAINTAINERS [] @@ -10923,6 +10923,12 @@ L: linux...@kvack.org S: Maintained F: mm/zswap.c +ALLWINNER SECURITY SYSTEM +M: Corentin Labbe clabbe.montj...@gmail.com +L: linux-crypto@vger.kernel.org +S: Maintained +F: drivers/crypto/sunxi-ss/ Use alphabetic ordering for new sections please. Please place this section between: ALI1563 I2C DRIVER and ALPHA PORT -- 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 12/12] crypto/sha-mb/sha1_mb.c : Syntax error
On Fri, Mar 13, 2015 at 11:38:21PM +0200, Ameen Ali wrote: fixing a syntax-error . Signed-off-by : Ameen Ali ameenali...@gmail.com Applied. -- Email: Herbert Xu herb...@gondor.apana.org.au 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
