[PATCH v5 0/8] crypto: AF_ALG: add AEAD and RNG support

[PATCH v5 0/8] crypto: AF_ALG: add AEAD and RNG support

[Stephan Mueller]

Hi,

This patch set adds AEAD and RNG support to the AF_ALG interface
exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
support, all cipher types the kernel crypto API allows access to are
now accessible from userspace.

Both, AEAD and RNG implementations are stand-alone and do not depend
other AF_ALG interfaces (like hash or skcipher).

The AEAD implementation uses the same approach as provided with
skcipher by offering the following interfaces:

	* sendmsg and recvmsg interfaces allowing multiple
	  invocations supporting a threaded user space. To support
	  multi-threaded user space, kernel-side buffering
	  is implemented similarly to skcipher.

	* splice / vmsplice interfaces allowing a zero-copy
	  invocation

The RNG interface only implements the recvmsg interface as
zero-copy is not applicable.

The new AEAD and RNG interfaces are fully tested with the test application
provided at [1]. That test application exercises all newly added user space
interfaces. The testing covers:

	* use of the sendmsg/recvmsg interface

	* use of the splice / vmsplice interface

	* invocation of all AF_ALG types (aead, rng, skcipher, hash)

	* using all types of operation (encryption, decryption, keyed MD,
	  MD, random numbers, AEAD decryption with positive and negative
	  authentication verification)

	* stress testing by running all tests for 30 minutes in an
	  endless loop

	* test execution on 64 bit and 32 bit

[1] http://www.chronox.de/libkcapi.html

Changes v2:
* rebase to current cryptodev-2.6 tree
* use memzero_explicit to zeroize AEAD associated data
* use sizeof for determining length of AEAD associated data
* update algif_rng.c covering all suggestions from Daniel Borkmann
  <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
* addition of patch 9: add digestsize interface for hashes
* addition of patch to update documentation covering the userspace interface
* change numbers of getsockopt options: separate them from sendmsg interface
  definitions

Changes v3:
* remove getsockopt interface
* AEAD: associated data is set prepended to the plain/ciphertext
* AEAD: allowing arbitrary associated data lengths
* remove setkey patch as protection was already in the existing code

Changes v4:
* stand-alone implementation of AEAD
* testing of all interfaces offered by AEAD
* stress testing of AEAD and RNG

Changes v5:
* AEAD: add outer while(size) loop in aead_sendmsg to ensure all data is
  copied into the kernel (reporter Herbert Xu)
* AEAD: aead_sendmsg bug fix: change size -= len; to size -= plen;
* AF_ALG / AEAD: add aead_setauthsize and associated extension to
  struct af_alg_type as well as alg_setsockopt (reporter Herbert Xu)
* RNG: rng_recvmsg: use 128 byte stack variable for output of RNG instead
  of ctx->result (reporter Herbert Xu)
* RNG / AF_ALG: allow user space to seed RNG via setsockopt
* RNG: rng_recvmsg bug fix: use genlen as result variable for
  crypto_rng_get_bytes as previously no negative errors were obtained 
* AF_ALG: alg_setop: zeroize buffer before free


Stephan Mueller (8):
  crypto: AF_ALG: add user space interface for AEAD
  crypto: AF_ALG: add setsockopt for auth tag size
  crypto: AF_ALG: add AEAD support
  crypto: AF_ALG: enable AEAD interface compilation
  crypto: AF_ALG: add user space interface for RNG
  crypto: AF_ALG: zeroize key / seed data
  crypto: AF_ALG: add random number generator support
  crypto: AF_ALG: enable RNG interface compilation

 crypto/Kconfig              |  18 ++
 crypto/Makefile             |   2 +
 crypto/af_alg.c             |  42 ++-
 crypto/algif_aead.c         | 650 ++++++++++++++++++++++++++++++++++++++++++++
 crypto/algif_rng.c          | 192 +++++++++++++
 include/crypto/if_alg.h     |   3 +
 include/uapi/linux/if_alg.h |   3 +
 7 files changed, 900 insertions(+), 10 deletions(-)
 create mode 100644 crypto/algif_aead.c
 create mode 100644 crypto/algif_rng.c

-- 
2.1.0

[PATCH v5 0/8] crypto: AF_ALG: add AEAD and RNG support

[Stephan Mueller]

Hi,

This patch set adds AEAD and RNG support to the AF_ALG interface
exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
support, all cipher types the kernel crypto API allows access to are
now accessible from userspace.

Both, AEAD and RNG implementations are stand-alone and do not depend
other AF_ALG interfaces (like hash or skcipher).

The AEAD implementation uses the same approach as provided with
skcipher by offering the following interfaces:

	* sendmsg and recvmsg interfaces allowing multiple
	  invocations supporting a threaded user space. To support
	  multi-threaded user space, kernel-side buffering
	  is implemented similarly to skcipher.

	* splice / vmsplice interfaces allowing a zero-copy
	  invocation

The RNG interface only implements the recvmsg interface as
zero-copy is not applicable.

The new AEAD and RNG interfaces are fully tested with the test application
provided at [1]. That test application exercises all newly added user space
interfaces. The testing covers:

	* use of the sendmsg/recvmsg interface

	* use of the splice / vmsplice interface

	* invocation of all AF_ALG types (aead, rng, skcipher, hash)

	* using all types of operation (encryption, decryption, keyed MD,
	  MD, random numbers, AEAD decryption with positive and negative
	  authentication verification)

	* stress testing by running all tests for 30 minutes in an
	  endless loop

	* test execution on 64 bit and 32 bit

[1] http://www.chronox.de/libkcapi.html

Changes v2:
* rebase to current cryptodev-2.6 tree
* use memzero_explicit to zeroize AEAD associated data
* use sizeof for determining length of AEAD associated data
* update algif_rng.c covering all suggestions from Daniel Borkmann
  <dborkman@redhat.com>
* addition of patch 9: add digestsize interface for hashes
* addition of patch to update documentation covering the userspace interface
* change numbers of getsockopt options: separate them from sendmsg interface
  definitions

Changes v3:
* remove getsockopt interface
* AEAD: associated data is set prepended to the plain/ciphertext
* AEAD: allowing arbitrary associated data lengths
* remove setkey patch as protection was already in the existing code

Changes v4:
* stand-alone implementation of AEAD
* testing of all interfaces offered by AEAD
* stress testing of AEAD and RNG

Changes v5:
* AEAD: add outer while(size) loop in aead_sendmsg to ensure all data is
  copied into the kernel (reporter Herbert Xu)
* AEAD: aead_sendmsg bug fix: change size -= len; to size -= plen;
* AF_ALG / AEAD: add aead_setauthsize and associated extension to
  struct af_alg_type as well as alg_setsockopt (reporter Herbert Xu)
* RNG: rng_recvmsg: use 128 byte stack variable for output of RNG instead
  of ctx->result (reporter Herbert Xu)
* RNG / AF_ALG: allow user space to seed RNG via setsockopt
* RNG: rng_recvmsg bug fix: use genlen as result variable for
  crypto_rng_get_bytes as previously no negative errors were obtained 
* AF_ALG: alg_setop: zeroize buffer before free


Stephan Mueller (8):
  crypto: AF_ALG: add user space interface for AEAD
  crypto: AF_ALG: add setsockopt for auth tag size
  crypto: AF_ALG: add AEAD support
  crypto: AF_ALG: enable AEAD interface compilation
  crypto: AF_ALG: add user space interface for RNG
  crypto: AF_ALG: zeroize key / seed data
  crypto: AF_ALG: add random number generator support
  crypto: AF_ALG: enable RNG interface compilation

 crypto/Kconfig              |  18 ++
 crypto/Makefile             |   2 +
 crypto/af_alg.c             |  42 ++-
 crypto/algif_aead.c         | 650 ++++++++++++++++++++++++++++++++++++++++++++
 crypto/algif_rng.c          | 192 +++++++++++++
 include/crypto/if_alg.h     |   3 +
 include/uapi/linux/if_alg.h |   3 +
 7 files changed, 900 insertions(+), 10 deletions(-)
 create mode 100644 crypto/algif_aead.c
 create mode 100644 crypto/algif_rng.c

-- 
2.1.0

[PATCH v5 1/8] crypto: AF_ALG: add user space interface for AEAD

