Re: [PATCH 2/3 v2] RFC4106 AES-GCM Driver Using Intel New Instructions - fixed build with binutils 2.16
On Fri, Dec 10, 2010 at 12:34:07PM +, tadeusz.st...@intel.com wrote: From tadeusz.st...@intel.com Mon Sep 17 00:00:00 2001 From: root r...@tweedle-dum.ir.intel.com Date: Fri, 10 Dec 2010 12:10:57 + Subject: [PATCH 2/3 v2] RFC4106 AES-GCM Driver Using Intel New Instructions - fixed build with binutils 2.16 Hi Herbert, This patch fixes the problem with 2.16 binutils. Regards, Tadeusz Signed-off-by: Aidan O'Mahony aidan.o.mah...@intel.com Signed-off-by: Adrian Hoban adrian.ho...@intel.com Signed-off-by: Gabriele Paoloni gabriele.paol...@intel.com Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Patch applied. Thanks a lot! -- 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
[PATCH] Add RNG support to AF_ALG
This patch enhances the AF_ALG protocol family to include support for random
number generator algorithms. With this enhancment, users of the AF_ALG protocol
can now bind sockets to instances of the various RNG algorithms available to the
kernel. For those RNG's that support it, instances can be reseeded using the
SETKEY socket option within the AF_ALG socket family. Like with hashes and
ciphers, only the intially created socket allows seeding, and only child sockets
retured via accept may return random data. Sending data on RNG instances is
prohibited, only receiving RNG data is possible.
Tested successfully using NIST provided RNG vectors by myself:
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
---
crypto/Kconfig |9 +++
crypto/Makefile|1 +
crypto/algif_rng.c | 197
3 files changed, 207 insertions(+), 0 deletions(-)
create mode 100644 crypto/algif_rng.c
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 96b0e55..ea448ca 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -864,6 +864,15 @@ config CRYPTO_USER_API_SKCIPHER
This option enables the user-spaces interface for symmetric
key cipher algorithms.
+config CRYPTO_USER_API_RNG
+ tristate User-space interface for Random Number Generator algorithms
+ depends on NET
+ select CRYPTO_ANSI_CPRNG
+ select CRYPTO_USER_API
+ help
+ This option enables the user-space interface for random number
+ generation algorithms.
+
source drivers/crypto/Kconfig
endif # if CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index e9a399c..8868555 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
#
# generic algorithms and the async_tx api
diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 000..b660a2a
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,197 @@
+/*
+ * algif_rng: User-space interface for rng algorithms
+ *
+ * This file provides the user-space API for rng algorithms.
+ *
+ * Copyright (c) 2010 Neil Horman nhor...@tuxdriver.com
+ *
+ * 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 crypto/rng.h
+#include crypto/if_alg.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/net.h
+#include net/sock.h
+
+struct rng_ctx {
+ struct crypto_rng *ctx;
+ u8 *seed;
+ size_t seedlen;
+ char *name;
+ u32 type;
+ u32 mask;
+};
+
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask-private;
+ int rc, i;
+ u8 *data = kzalloc(len, GFP_KERNEL);
+
+ if (!data)
+ return -ENOMEM;
+ rc = crypto_rng_get_bytes(ctx-ctx, data, len);
+ if (rc 0)
+ goto out;
+
+ rc = memcpy_toiovec(msg-msg_iov, data, len);
+out:
+ kfree(data);
+ return rc ?: len;
+}
+
+
+static const struct proto_ops algif_rng_ops = {
+ .family = PF_ALG,
+
+ .connect= sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname= sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .setsockopt = sock_no_setsockopt,
+ .poll = sock_no_poll,
+
+ .release= af_alg_release,
+ .sendmsg= sock_no_sendmsg,
+ .sendpage = sock_no_sendpage,
+ .recvmsg= rng_recvmsg,
+ .accept = sock_no_accept,
+};
+
+static void *rng_bind(const char *name, u32 type, u32 mask)
+{
+ struct rng_ctx *new = kzalloc(sizeof(struct rng_ctx), GFP_KERNEL);
+
+ if (!new)
+ goto out;
+
+ new-name = kmemdup(name, strnlen(name, 63)+1, GFP_KERNEL);
+ new-type = type;
+ new-mask = mask;
+out:
+ return new;
+}
+
+static void rng_release(void *private)
+{
+ struct rng_ctx *ctx = private;
+ crypto_free_rng(ctx-ctx);
+
Re: [PATCH] Add RNG support to AF_ALG
On Mon, Dec 13, 2010 at 12:24:34PM -0500, Miloslav Trmac wrote:
- Neil Horman nhor...@tuxdriver.com wrote:
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask-private;
+ int rc, i;
+ u8 *data = kzalloc(len, GFP_KERNEL);
There probably should be an upper limit on the allocation - perhaps just
always allocate a single page.
I'd rather allocate the explicit amount needed, just to avoid added memory
pressure allocating memory that we won't use, but yes, I can definately add an
upper limit to how much data can be requested in a single call.
+static void rng_release(void *private)
+{
+ struct rng_ctx *ctx = private;
+ crypto_free_rng(ctx-ctx);
+ kfree(ctx-seed);
Is a seed secret enough that it should be zeroed before freeing? (Same in
setkey, accept_parent).
I don't think that nececcecary, strictly speaking, but it couldn't hurt.
Actually looking at it, I don't really need to duplicate the seed at all in
accept_parent. I can probaby shrink that down considerably.
Thanks for the notes Mirek, I'll post an updated version shortly.
Neil
Mirek
--
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] Add RNG support to AF_ALG
- Neil Horman nhor...@tuxdriver.com wrote:
On Mon, Dec 13, 2010 at 12:24:34PM -0500, Miloslav Trmac wrote:
- Neil Horman nhor...@tuxdriver.com wrote:
+static int rng_recvmsg(struct kiocb *unused, struct socket
*sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask-private;
+ int rc, i;
+ u8 *data = kzalloc(len, GFP_KERNEL);
There probably should be an upper limit on the allocation - perhaps
just always allocate a single page.
I'd rather allocate the explicit amount needed, just to avoid added memory
pressure allocating memory that we won't use, but yes, I can definately add an
upper limit to how much data can be requested in a single call.
Please allow arbitrarily large requests. rng_recvmsg can easily use a smaller
buffer by filling the user-space destination one buffer-size at a time, on the
other hand handling an arbitrary upper limit in user-space would be
unnecessarily complex.
Mirek
--
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 Hardware Drivers?
Tobias Karnat wrote: In case it is based on TI OMAP, there are already drivers available: No, unfortunately, it isn't. -kb, the Kent who has looked through the existing crypto drivers to learn how they work, and who would have loved to have found one that matched his hardware. -- 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] Add RNG support to AF_ALG (v2)
Change notes:
Changed rng_rcvmsg to allocate a fixed size maximum temp block to store rng data
when recvmsg is called. This should prevent malicious DoS from user space by
tring to receive obscene amounts of random data in one call. Instead now we
loop using the same block of data and copy it incrementally to the user space
buffer using memcpy_toiovecend
Also changed the accept routine to only allocate a new rng, and not store the
seed value separately, simplifying the code somewhat. also now we memset the
parent sockets seed value to zero on free to hide the seed from intruders.
Summary:
This patch enhances the AF_ALG protocol family to include support for random
number generator algorithms. With this enhancment, users of the AF_ALG protocol
can now bind sockets to instances of the various RNG algorithms available to the
kernel. For those RNG's that support it, instances can be reseeded using the
SETKEY socket option within the AF_ALG socket family. Like with hashes and
ciphers, only the intially created socket allows seeding, and only child sockets
retured via accept may return random data. Sending data on RNG instances is
prohibited, only receiving RNG data is possible.
Tested successfully using NIST provided RNG vectors by myself:
Signed-off-by: Neil Horman nhor...@tuxdriver.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
---
crypto/Kconfig |9 ++
crypto/Makefile|1 +
crypto/algif_rng.c | 212
3 files changed, 222 insertions(+), 0 deletions(-)
create mode 100644 crypto/algif_rng.c
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 96b0e55..ea448ca 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -864,6 +864,15 @@ config CRYPTO_USER_API_SKCIPHER
This option enables the user-spaces interface for symmetric
key cipher algorithms.
+config CRYPTO_USER_API_RNG
+ tristate User-space interface for Random Number Generator algorithms
+ depends on NET
+ select CRYPTO_ANSI_CPRNG
+ select CRYPTO_USER_API
+ help
+ This option enables the user-space interface for random number
+ generation algorithms.
+
source drivers/crypto/Kconfig
endif # if CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index e9a399c..8868555 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
#
# generic algorithms and the async_tx api
diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 000..8664793
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,212 @@
+/*
+ * algif_rng: User-space interface for rng algorithms
+ *
+ * This file provides the user-space API for rng algorithms.
+ *
+ * Copyright (c) 2010 Neil Horman nhor...@tuxdriver.com
+ *
+ * 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 crypto/rng.h
+#include crypto/if_alg.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/net.h
+#include net/sock.h
+
+struct rng_ctx {
+ struct crypto_rng *ctx;
+ u8 *seed;
+ size_t seedlen;
+ char *name;
+ u32 type;
+ u32 mask;
+};
+
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct crypto_rng *ctx = ask-private;
+ int rc = 0;
+ int rc2;
+ u8 *data;
+ size_t alen, clen;
+
+ /*
+* Prevent huge memory allocations from user space
+*/
+ alen = (len PAGE_SIZE) ? PAGE_SIZE : len;
+ data = kzalloc(alen, GFP_KERNEL);
+
+ if (!data)
+ return -ENOMEM;
+
+ clen = 0;
+ while (clen != len) {
+ rc = crypto_rng_get_bytes(ctx, data, alen);
+ if (rc 0)
+ goto out;
+
+ rc2 = memcpy_toiovecend(msg-msg_iov, data, clen, rc);
+ if (rc2) {
+ rc = rc2;
+ goto out;
+ }
+
+ clen += rc;
+
+ /*
+* Get the remaining bytes
+*/
+ if ((len-clen) alen)
+ alen = len-clen;
+ rc = 0;
+ }
+out:
+ kfree(data);
+ return rc ?: len;
+}
+
+
+static struct proto_ops algif_rng_ops = {
+ .family = PF_ALG,
+
+ .connect=
Re: [PATCH 2/3] RFC4106 AES-GCM Driver Using Intel New Instructions
On Fri, Dec 03, 2010 at 09:30:21AM +0800, Herbert Xu wrote: Andrew, I'll just back this out if it doesn't get resolved. Andrew, the problem should be resolved in the current cryptodev tree. Please let me know if it still blows up for you. 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