[Stephan Mueller]

AEAD requires the caller to specify the following information separate
from the data stream. This information allows the AEAD interface handler
to identify the AAD, ciphertext/plaintext and the authentication tag:

        * Associated authentication data of arbitrary length and
          length

        * Length of authentication tag for encryption

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/af_alg.c             | 6 ++++++
 include/crypto/if_alg.h     | 1 +
 include/uapi/linux/if_alg.h | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..68ff113 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -421,6 +421,12 @@ int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con)
 			con->op = *(u32 *)CMSG_DATA(cmsg);
 			break;
 
+		case ALG_SET_AEAD_ASSOCLEN:
+			if (cmsg->cmsg_len < CMSG_LEN(sizeof(u32)))
+				return -EINVAL;
+			con->aead_assoclen = *(u32 *)CMSG_DATA(cmsg);
+			break;
+
 		default:
 			return -EINVAL;
 		}
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index d61c111..cd62bf4 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -42,6 +42,7 @@ struct af_alg_completion {
 struct af_alg_control {
 	struct af_alg_iv *iv;
 	int op;
+	unsigned int aead_assoclen;
 };
 
 struct af_alg_type {
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index 0f9acce..f2acd2f 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -32,6 +32,8 @@ struct af_alg_iv {
 #define ALG_SET_KEY			1
 #define ALG_SET_IV			2
 #define ALG_SET_OP			3
+#define ALG_SET_AEAD_ASSOCLEN		4
+#define ALG_SET_AEAD_AUTHSIZE		5
 
 /* Operations */
 #define ALG_OP_DECRYPT			0
-- 
2.1.0

[PATCH v5 2/8] crypto: AF_ALG: add setsockopt for auth tag size

[Stephan Mueller]

Use setsockopt on the tfm FD to provide the authentication tag size for
an AEAD cipher. This is achieved by adding a callback function which is
intended to be used by the AEAD AF_ALG implementation.

The optlen argument of the setsockopt specifies the authentication tag
size to be used with the AEAD tfm.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/af_alg.c         | 7 +++++++
 include/crypto/if_alg.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 68ff113..547c369 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -215,6 +215,13 @@ static int alg_setsockopt(struct socket *sock, int level, int optname,
 			goto unlock;
 
 		err = alg_setkey(sk, optval, optlen);
+		break;
+	case ALG_SET_AEAD_AUTHSIZE:
+		if (sock->state == SS_CONNECTED)
+			goto unlock;
+		if (!type->setauthsize)
+			goto unlock;
+		err = type->setauthsize(ask->private, optlen);
 	}
 
 unlock:
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index cd62bf4..5c7b6c5 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -50,6 +50,7 @@ struct af_alg_type {
 	void (*release)(void *private);
 	int (*setkey)(void *private, const u8 *key, unsigned int keylen);
 	int (*accept)(void *private, struct sock *sk);
+	int (*setauthsize)(void *private, unsigned int authsize);
 
 	struct proto_ops *ops;
 	struct module *owner;
-- 
2.1.0

[PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

This patch adds the AEAD support for AF_ALG.

The implementation is based on algif_skcipher, but contains heavy
modifications to streamline the interface for AEAD uses.

To use AEAD, the user space consumer has to use the salg_type named
"aead".

The AEAD implementation includes some overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explaining when and how that operation is performed.

A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/algif_aead.c | 650 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 650 insertions(+)
 create mode 100644 crypto/algif_aead.c

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
new file mode 100644
index 0000000..97d6a0e
--- /dev/null
+++ b/crypto/algif_aead.c
@@ -0,0 +1,650 @@
+/*
+ * algif_aeadr: User-space interface for AEAD algorithms
+ *
+ * Copyright (C) 2014, Stephan Mueller <smueller@chronox.de>
+ *
+ * This file provides the user-space API for AEAD ciphers.
+ *
+ * This file is derived from algif_skcipher.c.
+ *
+ * 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/scatterwalk.h>
+#include <crypto/if_alg.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/net.h>
+#include <net/sock.h>
+
+struct aead_sg_list {
+	unsigned int cur;
+	struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+struct aead_ctx {
+	struct aead_sg_list tsgl;
+	struct af_alg_sgl rsgl;
+
+	void *iv;
+
+	struct af_alg_completion completion;
+
+	unsigned long used;
+
+	unsigned int len;
+	bool more;
+	bool merge;
+	bool enc;
+
+	size_t aead_assoclen;
+	struct aead_request aead_req;
+};
+
+static inline int aead_sndbuf(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+
+	return max_t(int, max_t(int, sk->sk_sndbuf & PAGE_MASK, PAGE_SIZE) -
+			  ctx->used, 0);
+}
+
+static inline bool aead_writable(struct sock *sk)
+{
+	return PAGE_SIZE <= aead_sndbuf(sk);
+}
+
+static inline bool aead_sufficient_data(struct aead_ctx *ctx)
+{
+	unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx->aead_req));
+
+	return (ctx->used >= (ctx->aead_assoclen + ctx->enc ? : as ));
+}
+static inline bool aead_readable(struct aead_ctx *ctx)
+{
+	/*
+	 * Ensure that assoc data is present, the plaintext / ciphertext
+	 * is non-zero and that the authentication tag is also present
+	 * in case of a decryption operation.
+	 *
+	 * Also, wait until all data is received before processing.
+	 */
+	return (aead_sufficient_data(ctx) && !ctx->more);
+}
+
+static void aead_put_sgl(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	struct aead_sg_list *sgl = &ctx->tsgl;
+	struct scatterlist *sg = sgl->sg;
+	unsigned int i;
+
+	for (i = 0; i < sgl->cur; i++) {
+		if (!sg_page(sg + i))
+			continue;
+
+		put_page(sg_page(sg + i));
+		sg_assign_page(sg + i, NULL);
+	}
+	sgl->cur = 0;
+	ctx->used = 0;
+	ctx->more = 0;
+	ctx->merge = 0;
+}
+
+static int aead_wait_for_wmem(struct sock *sk, unsigned flags)
+{
+	long timeout;
+	DEFINE_WAIT(wait);
+	int err = -ERESTARTSYS;
+
+	if (flags & MSG_DONTWAIT)
+		return -EAGAIN;
+
+	set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
+
+	for (;;) {
+		if (signal_pending(current))
+			break;
+		prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+		timeout = MAX_SCHEDULE_TIMEOUT;
+		if (sk_wait_event(sk, &timeout, aead_writable(sk))) {
+			err = 0;
+			break;
+		}
+	}
+	finish_wait(sk_sleep(sk), &wait);
+
+	return err;
+}
+
+static void aead_wmem_wakeup(struct sock *sk)
+{
+	struct socket_wq *wq;
+
+	if (!aead_writable(sk))
+		return;
+
+	rcu_read_lock();
+	wq = rcu_dereference(sk->sk_wq);
+	if (wq_has_sleeper(wq))
+		wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
+							   POLLRDNORM |
+							   POLLRDBAND);
+	sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
+	rcu_read_unlock();
+}
+
+static int aead_wait_for_data(struct sock *sk, unsigned flags)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	long timeout;
+	DEFINE_WAIT(wait);
+	int err = -ERESTARTSYS;
+
+	if (flags & MSG_DONTWAIT) {
+		return -EAGAIN;
+	}
+
+	set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+	for (;;) {
+		if (signal_pending(current))
+			break;
+		prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+		timeout = MAX_SCHEDULE_TIMEOUT;
+		if (sk_wait_event(sk, &timeout, aead_readable(ctx))) {
+			err = 0;
+			break;
+		}
+	}
+	finish_wait(sk_sleep(sk), &wait);
+
+	clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+	return err;
+}
+
+static void aead_data_wakeup(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	struct socket_wq *wq;
+
+	if (!aead_readable(ctx))
+		return;
+
+	rcu_read_lock();
+	wq = rcu_dereference(sk->sk_wq);
+	if (wq_has_sleeper(wq))
+		wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
+							   POLLRDNORM |
+							   POLLRDBAND);
+	sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
+	rcu_read_unlock();
+}
+
+static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
+		        struct msghdr *msg, size_t size)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	unsigned ivsize =
+		crypto_aead_ivsize(crypto_aead_reqtfm(&ctx->aead_req));
+	struct aead_sg_list *sgl = &ctx->tsgl;
+	struct af_alg_control con = {};
+	long copied = 0;
+	bool enc = 0;
+	bool init = 0;
+	int err = -EINVAL;
+
+	if (msg->msg_controllen) {
+		err = af_alg_cmsg_send(msg, &con);
+		if (err)
+			return err;
+
+		init = 1;
+		switch (con.op) {
+		case ALG_OP_ENCRYPT:
+			enc = 1;
+			break;
+		case ALG_OP_DECRYPT:
+			enc = 0;
+			break;
+		default:
+			return -EINVAL;
+		}
+
+		if (con.iv && con.iv->ivlen != ivsize)
+			return -EINVAL;
+
+		if (!con.aead_assoclen)
+			return -EINVAL;
+
+		/* aead_recvmsg limits the maximum AD size to one page */
+		if (con.aead_assoclen > PAGE_SIZE)
+			return -E2BIG;
+	}
+
+	lock_sock(sk);
+	if (!ctx->more && ctx->used)
+		goto unlock;
+
+	if (init) {
+		ctx->enc = enc;
+		if (con.iv)
+			memcpy(ctx->iv, con.iv->iv, ivsize);
+
+		ctx->aead_assoclen = con.aead_assoclen;
+	}
+
+	while (size) {
+		unsigned long len = size;
+		struct scatterlist *sg = NULL;
+
+		if (ctx->merge) {
+			sg = sgl->sg + sgl->cur - 1;
+			len = min_t(unsigned long, len,
+				    PAGE_SIZE - sg->offset - sg->length);
+			err = memcpy_fromiovec(page_address(sg_page(sg)) +
+					       sg->offset + sg->length,
+					       msg->msg_iov, len);
+			if (err)
+				goto unlock;
+
+			sg->length += len;
+			ctx->merge = (sg->offset + sg->length) &
+				     (PAGE_SIZE - 1);
+
+			ctx->used += len;
+			copied += len;
+			size -= len;
+		}
+
+		if (!aead_writable(sk)) {
+			/*
+			 * If there is more data to be expected, but we cannot
+			 * write more data, forcefully define that we do not
+			 * expect more data to invoke the AEAD operation. This
+			 * prevents a deadlock in user space.
+			 */
+			ctx->more = 0;
+			err = aead_wait_for_wmem(sk, msg->msg_flags);
+			if (err)
+				goto unlock;
+		}
+
+		len = min_t(unsigned long, size, aead_sndbuf(sk));
+		while (len && sgl->cur < ALG_MAX_PAGES) {
+			int plen = 0;
+
+			sg = sgl->sg + sgl->cur;
+			plen = min_t(int, len, PAGE_SIZE);
+
+			if (sgl->cur >= ALG_MAX_PAGES) {
+				err = -E2BIG;
+				goto unlock;
+			}
+
+			sg_assign_page(sg, alloc_page(GFP_KERNEL));
+			err = -ENOMEM;
+			if (!sg_page(sg))
+				goto unlock;
+
+			err = memcpy_fromiovec(page_address(sg_page(sg)),
+					       msg->msg_iov, plen);
+			if (err) {
+				__free_page(sg_page(sg));
+				sg_assign_page(sg, NULL);
+				goto unlock;
+			}
+
+			sg->length = plen;
+			len -= plen;
+			ctx->used += plen;
+			copied += plen;
+			sgl->cur++;
+			size -= plen;
+			ctx->merge = plen & (PAGE_SIZE - 1);
+		}
+	}
+
+	err = 0;
+
+	ctx->more = msg->msg_flags & MSG_MORE;
+
+unlock:
+	aead_data_wakeup(sk);
+	release_sock(sk);
+
+	return copied ?: err;
+}
+
+static ssize_t aead_sendpage(struct socket *sock, struct page *page,
+			     int offset, size_t size, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	struct aead_sg_list *sgl = &ctx->tsgl;
+	int err = -EINVAL;
+
+	if (flags & MSG_SENDPAGE_NOTLAST)
+		flags |= MSG_MORE;
+
+	if (sgl->cur >= ALG_MAX_PAGES)
+		return -E2BIG;
+
+	lock_sock(sk);
+	if (!ctx->more && ctx->used)
+		goto unlock;
+
+	if (!size)
+		goto done;
+
+	if (!aead_writable(sk)) {
+		/* see aead_sendmsg why more is set to 0 */
+		ctx->more = 0;
+		err = aead_wait_for_wmem(sk, flags);
+		if (err)
+			goto unlock;
+	}
+
+	ctx->merge = 0;
+
+	get_page(page);
+	sg_set_page(sgl->sg + sgl->cur, page, size, offset);
+	sgl->cur++;
+	ctx->used += size;
+
+	err = 0;
+
+done:
+	ctx->more = flags & MSG_MORE;
+
+unlock:
+	aead_data_wakeup(sk);
+	release_sock(sk);
+
+	return err ?: size;
+}
+
+static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
+			    struct msghdr *msg, size_t ignored, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	unsigned bs = crypto_aead_blocksize(crypto_aead_reqtfm(&ctx->aead_req));
+	unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx->aead_req));
+	struct aead_sg_list *sgl = &ctx->tsgl;
+	struct scatterlist *sg = sgl->sg;
+	struct scatterlist assoc;
+	size_t assoclen = 0;
+	unsigned int i = 0;
+	int err = -EAGAIN;
+	unsigned long used = 0;
+	unsigned long outlen = 0;
+
+	/*
+	 * Require exactly one IOV block as the AEAD operation is a one shot
+	 * due to the authentication tag.
+	 */
+	if (msg->msg_iovlen != 1)
+		return -ENOMSG;
+
+	lock_sock(sk);
+	/*
+	* AEAD memory structure: For encryption, the tag is appended to the
+	* ciphertext which implies that the memory allocated for the ciphertext
+	* must be increased by the tag length. For decryption, the tag
+	* is expected to be concatenated to the ciphertext. The plaintext
+	* therefore has a memory size of the ciphertext minus the tag length.
+	*
+	* The memory structure for cipher operation has the following
+	* structure:
+	*	AEAD encryption input:  assoc data || plaintext
+	*	AEAD encryption output: cipherntext || auth tag
+	*	AEAD decryption input:  assoc data || ciphertext || auth tag
+	*	AEAD decryption output: plaintext
+	*/
+
+	if (!aead_readable(ctx)) {
+		err = aead_wait_for_data(sk, flags);
+		if (err)
+			goto unlock;
+	}
+
+	used = ctx->used;
+
+	err = -ENOMEM;
+	if (!aead_sufficient_data(ctx))
+		goto unlock;
+	/*
+	 * The cipher operation input data is reduced by the associated data
+	 * length as this data is processed separately later on.
+	 */
+	used -= ctx->aead_assoclen;
+
+	if (ctx->enc) {
+		/* round up output buffer to multiple of block size */
+		outlen = ((used + bs - 1) / bs * bs);
+		/* add the size needed for the auth tag to be created */
+		outlen += as;
+	} else {
+		/* output data size is input without the authentication tag */
+		outlen = used - as;
+		/* round up output buffer to multiple of block size */
+		outlen = ((outlen + bs - 1) / bs * bs);
+	}
+
+	/* ensure output buffer is sufficiently large */
+	if (msg->msg_iov->iov_len < outlen)
+		goto unlock;
+
+	outlen = af_alg_make_sg(&ctx->rsgl, msg->msg_iov->iov_base, outlen, 1);
+	err = outlen;
+	if (err < 0)
+		goto unlock;
+
+	err = -EINVAL;
+	/*
+	 * first chunk of input is AD -- one scatterlist entry is one page,
+	 * and we process only one scatterlist, the maximum size of AD is
+	 * one page
+	 */
+	sg_init_table(&assoc, 1);
+	sg_set_page(&assoc, sg_page(sg), ctx->aead_assoclen, sg->offset);
+	aead_request_set_assoc(&ctx->aead_req, &assoc, ctx->aead_assoclen);
+
+	/* point sg to cipher/plaintext start */
+	assoclen = ctx->aead_assoclen;
+	for(i = 0; i < ctx->tsgl.cur; i++) {
+		sg = sgl->sg + i;
+		if (sg->length <= assoclen) {
+			assoclen -= sg->length;
+			if (i >= ctx->tsgl.cur)
+				goto unlock;
+		} else {
+			sg->length -= assoclen;
+			sg->offset += assoclen;
+			break;
+		}
+	}
+
+	aead_request_set_crypt(&ctx->aead_req, sg, ctx->rsgl.sg, used, ctx->iv);
+
+	err = af_alg_wait_for_completion(ctx->enc ?
+					 crypto_aead_encrypt(&ctx->aead_req) :
+					 crypto_aead_decrypt(&ctx->aead_req),
+					 &ctx->completion);
+
+	af_alg_free_sg(&ctx->rsgl);
+
+	if (err)
+		goto unlock;
+
+	aead_put_sgl(sk);
+
+	err = 0;
+
+unlock:
+	aead_wmem_wakeup(sk);
+	release_sock(sk);
+
+	return err ? err : outlen;
+}
+
+static unsigned int aead_poll(struct file *file, struct socket *sock,
+				  poll_table *wait)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	unsigned int mask;
+
+	sock_poll_wait(file, sk_sleep(sk), wait);
+	mask = 0;
+
+	if (aead_readable(ctx))
+		mask |= POLLIN | POLLRDNORM;
+
+	if (aead_writable(sk))
+		mask |= POLLOUT | POLLWRNORM | POLLWRBAND;
+
+	return mask;
+}
+
+static struct proto_ops algif_aead_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,
+	.accept		=	sock_no_accept,
+	.setsockopt	=	sock_no_setsockopt,
+
+	.release	=	af_alg_release,
+	.sendmsg	=	aead_sendmsg,
+	.sendpage	=	aead_sendpage,
+	.recvmsg	=	aead_recvmsg,
+	.poll		=	aead_poll,
+};
+
+static void *aead_bind(const char *name, u32 type, u32 mask)
+{
+	return crypto_alloc_aead(name, type, mask);
+}
+
+static void aead_release(void *private)
+{
+	crypto_free_aead(private);
+}
+
+static int aead_setauthsize(void *private, unsigned int authsize)
+{
+	return crypto_aead_setauthsize(private, authsize);
+}
+
+static int aead_setkey(void *private, const u8 *key, unsigned int keylen)
+{
+	return crypto_aead_setkey(private, key, keylen);
+}
+
+static void aead_sock_destruct(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct aead_ctx *ctx = ask->private;
+	unsigned int ivlen = crypto_aead_ivsize(
+				crypto_aead_reqtfm(&ctx->aead_req));
+
+	aead_put_sgl(sk);
+	sock_kzfree_s(sk, ctx->iv, ivlen);
+	sock_kfree_s(sk, ctx, ctx->len);
+	af_alg_release_parent(sk);
+}
+
+static int aead_accept_parent(void *private, struct sock *sk)
+{
+	struct aead_ctx *ctx;
+	struct alg_sock *ask = alg_sk(sk);
+	unsigned int len = sizeof(*ctx) + crypto_aead_reqsize(private);
+	unsigned int ivlen = crypto_aead_ivsize(private);
+
+	ctx = sock_kmalloc(sk, len, GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+	memset(ctx, 0, len);
+
+	ctx->iv = sock_kmalloc(sk, ivlen, GFP_KERNEL);
+	if (!ctx->iv) {
+		sock_kfree_s(sk, ctx, len);
+		return -ENOMEM;
+	}
+	memset(ctx->iv, 0, ivlen);
+
+	ctx->len = len;
+	ctx->used = 0;
+	ctx->more = 0;
+	ctx->merge = 0;
+	ctx->enc = 0;
+	ctx->tsgl.cur = 0;
+	ctx->aead_assoclen = 0;
+	af_alg_init_completion(&ctx->completion);
+	sg_init_table(ctx->tsgl.sg, ALG_MAX_PAGES);
+
+	ask->private = ctx;
+
+	aead_request_set_tfm(&ctx->aead_req, private);
+	aead_request_set_callback(&ctx->aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+				  af_alg_complete, &ctx->completion);
+
+	sk->sk_destruct = aead_sock_destruct;
+
+	return 0;
+}
+
+static const struct af_alg_type algif_type_aead = {
+	.bind		=	aead_bind,
+	.release	=	aead_release,
+	.setkey		=	aead_setkey,
+	.setauthsize	=	aead_setauthsize,
+	.accept		=	aead_accept_parent,
+	.ops		=	&algif_aead_ops,
+	.name		=	"aead",
+	.owner		=	THIS_MODULE
+};
+
+static int __init algif_aead_init(void)
+{
+	return af_alg_register_type(&algif_type_aead);
+}
+
+static void __exit algif_aead_exit(void)
+{
+	int err = af_alg_unregister_type(&algif_type_aead);
+	BUG_ON(err);
+}
+
+module_init(algif_aead_init);
+module_exit(algif_aead_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
+MODULE_DESCRIPTION("AEAD kernel crypto API user space interface");
-- 
2.1.0

[PATCH v5 4/8] crypto: AF_ALG: enable AEAD interface compilation

[Stephan Mueller]

Enable compilation of the AEAD AF_ALG support and provide a Kconfig
option to compile the AEAD AF_ALG support.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/Kconfig  | 9 +++++++++
 crypto/Makefile | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 87bbc9c..0b2affc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1505,6 +1505,15 @@ config CRYPTO_USER_API_SKCIPHER
 	  This option enables the user-spaces interface for symmetric
 	  key cipher algorithms.
 
+config CRYPTO_USER_API_AEAD
+	tristate "User-space interface for AEAD cipher algorithms"
+	depends on NET
+	select CRYPTO_AEAD
+	select CRYPTO_USER_API
+	help
+	  This option enables the user-spaces interface for AEAD
+	  cipher algorithms.
+
 config CRYPTO_HASH_INFO
 	bool
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 1445b91..593fd3c 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -99,6 +99,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_AEAD) += algif_aead.o
 
 #
 # generic algorithms and the async_tx api
-- 
2.1.0

[PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG

[Stephan Mueller]

Allow user space to seed / reset the RNG via a setsockopt.

This patch reuses alg_setkey to copy data into the kernel. The
alg_setkey is now used for two mechanisms: setkey and seeding.
The function is extended by the providing the function pointer
to the function handling the copied data.

As the alg_setkey is now usable for more than just setkey, it is renamed
to alg_setop.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/af_alg.c             | 29 +++++++++++++++++++----------
 include/crypto/if_alg.h     |  1 +
 include/uapi/linux/if_alg.h |  1 +
 3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 547c369..d1eb1e9 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -169,26 +169,27 @@ static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 	return 0;
 }
 
-static int alg_setkey(struct sock *sk, char __user *ukey,
-		      unsigned int keylen)
+static int alg_setop(struct sock *sk, char __user *udata,
+		      unsigned int datalen,
+		      int (*handler)(void *private, const u8 *data,
+				     unsigned int datalen))
 {
 	struct alg_sock *ask = alg_sk(sk);
-	const struct af_alg_type *type = ask->type;
-	u8 *key;
+	u8 *data;
 	int err;
 
-	key = sock_kmalloc(sk, keylen, GFP_KERNEL);
-	if (!key)
+	data = sock_kmalloc(sk, datalen, GFP_KERNEL);
+	if (!data)
 		return -ENOMEM;
 
 	err = -EFAULT;
-	if (copy_from_user(key, ukey, keylen))
+	if (copy_from_user(data, udata, datalen))
 		goto out;
 
-	err = type->setkey(ask->private, key, keylen);
+	err = handler(ask->private, data, datalen);
 
 out:
-	sock_kfree_s(sk, key, keylen);
+	sock_kfree_s(sk, data, datalen);
 
 	return err;
 }
@@ -214,7 +215,7 @@ static int alg_setsockopt(struct socket *sock, int level, int optname,
 		if (!type->setkey)
 			goto unlock;
 
-		err = alg_setkey(sk, optval, optlen);
+		err = alg_setop(sk, optval, optlen, type->setkey);
 		break;
 	case ALG_SET_AEAD_AUTHSIZE:
 		if (sock->state == SS_CONNECTED)
@@ -222,6 +223,14 @@ static int alg_setsockopt(struct socket *sock, int level, int optname,
 		if (!type->setauthsize)
 			goto unlock;
 		err = type->setauthsize(ask->private, optlen);
+		break;
+	case ALG_SET_RNG_SEED:
+		if (sock->state == SS_CONNECTED)
+			goto unlock;
+		if (!type->setseed)
+			goto unlock;
+
+		err = alg_setop(sk, optval, optlen, type->setseed);
 	}
 
 unlock:
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 5c7b6c5..0808ed1 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -51,6 +51,7 @@ struct af_alg_type {
 	int (*setkey)(void *private, const u8 *key, unsigned int keylen);
 	int (*accept)(void *private, struct sock *sk);
 	int (*setauthsize)(void *private, unsigned int authsize);
+	int (*setseed)(void *private, const u8 *seed, unsigned int seedlen);
 
 	struct proto_ops *ops;
 	struct module *owner;
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index f2acd2f..973dcca 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -34,6 +34,7 @@ struct af_alg_iv {
 #define ALG_SET_OP			3
 #define ALG_SET_AEAD_ASSOCLEN		4
 #define ALG_SET_AEAD_AUTHSIZE		5
+#define ALG_SET_RNG_SEED		6
 
 /* Operations */
 #define ALG_OP_DECRYPT			0
-- 
2.1.0

[PATCH v5 6/8] crypto: AF_ALG: zeroize key / seed data

[Stephan Mueller]

alg_setop shall zeroize the sensitive data after use.

Signed-off-by: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
---
 crypto/af_alg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index d1eb1e9..836fa4a 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -189,7 +189,7 @@ static int alg_setop(struct sock *sk, char __user *udata,
 	err = handler(ask->private, data, datalen);
 
 out:
-	sock_kfree_s(sk, data, datalen);
+	sock_kzfree_s(sk, data, datalen);
 
 	return err;
 }
-- 
2.1.0

[PATCH v5 6/8] crypto: AF_ALG: zeroize key / seed data

[Stephan Mueller]

alg_setop shall zeroize the sensitive data after use.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/af_alg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index d1eb1e9..836fa4a 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -189,7 +189,7 @@ static int alg_setop(struct sock *sk, char __user *udata,
 	err = handler(ask->private, data, datalen);
 
 out:
-	sock_kfree_s(sk, data, datalen);
+	sock_kzfree_s(sk, data, datalen);
 
 	return err;
 }
-- 
2.1.0

[PATCH v5 7/8] crypto: AF_ALG: add random number generator support

[Stephan Mueller]

This patch adds the random number generator support for AF_ALG.

A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback handler for
recvmsg.

The following parameters provided with a recvmsg are processed by the
RNG callback handler:

        * sock - to resolve the RNG context data structure accessing the
          RNG instance private to the socket

        * len - this parameter allows userspace callers to specify how
          many random bytes the RNG shall produce and return. As the
          kernel context for the RNG allocates a buffer of 128 bytes to
          store random numbers before copying them to userspace, the len
          parameter is checked that it is not larger than 128. If a
          caller wants more random numbers, a new request for recvmsg
          shall be made.

The size of 128 bytes is chose because of the following considerations:

        * to increase the memory footprint of the kernel too much (note,
          that would be 128 bytes per open socket)

        * 128 is divisible by any typical cryptographic block size an
          RNG may have

        * A request for random numbers typically only shall supply small
          amount of data like for keys or IVs that should only require
          one invocation of the recvmsg function.

Note, during instantiation of the RNG, the code checks whether the RNG
implementation requires seeding. If so, the RNG is seeded with output
from get_random_bytes.

A fully working example using all aspects of the RNG interface is
provided at http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/algif_rng.c | 192 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 192 insertions(+)
 create mode 100644 crypto/algif_rng.c

diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 0000000..78856f8
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,192 @@
+/*
+ * algif_rng: User-space interface for random number generators
+ *
+ * This file provides the user-space API for random number generators.
+ *
+ * Copyright (C) 2014, Stephan Mueller <smueller@chronox.de>
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, and the entire permission notice in its entirety,
+ *    including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *    products derived from this software without specific prior
+ *    written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions.  (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+#include <linux/module.h>
+#include <crypto/rng.h>
+#include <linux/random.h>
+#include <crypto/if_alg.h>
+#include <linux/net.h>
+#include <net/sock.h>
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
+MODULE_DESCRIPTION("User-space interface for random number generators");
+
+struct rng_ctx {
+#define MAXSIZE 128
+	unsigned int len;
+	struct crypto_rng *drng;
+};
+
+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 err = -EFAULT;
+	int genlen = 0;
+	u8 result[MAXSIZE];
+
+	if (len == 0)
+		return 0;
+	if (len > MAXSIZE)
+		len = MAXSIZE;
+
+	/*
+	 * although not strictly needed, this is a precaution against coding
+	 * errors
+	 */
+	memset(result, 0, len);
+
+	/*
+	 * The enforcement of a proper seeding of an RNG is done within an
+	 * RNG implementation. Some RNGs (DRBG, krng) do not need specific
+	 * seeding as they automatically seed. The X9.31 DRNG will return
+	 * an error if it was not seeded properly.
+	 */
+	genlen = crypto_rng_get_bytes(ctx->drng, result, len);
+	if (genlen < 0)
+		return genlen;
+
+	err = memcpy_toiovec(msg->msg_iov, result, len);
+	memzero_explicit(result, genlen);
+
+	return err ? err : len;
+}
+
+static 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,
+	.accept		=	sock_no_accept,
+	.setsockopt	=	sock_no_setsockopt,
+	.poll		=	sock_no_poll,
+	.sendmsg	=	sock_no_sendmsg,
+	.sendpage	=	sock_no_sendpage,
+
+	.release	=	af_alg_release,
+	.recvmsg	=	rng_recvmsg,
+};
+
+static void *rng_bind(const char *name, u32 type, u32 mask)
+{
+	return crypto_alloc_rng(name, type, mask);
+}
+
+static void rng_release(void *private)
+{
+	crypto_free_rng(private);
+}
+
+static void rng_sock_destruct(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct rng_ctx *ctx = ask->private;
+
+	sock_kfree_s(sk, ctx, ctx->len);
+	af_alg_release_parent(sk);
+}
+
+static int rng_accept_parent(void *private, struct sock *sk)
+{
+	struct rng_ctx *ctx;
+	struct alg_sock *ask = alg_sk(sk);
+	unsigned int len = sizeof(*ctx);
+
+	ctx = sock_kmalloc(sk, len, GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->len = len;
+
+	/*
+	 * No seeding done at that point -- if multiple accepts are
+	 * done on one RNG instance, each resulting FD points to the same
+	 * state of the RNG.
+	 */
+
+	ctx->drng = private;
+	ask->private = ctx;
+	sk->sk_destruct = rng_sock_destruct;
+
+	return 0;
+}
+
+static int rng_setseed(void *private, const u8 *seed, unsigned int seedlen)
+{
+	/*
+	 * Check whether seedlen is of sufficient size is done in RNG
+	 * implementations.
+	 */
+	return crypto_rng_reset(private, (u8 *)seed, seedlen);
+}
+
+static const struct af_alg_type algif_type_rng = {
+	.bind		=	rng_bind,
+	.release	=	rng_release,
+	.accept		=	rng_accept_parent,
+	.setseed	=	rng_setseed,
+	.ops		=	&algif_rng_ops,
+	.name		=	"rng",
+	.owner		=	THIS_MODULE
+};
+
+static int __init rng_init(void)
+{
+	return af_alg_register_type(&algif_type_rng);
+}
+
+void __exit rng_exit(void)
+{
+	int err = af_alg_unregister_type(&algif_type_rng);
+	BUG_ON(err);
+}
+
+module_init(rng_init);
+module_exit(rng_exit);
-- 
2.1.0

[PATCH v5 8/8] crypto: AF_ALG: enable RNG interface compilation

[Stephan Mueller]

Enable compilation of the RNG AF_ALG support and provide a Kconfig
option to compile the RNG AF_ALG support.

Signed-off-by: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
---
 crypto/Kconfig  | 9 +++++++++
 crypto/Makefile | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 0b2affc..8e968dc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1514,6 +1514,15 @@ config CRYPTO_USER_API_AEAD
 	  This option enables the user-spaces interface for AEAD
 	  cipher algorithms.
 
+config CRYPTO_USER_API_RNG
+	tristate "User-space interface for random number generator algorithms"
+	depends on NET
+	select CRYPTO_RNG
+	select CRYPTO_USER_API
+	help
+	  This option enables the user-spaces interface for random
+	  number generator algorithms.
+
 config CRYPTO_HASH_INFO
 	bool
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 593fd3c..c109df5 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -100,6 +100,7 @@ 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_AEAD) += algif_aead.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
 
 #
 # generic algorithms and the async_tx api
-- 
2.1.0

[PATCH v5 8/8] crypto: AF_ALG: enable RNG interface compilation

[Stephan Mueller]

Enable compilation of the RNG AF_ALG support and provide a Kconfig
option to compile the RNG AF_ALG support.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/Kconfig  | 9 +++++++++
 crypto/Makefile | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 0b2affc..8e968dc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1514,6 +1514,15 @@ config CRYPTO_USER_API_AEAD
 	  This option enables the user-spaces interface for AEAD
 	  cipher algorithms.
 
+config CRYPTO_USER_API_RNG
+	tristate "User-space interface for random number generator algorithms"
+	depends on NET
+	select CRYPTO_RNG
+	select CRYPTO_USER_API
+	help
+	  This option enables the user-spaces interface for random
+	  number generator algorithms.
+
 config CRYPTO_HASH_INFO
 	bool
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 593fd3c..c109df5 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -100,6 +100,7 @@ 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_AEAD) += algif_aead.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
 
 #
 # generic algorithms and the async_tx api
-- 
2.1.0

Re: [PATCH v5 1/8] crypto: AF_ALG: add user space interface for AEAD

[Stephan Mueller]

Am Sonntag, 7. Dezember 2014, 23:21:09 schrieb Stephan Mueller:

Hi Herbert,

FYI: you mentioned that you applied that patch already. However, I do not see 
it in the cryptodev-2.6 tree. Therefore I resent it. In case it was applied, 
please disregard this patch.

> AEAD requires the caller to specify the following information separate
> from the data stream. This information allows the AEAD interface handler
> to identify the AAD, ciphertext/plaintext and the authentication tag:
> 
>         * Associated authentication data of arbitrary length and
>           length
> 
>         * Length of authentication tag for encryption
> 
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
>  crypto/af_alg.c             | 6 ++++++
>  include/crypto/if_alg.h     | 1 +
>  include/uapi/linux/if_alg.h | 2 ++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 6a3ad80..68ff113 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -421,6 +421,12 @@ int af_alg_cmsg_send(struct msghdr *msg, struct
> af_alg_control *con) con->op = *(u32 *)CMSG_DATA(cmsg);
>  			break;
> 
> +		case ALG_SET_AEAD_ASSOCLEN:
> +			if (cmsg->cmsg_len < CMSG_LEN(sizeof(u32)))
> +				return -EINVAL;
> +			con->aead_assoclen = *(u32 *)CMSG_DATA(cmsg);
> +			break;
> +
>  		default:
>  			return -EINVAL;
>  		}
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index d61c111..cd62bf4 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -42,6 +42,7 @@ struct af_alg_completion {
>  struct af_alg_control {
>  	struct af_alg_iv *iv;
>  	int op;
> +	unsigned int aead_assoclen;
>  };
> 
>  struct af_alg_type {
> diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
> index 0f9acce..f2acd2f 100644
> --- a/include/uapi/linux/if_alg.h
> +++ b/include/uapi/linux/if_alg.h
> @@ -32,6 +32,8 @@ struct af_alg_iv {
>  #define ALG_SET_KEY			1
>  #define ALG_SET_IV			2
>  #define ALG_SET_OP			3
> +#define ALG_SET_AEAD_ASSOCLEN		4
> +#define ALG_SET_AEAD_AUTHSIZE		5
> 
>  /* Operations */
>  #define ALG_OP_DECRYPT			0


-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Sun, Dec 07, 2014 at 11:22:30PM +0100, Stephan Mueller wrote:
>
> +static inline bool aead_sufficient_data(struct aead_ctx *ctx)
> +{
> +	unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx->aead_req));
> +
> +	return (ctx->used >= (ctx->aead_assoclen + ctx->enc ? : as ));

Is this supposed to be

	return (ctx->used >= (ctx->aead_assoclen + (ctx->enc ?: as)));

> +static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
> +			    struct msghdr *msg, size_t ignored, int flags)
> +{

...

> +	err = -ENOMEM;
> +	if (!aead_sufficient_data(ctx))
> +		goto unlock;

You should just block if there is insufficient input.

Cheers,
-- 
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

Re: [PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG

[Herbert Xu]

On Sun, Dec 07, 2014 at 11:23:48PM +0100, Stephan Mueller wrote:
> Allow user space to seed / reset the RNG via a setsockopt.
> 
> This patch reuses alg_setkey to copy data into the kernel. The
> alg_setkey is now used for two mechanisms: setkey and seeding.
> The function is extended by the providing the function pointer
> to the function handling the copied data.
> 
> As the alg_setkey is now usable for more than just setkey, it is renamed
> to alg_setop.

Just call it setkey, there is no harm in treating the seed as a key
is there?

In fact we should have done this from the very start.
crypto_rng_reset should be renamed crypto_rng_setkey.

Cheers,
-- 
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG

[Herbert Xu]

On Sun, Dec 07, 2014 at 11:23:48PM +0100, Stephan Mueller wrote:
> Allow user space to seed / reset the RNG via a setsockopt.
> 
> This patch reuses alg_setkey to copy data into the kernel. The
> alg_setkey is now used for two mechanisms: setkey and seeding.
> The function is extended by the providing the function pointer
> to the function handling the copied data.
> 
> As the alg_setkey is now usable for more than just setkey, it is renamed
> to alg_setop.

Just call it setkey, there is no harm in treating the seed as a key
is there?

In fact we should have done this from the very start.
crypto_rng_reset should be renamed crypto_rng_setkey.

Cheers,
-- 
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

Re: [PATCH v5 2/8] crypto: AF_ALG: add setsockopt for auth tag size

[Herbert Xu]

On Sun, Dec 07, 2014 at 11:21:42PM +0100, Stephan Mueller wrote:
> Use setsockopt on the tfm FD to provide the authentication tag size for
> an AEAD cipher. This is achieved by adding a callback function which is
> intended to be used by the AEAD AF_ALG implementation.
> 
> The optlen argument of the setsockopt specifies the authentication tag
> size to be used with the AEAD tfm.
> 
> Signed-off-by: Stephan Mueller <smueller@chronox.de>

Patch applied.
-- 
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

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Montag, 22. Dezember 2014, 22:23:41 schrieb Herbert Xu:

Hi Herbert,

> On Sun, Dec 07, 2014 at 11:22:30PM +0100, Stephan Mueller wrote:
> > +static inline bool aead_sufficient_data(struct aead_ctx *ctx)
> > +{
> > +	unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(&ctx-
>aead_req));
> > +
> > +	return (ctx->used >= (ctx->aead_assoclen + ctx->enc ? : as ));
> 
> Is this supposed to be
> 
> 	return (ctx->used >= (ctx->aead_assoclen + (ctx->enc ?: as)));

Thanks, will be fixed in the next iteration
> 
> > +static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
> > +			    struct msghdr *msg, size_t ignored, int flags)
> > +{
> 
> ...
> 
> > +	err = -ENOMEM;
> > +	if (!aead_sufficient_data(ctx))
> > +		goto unlock;
> 
> You should just block if there is insufficient input.
> 
I do not concur here due to the following:

- the check aead_readable() immediately before this check implements the 
blocking if we do not have sufficient data *and* more data is to be expected

- this very check for aead_sufficient_data() comes into play if the caller 
does not have more data (i.e. ctx->more is zero). In this case, more data is 
not to be expected and we cannot wait as this would be a deadlock in user 
space.

-- 
Ciao
Stephan

Re: [PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG

[Stephan Mueller]

Am Montag, 22. Dezember 2014, 22:27:30 schrieb Herbert Xu:

Hi Herbert,

> On Sun, Dec 07, 2014 at 11:23:48PM +0100, Stephan Mueller wrote:
> > Allow user space to seed / reset the RNG via a setsockopt.
> > 
> > This patch reuses alg_setkey to copy data into the kernel. The
> > alg_setkey is now used for two mechanisms: setkey and seeding.
> > The function is extended by the providing the function pointer
> > to the function handling the copied data.
> > 
> > As the alg_setkey is now usable for more than just setkey, it is renamed
> > to alg_setop.
> 
> Just call it setkey, there is no harm in treating the seed as a key
> is there?
> 
> In fact we should have done this from the very start.
> crypto_rng_reset should be renamed crypto_rng_setkey.

Ok, that means I will drop this patch entirely and wire up the reseeding 
function in algif_rng.c with setkey.
> 
> Cheers,


-- 
Ciao
Stephan

Re: [PATCH v5 5/8] crypto: AF_ALG: add user space interface for RNG

[Stephan Mueller]

Am Montag, 22. Dezember 2014, 22:27:30 schrieb Herbert Xu:

Hi Herbert,

> On Sun, Dec 07, 2014 at 11:23:48PM +0100, Stephan Mueller wrote:
> > Allow user space to seed / reset the RNG via a setsockopt.
> > 
> > This patch reuses alg_setkey to copy data into the kernel. The
> > alg_setkey is now used for two mechanisms: setkey and seeding.
> > The function is extended by the providing the function pointer
> > to the function handling the copied data.
> > 
> > As the alg_setkey is now usable for more than just setkey, it is renamed
> > to alg_setop.
> 
> Just call it setkey, there is no harm in treating the seed as a key
> is there?
> 
> In fact we should have done this from the very start.
> crypto_rng_reset should be renamed crypto_rng_setkey.

Ok, that means I will drop this patch entirely and wire up the reseeding 
function in algif_rng.c with setkey.
> 
> Cheers,


-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
>
> - the check aead_readable() immediately before this check implements the 
> blocking if we do not have sufficient data *and* more data is to be expected

Good point.

In fact AEAD is rather awkward because you need to do everything
in one go.  Perhaps we could adapt our kernel interface to allow
partial AEAD operations?

I want to be very careful before we pin down our user-space
interface since that's something that we cannot easily change
while the kernel interface can be modified at any time.

Thanks,
-- 
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
>
> - the check aead_readable() immediately before this check implements the 
> blocking if we do not have sufficient data *and* more data is to be expected

Good point.

In fact AEAD is rather awkward because you need to do everything
in one go.  Perhaps we could adapt our kernel interface to allow
partial AEAD operations?

I want to be very careful before we pin down our user-space
interface since that's something that we cannot easily change
while the kernel interface can be modified at any time.

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

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
> > - the check aead_readable() immediately before this check implements the
> > blocking if we do not have sufficient data *and* more data is to be
> > expected
> Good point.
> 
> In fact AEAD is rather awkward because you need to do everything
> in one go.  Perhaps we could adapt our kernel interface to allow
> partial AEAD operations?


I am not sure what you are referring to. The invocation does not need to be in 
one go. You can have arbitrary number of sendmsg calls. But all input data 
needs to be supplied before you call recvmsg.

Please see my test code that implements the following call sequence using the 
libkcapi wrapper API calls where I dissect the data to be sent to the kernel 
for testing purposes:

if (cavs_test->enc) {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_enc(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with last call */
                iov.iov_base = cavs_test->pt;
                iov.iov_len = cavs_test->ptlen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        } else {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_dec(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with intermediary call */
                iov.iov_base = cavs_test->ct;
                iov.iov_len = cavs_test->ctlen;
                ret = kcapi_aead_stream_update(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending update buffer failed\n");
                        goto out;
                }
                /* send tag with last send call */
                iov.iov_base = cavs_test->tag;
                iov.iov_len = cavs_test->taglen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        }

Every call to kcapi_aead_stream_init_dec / kcapi_aead_stream_update / 
kcapi_aead_stream_update_last invokes one sendmsg syscall.

In essence, kcapi_aead_stream_update can be invoked with every byte you want 
to add to the message stream. This "stream" API of libkcapi is logially 
equivalent to the init/update/final of message digests.
> 
> I want to be very careful before we pin down our user-space
> interface since that's something that we cannot easily change
> while the kernel interface can be modified at any time.

I am fully with you and try to patiently present solutions.
> 
> Thanks,


-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 09:14:43AM +0100, Stephan Mueller wrote:
> > - the check aead_readable() immediately before this check implements the
> > blocking if we do not have sufficient data *and* more data is to be
> > expected
> Good point.
> 
> In fact AEAD is rather awkward because you need to do everything
> in one go.  Perhaps we could adapt our kernel interface to allow
> partial AEAD operations?


I am not sure what you are referring to. The invocation does not need to be in 
one go. You can have arbitrary number of sendmsg calls. But all input data 
needs to be supplied before you call recvmsg.

Please see my test code that implements the following call sequence using the 
libkcapi wrapper API calls where I dissect the data to be sent to the kernel 
for testing purposes:

if (cavs_test->enc) {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_enc(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with last call */
                iov.iov_base = cavs_test->pt;
                iov.iov_len = cavs_test->ptlen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        } else {
                /* send assoc with init call */
                ret = kcapi_aead_stream_init_dec(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Initialization of cipher buffer failed\n");
                        goto out;
                }
                /* send plaintext with intermediary call */
                iov.iov_base = cavs_test->ct;
                iov.iov_len = cavs_test->ctlen;
                ret = kcapi_aead_stream_update(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending update buffer failed\n");
                        goto out;
                }
                /* send tag with last send call */
                iov.iov_base = cavs_test->tag;
                iov.iov_len = cavs_test->taglen;
                ret = kcapi_aead_stream_update_last(&handle, &iov, 1);
                if (0 > ret) {
                        printf("Sending last update buffer failed\n");
                        goto out;
                }
                ret = kcapi_aead_stream_op(&handle, &outiov, 1);
        }

Every call to kcapi_aead_stream_init_dec / kcapi_aead_stream_update / 
kcapi_aead_stream_update_last invokes one sendmsg syscall.

In essence, kcapi_aead_stream_update can be invoked with every byte you want 
to add to the message stream. This "stream" API of libkcapi is logially 
equivalent to the init/update/final of message digests.
> 
> I want to be very careful before we pin down our user-space
> interface since that's something that we cannot easily change
> while the kernel interface can be modified at any time.

I am fully with you and try to patiently present solutions.
> 
> Thanks,


-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
>
> > In fact AEAD is rather awkward because you need to do everything
> > in one go.  Perhaps we could adapt our kernel interface to allow
> > partial AEAD operations?
> 
> 
> I am not sure what you are referring to. The invocation does not need to be in 
> one go. You can have arbitrary number of sendmsg calls. But all input data 
> needs to be supplied before you call recvmsg.

What I mean is that unlike skcipher we cannot precede until we
have the complete input.  So you cannot begin recvmsg until all
input has been sent.

Cheers,
-- 
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
>
> > In fact AEAD is rather awkward because you need to do everything
> > in one go.  Perhaps we could adapt our kernel interface to allow
> > partial AEAD operations?
> 
> 
> I am not sure what you are referring to. The invocation does not need to be in 
> one go. You can have arbitrary number of sendmsg calls. But all input data 
> needs to be supplied before you call recvmsg.

What I mean is that unlike skcipher we cannot precede until we
have the complete input.  So you cannot begin recvmsg until all
input has been sent.

Cheers,
-- 
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

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Mittwoch, 24. Dezember 2014, 07:24:01 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> > Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
> > > In fact AEAD is rather awkward because you need to do everything
> > > in one go.  Perhaps we could adapt our kernel interface to allow
> > > partial AEAD operations?
> > 
> > I am not sure what you are referring to. The invocation does not need to
> > be in one go. You can have arbitrary number of sendmsg calls. But all
> > input data needs to be supplied before you call recvmsg.
> 
> What I mean is that unlike skcipher we cannot precede until we
> have the complete input.  So you cannot begin recvmsg until all
> input has been sent.

That is right, but isn't that the nature of AEAD ciphers in general? Even if 
you are in the kernel, you need to have all scatter lists together for one 
invocation of the AEAD cipher.

In case of a threaded application, the recvmsg does not start until all data 
is in, marked with the missing MSG_MORE -- see aead_readable.

All we can do is allow the user to use multiple system calls to collect all 
data before the AEAD operation takes place.

Or do you see another way on how to invoke the AEAD operation in a different 
manner?

The only item that I see that could be made better is the output side: 
currently the code allows only one and exactly one iovec to point to the 
output buffer. I would like to allow multiple iovec buffers that are filled 
with the output of one invocation of the AEAD operation. However, to avoid 
making a kernel-internal scratch buffer, I would need to somehow link the 
kernel-internal scatter lists with the iovec buffers. That only works when 
walking the iovec lists first and call af_alg_make_sg with every iovec entry 
and create the kernel-internal scatterlist representation. That is followed by 
the AEAD operation on the scatterlist.

If we agree on walking the iovec list first, then the question arises how many 
iovec list entries we allow at max. Is 16 entries a sensible value?

-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Mittwoch, 24. Dezember 2014, 07:24:01 schrieb Herbert Xu:

Hi Herbert,

> On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> > Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
> > > In fact AEAD is rather awkward because you need to do everything
> > > in one go.  Perhaps we could adapt our kernel interface to allow
> > > partial AEAD operations?
> > 
> > I am not sure what you are referring to. The invocation does not need to
> > be in one go. You can have arbitrary number of sendmsg calls. But all
> > input data needs to be supplied before you call recvmsg.
> 
> What I mean is that unlike skcipher we cannot precede until we
> have the complete input.  So you cannot begin recvmsg until all
> input has been sent.

That is right, but isn't that the nature of AEAD ciphers in general? Even if 
you are in the kernel, you need to have all scatter lists together for one 
invocation of the AEAD cipher.

In case of a threaded application, the recvmsg does not start until all data 
is in, marked with the missing MSG_MORE -- see aead_readable.

All we can do is allow the user to use multiple system calls to collect all 
data before the AEAD operation takes place.

Or do you see another way on how to invoke the AEAD operation in a different 
manner?

The only item that I see that could be made better is the output side: 
currently the code allows only one and exactly one iovec to point to the 
output buffer. I would like to allow multiple iovec buffers that are filled 
with the output of one invocation of the AEAD operation. However, to avoid 
making a kernel-internal scratch buffer, I would need to somehow link the 
kernel-internal scatter lists with the iovec buffers. That only works when 
walking the iovec lists first and call af_alg_make_sg with every iovec entry 
and create the kernel-internal scatterlist representation. That is followed by 
the AEAD operation on the scatterlist.

If we agree on walking the iovec list first, then the question arises how many 
iovec list entries we allow at max. Is 16 entries a sensible value?

-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Mittwoch, 24. Dezember 2014, 09:54:33 schrieb Stephan Mueller:

Hi Stephan,

> Am Mittwoch, 24. Dezember 2014, 07:24:01 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> > > Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
> > > > In fact AEAD is rather awkward because you need to do everything
> > > > in one go.  Perhaps we could adapt our kernel interface to allow
> > > > partial AEAD operations?
> > > 
> > > I am not sure what you are referring to. The invocation does not need to
> > > be in one go. You can have arbitrary number of sendmsg calls. But all
> > > input data needs to be supplied before you call recvmsg.
> > 
> > What I mean is that unlike skcipher we cannot precede until we
> > have the complete input.  So you cannot begin recvmsg until all
> > input has been sent.
> 
> That is right, but isn't that the nature of AEAD ciphers in general? Even if
> you are in the kernel, you need to have all scatter lists together for one
> invocation of the AEAD cipher.
> 
> In case of a threaded application, the recvmsg does not start until all data
> is in, marked with the missing MSG_MORE -- see aead_readable.
> 
> All we can do is allow the user to use multiple system calls to collect all
> data before the AEAD operation takes place.
> 
> Or do you see another way on how to invoke the AEAD operation in a different
> manner?
> 
> The only item that I see that could be made better is the output side:
> currently the code allows only one and exactly one iovec to point to the
> output buffer. I would like to allow multiple iovec buffers that are filled
> with the output of one invocation of the AEAD operation. However, to avoid
> making a kernel-internal scratch buffer, I would need to somehow link the
> kernel-internal scatter lists with the iovec buffers. That only works when
> walking the iovec lists first and call af_alg_make_sg with every iovec entry
> and create the kernel-internal scatterlist representation. That is followed
> by the AEAD operation on the scatterlist.
> 
> If we agree on walking the iovec list first, then the question arises how
> many iovec list entries we allow at max. Is 16 entries a sensible value?

I would be now ready with a new release of the AEAD and RNG interface patches 
against the current code base (including the iov_iter update). Though, I would 
like to get your answer regarding your concerns.

Thanks.

-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

Am Mittwoch, 24. Dezember 2014, 09:54:33 schrieb Stephan Mueller:

Hi Stephan,

> Am Mittwoch, 24. Dezember 2014, 07:24:01 schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Tue, Dec 23, 2014 at 03:52:27PM +0100, Stephan Mueller wrote:
> > > Am Dienstag, 23. Dezember 2014, 22:56:26 schrieb Herbert Xu:
> > > > In fact AEAD is rather awkward because you need to do everything
> > > > in one go.  Perhaps we could adapt our kernel interface to allow
> > > > partial AEAD operations?
> > > 
> > > I am not sure what you are referring to. The invocation does not need to
> > > be in one go. You can have arbitrary number of sendmsg calls. But all
> > > input data needs to be supplied before you call recvmsg.
> > 
> > What I mean is that unlike skcipher we cannot precede until we
> > have the complete input.  So you cannot begin recvmsg until all
> > input has been sent.
> 
> That is right, but isn't that the nature of AEAD ciphers in general? Even if
> you are in the kernel, you need to have all scatter lists together for one
> invocation of the AEAD cipher.
> 
> In case of a threaded application, the recvmsg does not start until all data
> is in, marked with the missing MSG_MORE -- see aead_readable.
> 
> All we can do is allow the user to use multiple system calls to collect all
> data before the AEAD operation takes place.
> 
> Or do you see another way on how to invoke the AEAD operation in a different
> manner?
> 
> The only item that I see that could be made better is the output side:
> currently the code allows only one and exactly one iovec to point to the
> output buffer. I would like to allow multiple iovec buffers that are filled
> with the output of one invocation of the AEAD operation. However, to avoid
> making a kernel-internal scratch buffer, I would need to somehow link the
> kernel-internal scatter lists with the iovec buffers. That only works when
> walking the iovec lists first and call af_alg_make_sg with every iovec entry
> and create the kernel-internal scatterlist representation. That is followed
> by the AEAD operation on the scatterlist.
> 
> If we agree on walking the iovec list first, then the question arises how
> many iovec list entries we allow at max. Is 16 entries a sensible value?

I would be now ready with a new release of the AEAD and RNG interface patches 
against the current code base (including the iov_iter update). Though, I would 
like to get your answer regarding your concerns.

Thanks.

-- 
Ciao
Stephan

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Wed, Dec 24, 2014 at 09:54:33AM +0100, Stephan Mueller wrote:
> 
> That is right, but isn't that the nature of AEAD ciphers in general? Even if 
> you are in the kernel, you need to have all scatter lists together for one 
> invocation of the AEAD cipher.

It's actually only the nature of certain algorithms like CCM which
requires the total length to start the operation.  Most AEAD
algorithms can be implemented in a way that allows piecemeal
operation.  However, as the only users of AEAD is IPsec, it's
probably not worth adding more complexity for now.

So let's proceed with your current solution.

Thanks,
-- 
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v5 3/8] crypto: AF_ALG: add AEAD support

[Herbert Xu]

On Wed, Dec 24, 2014 at 09:54:33AM +0100, Stephan Mueller wrote:
> 
> That is right, but isn't that the nature of AEAD ciphers in general? Even if 
> you are in the kernel, you need to have all scatter lists together for one 
> invocation of the AEAD cipher.

It's actually only the nature of certain algorithms like CCM which
requires the total length to start the operation.  Most AEAD
algorithms can be implemented in a way that allows piecemeal
operation.  However, as the only users of AEAD is IPsec, it's
probably not worth adding more complexity for now.

So let's proceed with your current solution.

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