Skip to contentSkip to conversation

Parallel IPsec v4

RFC PATCH In review Steffen Klassert 2 participants 23 messages Jun 8, 2009 – Jun 29, 2009

Subsystems (3)
lore
Share & tools
lore

Steffen Klassert

author maintainer
#0 lore raw

cover Parallel IPsec v4

This patchset adds the 'pcrypt' parallel crypto template. With this template it is possible to process the crypto requests of a transform in parallel without getting request reorder. This is in particular interesting for IPsec.

The parallel crypto template is based on a generic parallelization/serialization method. This method uses the remote softirq invocation infrastructure for parallelization and serialization. With this method data objects can be processed in parallel, starting at some given point.
After doing some expensive operations in parallel, it is possible to serialize again. The parallelized data objects return after serialization in the order as they were before the parallelization. In the case of IPsec, this makes it possible to run the expensive parts in parallel without getting packet reordering.

Changes from v3:

- The generic aead wrapper is dropped.

- tcrypt is extended to test algorithms by name. So it is possible to instantiate pcrypt by doing e.g.:
modprobe tcrypt alg="pcrypt(authenc(hmac(sha1),cbc(aes)))" type=3

Changes from v2:

- The xfrm netlink configuration code is dropped,
this will be an extra patchset.

- Add generic aead wrapper interface to be able to wrap an aead algorithm with an arbitrary crypto template.

- Convert pcrypt to use the generic aead wrapper.

- Add support for aead algorithms to eseqiv.

- Add support for the pcrypt aead wrapper to authenc. It's now possible to choose for pcrypt as the default authenc wrapper with a module parameter.

- Patchset applies to linux-2.6 git current.

Changes from v1:

- cpu_chainiv is dropped, pcrypt uses eseqiv as it's IV generator now.

- Add a xfrm netlink message to be able to choose for pcrypt from userspace.

- Use pcrypt just if it is selected from userspace.

- Patchset applies to 2.6.30-rc3

Steffen

author maintainer
#1 lore raw

RFC PATCH 1/5 padata: generic interface for parallel processing

This patch introduces an interface to process data objects in parallel. On request it is possible to serialize again. The parallelized objects return after serialization in the same order as they were before the parallelization.

---
 include/linux/interrupt.h |    3 +-
 include/linux/padata.h    |  116 +++++++++++
 kernel/Makefile           |    2 +-
 kernel/padata.c           |  490 +++++++++++++++++++++++++++++++++++++++++++++
 kernel/softirq.c          |    2 +-
 5 files changed, 610 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/padata.h
 create mode 100644 kernel/padata.c
include/linux/interrupt.h +2 -1
index 91bb76f..a17679c 100644
@@ -338,7 +338,8 @@ enum
 	TASKLET_SOFTIRQ,
 	SCHED_SOFTIRQ,
 	HRTIMER_SOFTIRQ,
-	RCU_SOFTIRQ,	/* Preferable RCU should always be the last softirq */
+	PADATA_SOFTIRQ,
+	RCU_SOFTIRQ, 	/* Preferable RCU should always be the last softirq */
 
 	NR_SOFTIRQS
 };
include/linux/padata.h new file +116 -0

116 lines not on this page · raw message

kernel/Makefile +1 -1
index 4242366..f2d7ea7 100644
@@ -40,7 +40,7 @@ obj-$(CONFIG_RT_MUTEXES) += rtmutex.o
 obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o
 obj-$(CONFIG_RT_MUTEX_TESTER) += rtmutex-tester.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
-obj-$(CONFIG_USE_GENERIC_SMP_HELPERS) += smp.o
+obj-$(CONFIG_USE_GENERIC_SMP_HELPERS) += smp.o padata.o
 ifneq ($(CONFIG_SMP),y)
 obj-y += up.o
 endif
kernel/padata.c new file +490 -0

490 lines not on this page · raw message

kernel/softirq.c +1 -1
index b525dd3..12c9b64 100644
@@ -56,7 +56,7 @@ static DEFINE_PER_CPU(struct task_struct *, ksoftirqd);
 
 char *softirq_to_name[NR_SOFTIRQS] = {
 	"HI", "TIMER", "NET_TX", "NET_RX", "BLOCK",
-	"TASKLET", "SCHED", "HRTIMER",	"RCU"
+	"TASKLET", "SCHED", "HRTIMER", "PADATA", "RCU"
 };
 
 /*
Signature · 1 line
1.5.4.2
author maintainer
#2 lore raw

RFC PATCH 2/5 pcrypt: Add pcrypt crypto parallelization wrapper

In reply to Steffen Klassert

This patch adds a parallel crypto template that takes a crypto algorithm and converts it to process the crypto transforms in parallel. For the moment only aead is supported.

---
 crypto/Kconfig            |   13 ++
 crypto/Makefile           |    2 +
 crypto/pcrypt.c           |  413 +++++++++++++++++++++++++++++++++++++++++++++
 crypto/pcrypt_core.c      |  125 ++++++++++++++
 include/crypto/pcrypt.h   |   85 +++++++++
 include/linux/interrupt.h |    2 +
 6 files changed, 640 insertions(+), 0 deletions(-)
 create mode 100644 crypto/pcrypt.c
 create mode 100644 crypto/pcrypt_core.c
 create mode 100644 include/crypto/pcrypt.h
crypto/Kconfig +13 -0
index 74d0e62..b05fc95 100644
@@ -112,6 +112,19 @@ config CRYPTO_NULL
 	help
 	  These are 'Null' algorithms, used by IPsec, which do nothing.
 
+config CRYPTO_PCRYPT_CORE
+	bool
+	select CRYPTO_AEAD
+
+config CRYPTO_PCRYPT
+	tristate "Parallel crypto engine (EXPERIMENTAL)"
+	depends on USE_GENERIC_SMP_HELPERS && EXPERIMENTAL
+	select CRYPTO_MANAGER
+	select CRYPTO_PCRYPT_CORE
+	help
+	  This converts an arbitrary crypto algorithm into a parallel
+	  algorithm that is executed in a softirq.
+
 config CRYPTO_WORKQUEUE
        tristate
 
crypto/Makefile +2 -0
index 673d9f7..84b9d17 100644
@@ -56,6 +56,8 @@ obj-$(CONFIG_CRYPTO_XTS) += xts.o
 obj-$(CONFIG_CRYPTO_CTR) += ctr.o
 obj-$(CONFIG_CRYPTO_GCM) += gcm.o
 obj-$(CONFIG_CRYPTO_CCM) += ccm.o
+obj-$(CONFIG_CRYPTO_PCRYPT_CORE) += pcrypt_core.o
+obj-$(CONFIG_CRYPTO_PCRYPT) += pcrypt.o
 obj-$(CONFIG_CRYPTO_CRYPTD) += cryptd.o
 obj-$(CONFIG_CRYPTO_DES) += des_generic.o
 obj-$(CONFIG_CRYPTO_FCRYPT) += fcrypt.o
crypto/pcrypt.c new file +413 -0

413 lines not on this page · raw message

crypto/pcrypt_core.c new file +125 -0

125 lines not on this page · raw message

include/crypto/pcrypt.h new file +85 -0

85 lines not on this page · raw message

include/linux/interrupt.h +2 -0
index a17679c..93e0c9f 100644
@@ -338,6 +338,8 @@ enum
 	TASKLET_SOFTIRQ,
 	SCHED_SOFTIRQ,
 	HRTIMER_SOFTIRQ,
+	AEAD_ENC_SOFTIRQ,
+	AEAD_DEC_SOFTIRQ,
 	PADATA_SOFTIRQ,
 	RCU_SOFTIRQ, 	/* Preferable RCU should always be the last softirq */
 
Signature · 1 line
1.5.4.2
maintainer
#3 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

crypto/Kconfig config CRYPTO_NULL · line 117

Quoted 4 lines · Steffen Klassert
crypto/Kconfig +3 -0
+config CRYPTO_PCRYPT_CORE
+	bool
+	select CRYPTO_AEAD

BTW just noticed that this forces AEAD to be built-in even when pcrypt is a module. We should fix this up.

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#4 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 9 lines · Herbert Xu

crypto/Kconfig config CRYPTO_NULL · line 117

Quoted 4 lines · Steffen Klassert
crypto/Kconfig +3 -0
+config CRYPTO_PCRYPT_CORE
+	bool
+	select CRYPTO_AEAD

BTW just noticed that this forces AEAD to be built-in even when pcrypt is a module. We should fix this up.

Yes, I'll change this with the next version.

maintainer
#5 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

In reply to Steffen Klassert

crypto/Kconfig config CRYPTO_NULL · line 126

Quoted 9 lines · Steffen Klassert
crypto/Kconfig +8 -0
+config CRYPTO_PCRYPT
+	tristate "Parallel crypto engine (EXPERIMENTAL)"
+	depends on USE_GENERIC_SMP_HELPERS && EXPERIMENTAL
+	select CRYPTO_MANAGER
+	select CRYPTO_PCRYPT_CORE
+	help
+	  This converts an arbitrary crypto algorithm into a parallel
+	  algorithm that is executed in a softirq.

BTW, do we really need softirqs for these things? Cryptographic operations are typically slow (especially when you have to move them to other CPUs to handle a single NIC:) so if we're going to the trouble of making it async then we should put them in work queues instead.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#6 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 16 lines · Herbert Xu

crypto/Kconfig config CRYPTO_NULL · line 126

Quoted 9 lines · Steffen Klassert
crypto/Kconfig +8 -0
+config CRYPTO_PCRYPT
+	tristate "Parallel crypto engine (EXPERIMENTAL)"
+	depends on USE_GENERIC_SMP_HELPERS && EXPERIMENTAL
+	select CRYPTO_MANAGER
+	select CRYPTO_PCRYPT_CORE
+	help
+	  This converts an arbitrary crypto algorithm into a parallel
+	  algorithm that is executed in a softirq.

BTW, do we really need softirqs for these things? Cryptographic operations are typically slow (especially when you have to move them to other CPUs to handle a single NIC:) so if we're going to the trouble of making it async then we should put them in work queues instead.

I did already tests with a work queue based parallelization, but the throughput and the latency on networking tests were much better with the remote softirq based version. The serialization engine must always wait for the cpu that processes the 'next' packet to keep the packets in the right order. And softirqs are a good way to ensure that the packets are processed as soon as possible.

Anyway, we can always use pcrypt(cryptd(..)) combinations if we need to make the request async.

maintainer
#7 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 7 lines · Steffen Klassert

I did already tests with a work queue based parallelization, but the throughput and the latency on networking tests were much better with the remote softirq based version. The serialization engine must always wait for the cpu that processes the 'next' packet to keep the packets in the right order. And softirqs are a good way to ensure that the packets are processed as soon as possible.

OK, do you have some numbers that we can add to the patches?

Also note that the real time folks are turning softirq into threads so this complexity might be moot in the end.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#8 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 10 lines · Herbert Xu
Quoted 7 lines · Steffen Klassert

I did already tests with a work queue based parallelization, but the throughput and the latency on networking tests were much better with the remote softirq based version. The serialization engine must always wait for the cpu that processes the 'next' packet to keep the packets in the right order. And softirqs are a good way to ensure that the packets are processed as soon as possible.

OK, do you have some numbers that we can add to the patches?

I posted some numbers for the actual softirq based version with the first patchset, see:
http://www.mail-archive.com/[email protected]/msg03035.html

But as I pointed out there, these numbers are not that meaningful as long as we have the lock in crypto_authenc_hash() Actually I'm about to rewrite authenc/hmac to use ahash. As soon as I finished this I will redo the tests without the lock.

Quoted 4 lines

Also note that the real time folks are turning softirq into threads so this complexity might be moot in the end.

Yes, I know. The one of the main problems of the thread based version was that it had to wait for the cpu that serves the interrupt for the NICs. As soon as other softirqs (like the NET_RX_SOFTIRQ) are thread based too this should not be a problem any more.

maintainer
#9 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 4 lines · Steffen Klassert

I posted some numbers for the actual softirq based version with the first patchset, see:
http://www.mail-archive.com/[email protected]/msg03035.html

Thanks, but I was thinking of softirq numbers vs. workqueue numbers.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#10 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 8 lines · Herbert Xu
Quoted 4 lines · Steffen Klassert

I posted some numbers for the actual softirq based version with the first patchset, see:
http://www.mail-archive.com/[email protected]/msg03035.html

Thanks, but I was thinking of softirq numbers vs. workqueue numbers.

I have just some numbers from a network based parallelization that uses threads. So it's probaply not really comparable to the pcrypt version. To compare the pcrypt version, we would need a thread based padata version. If you think that it is needed I could care about this as soon as I finished the ahash work.

Anyway, here are numbers for the network based versions:

I did forwarding tests with the thread version and two quad core machines (Intel Core 2 Quad Q6600):

linux-2.6.25.2 + thread based (network) parallelization
Packetsize: 1420 byte
Encryption: aes192-sha1
Unidirectional throughput: 660 Mbit/s (tcp)

After rewriting this to use remote softirqs I've got with the same environment:

linux-2.6-git (Dec 01, 2008) + softirq based (network) parallelization
Packetsize: 1420 byte
Encryption: aes192-sha1
Unidirectional throughput: 910 Mbit/s (tcp)

maintainer
#11 lore raw

Re: [RFC] [PATCH 2/5] pcrypt: Add pcrypt crypto parallelization wrapper

Quoted 11 lines · Steffen Klassert

Anyway, here are numbers for the network based versions:

I did forwarding tests with the thread version and two quad core machines (Intel Core 2 Quad Q6600):

linux-2.6.25.2 + thread based (network) parallelization
Packetsize: 1420 byte
Encryption: aes192-sha1
Unidirectional throughput: 660 Mbit/s (tcp)

Quoted 7 lines

After rewriting this to use remote softirqs I've got with the same environment:

linux-2.6-git (Dec 01, 2008) + softirq based (network) parallelization
Packetsize: 1420 byte
Encryption: aes192-sha1
Unidirectional throughput: 910 Mbit/s (tcp)

OK, as long as there something to justify the added complexity it's fine by me. We could always remove the softirqs later if necessary.

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#12 lore raw

RFC PATCH 3/5 eseqiv: Add support for aead algorithms

In reply to Steffen Klassert

This adds eseqiv support for aead algorithms, this is usefull for aead algorithms that need eseqiv as it's default IV generator.

---
 crypto/eseqiv.c        |  244 +++++++++++++++++++++++++++++++++++++++++++++---
 include/linux/crypto.h |    1 +
 2 files changed, 232 insertions(+), 13 deletions(-)
crypto/eseqiv.c +231 -13
index 3ca3b66..04a8bba 100644
@@ -15,6 +15,7 @@
  *
  */
 
+#include <crypto/internal/aead.h>
 #include <crypto/internal/skcipher.h>
 #include <crypto/rng.h>
 #include <crypto/scatterwalk.h>
@@ -62,6 +63,29 @@ out:
 	skcipher_givcrypt_complete(req, err);
 }
 
+static void eseqiv_aead_complete2(struct aead_givcrypt_request *req)
+{
+	struct crypto_aead *geniv = aead_givcrypt_reqtfm(req);
+	struct eseqiv_request_ctx *reqctx = aead_givcrypt_reqctx(req);
+
+	memcpy(req->giv, PTR_ALIGN((u8 *)reqctx->tail,
+			 crypto_aead_alignmask(geniv) + 1),
+	       crypto_aead_ivsize(geniv));
+}
+
+static void eseqiv_aead_complete(struct crypto_async_request *base, int err)
+{
+	struct aead_givcrypt_request *req = base->data;
+
+	if (err)
+		goto out;
+
+	eseqiv_aead_complete2(req);
+
+out:
+	aead_givcrypt_complete(req, err);
+}
+
 static void eseqiv_chain(struct scatterlist *head, struct scatterlist *sg,
 			 int chain)
 {
@@ -155,6 +179,90 @@ static int eseqiv_givencrypt(struct skcipher_givcrypt_request *req)
 
 	if (giv != req->giv)
 		eseqiv_complete2(req);
+out:
+	return err;
+}
+
+static int eseqiv_aead_givencrypt(struct aead_givcrypt_request *req)
+{
+	struct crypto_aead *geniv = aead_givcrypt_reqtfm(req);
+	struct eseqiv_ctx *ctx = crypto_aead_ctx(geniv);
+	struct eseqiv_request_ctx *reqctx = aead_givcrypt_reqctx(req);
+	struct aead_request *subreq;
+	crypto_completion_t complete;
+	void *data;
+	struct scatterlist *osrc, *odst;
+	struct scatterlist *dst;
+	struct page *srcp;
+	struct page *dstp;
+	u8 *giv;
+	u8 *vsrc;
+	u8 *vdst;
+	__be64 seq;
+	unsigned int ivsize;
+	unsigned int len;
+	unsigned int flags;
+	int err;
+
+	subreq = (void *)(reqctx->tail + ctx->reqoff);
+	aead_request_set_tfm(subreq, aead_geniv_base(geniv));
+
+	giv = req->giv;
+	complete = req->areq.base.complete;
+	data = req->areq.base.data;
+
+	osrc = req->areq.src;
+	odst = req->areq.dst;
+	srcp = sg_page(osrc);
+	dstp = sg_page(odst);
+	vsrc = PageHighMem(srcp) ? NULL : page_address(srcp) + osrc->offset;
+	vdst = PageHighMem(dstp) ? NULL : page_address(dstp) + odst->offset;
+
+	ivsize = crypto_aead_ivsize(geniv);
+	flags = req->areq.base.flags | CRYPTO_TFM_REQ_SG_HAS_IV;
+
+	if (vsrc != giv + ivsize && vdst != giv + ivsize) {
+		giv = PTR_ALIGN((u8 *)reqctx->tail,
+				crypto_aead_alignmask(geniv) + 1);
+		complete = eseqiv_aead_complete;
+		data = req;
+	}
+
+	aead_request_set_callback(subreq, flags, complete, data);
+
+	sg_init_table(reqctx->src, 2);
+	sg_set_buf(reqctx->src, giv, ivsize);
+	eseqiv_chain(reqctx->src, osrc, vsrc == giv + ivsize);
+
+	dst = reqctx->src;
+	if (osrc != odst) {
+		sg_init_table(reqctx->dst, 2);
+		sg_set_buf(reqctx->dst, giv, ivsize);
+		eseqiv_chain(reqctx->dst, odst, vdst == giv + ivsize);
+
+		dst = reqctx->dst;
+	}
+
+	aead_request_set_crypt(subreq, reqctx->src, dst,
+				     req->areq.cryptlen + ivsize, req->areq.iv);
+	aead_request_set_assoc(subreq, req->areq.assoc, req->areq.assoclen);
+
+	memcpy(req->areq.iv, ctx->salt, ivsize);
+
+	len = ivsize;
+	if (ivsize > sizeof(u64)) {
+		memset(req->giv, 0, ivsize - sizeof(u64));
+		len = sizeof(u64);
+	}
+	seq = cpu_to_be64(req->seq);
+	memcpy(req->giv + ivsize - len, &seq, len);
+
+	err = crypto_aead_encrypt(subreq);
+	if (err)
+		goto out;
+
+	if (giv != req->giv)
+		eseqiv_aead_complete2(req);
 
 out:
 	return err;
@@ -183,6 +291,29 @@ unlock:
 	return eseqiv_givencrypt(req);
 }
 
+static int eseqiv_aead_givencrypt_first(struct aead_givcrypt_request *req)
+{
+	struct crypto_aead *geniv = aead_givcrypt_reqtfm(req);
+	struct eseqiv_ctx *ctx = crypto_aead_ctx(geniv);
+	int err = 0;
+
+	spin_lock_bh(&ctx->lock);
+	if (crypto_aead_crt(geniv)->givencrypt != eseqiv_aead_givencrypt_first)
+		goto unlock;
+
+	crypto_aead_crt(geniv)->givencrypt = eseqiv_aead_givencrypt;
+	err = crypto_rng_get_bytes(crypto_default_rng, ctx->salt,
+				   crypto_aead_ivsize(geniv));
+
+unlock:
+	spin_unlock_bh(&ctx->lock);
+
+	if (err)
+		return err;
+
+	return eseqiv_aead_givencrypt(req);
+}
+
 static int eseqiv_init(struct crypto_tfm *tfm)
 {
 	struct crypto_ablkcipher *geniv = __crypto_ablkcipher_cast(tfm);
@@ -215,20 +346,47 @@ static int eseqiv_init(struct crypto_tfm *tfm)
 	return skcipher_geniv_init(tfm);
 }
 
+static int eseqiv_aead_init(struct crypto_tfm *tfm)
+{
+	struct crypto_aead *geniv = __crypto_aead_cast(tfm);
+	struct eseqiv_ctx *ctx = crypto_aead_ctx(geniv);
+	unsigned long alignmask;
+	unsigned int reqsize;
+
+	spin_lock_init(&ctx->lock);
+
+	alignmask = crypto_tfm_ctx_alignment() - 1;
+	reqsize = sizeof(struct eseqiv_request_ctx);
+
+	if (alignmask & reqsize) {
+		alignmask &= reqsize;
+		alignmask--;
+	}
+
+	alignmask = ~alignmask;
+	alignmask &= crypto_aead_alignmask(geniv);
+
+	reqsize += alignmask;
+	reqsize += crypto_aead_ivsize(geniv);
+	reqsize = ALIGN(reqsize, crypto_tfm_ctx_alignment());
+
+	ctx->reqoff = reqsize - sizeof(struct eseqiv_request_ctx);
+
+	tfm->crt_aead.reqsize = reqsize + sizeof(struct aead_request);
+
+	return aead_geniv_init(tfm);
+}
+
 static struct crypto_template eseqiv_tmpl;
 
-static struct crypto_instance *eseqiv_alloc(struct rtattr **tb)
+static struct crypto_instance *eseqiv_ablkcipher_alloc(struct rtattr **tb)
 {
-	struct crypto_instance *inst;
 	int err;
-
-	err = crypto_get_default_rng();
-	if (err)
-		return ERR_PTR(err);
+	struct crypto_instance *inst;
 
 	inst = skcipher_geniv_alloc(&eseqiv_tmpl, tb, 0, 0);
 	if (IS_ERR(inst))
-		goto put_rng;
+		goto out;
 
 	err = -EINVAL;
 	if (inst->alg.cra_ablkcipher.ivsize != inst->alg.cra_blocksize)
@@ -236,18 +394,75 @@ static struct crypto_instance *eseqiv_alloc(struct rtattr **tb)
 
 	inst->alg.cra_ablkcipher.givencrypt = eseqiv_givencrypt_first;
 
-	inst->alg.cra_init = eseqiv_init;
-	inst->alg.cra_exit = skcipher_geniv_exit;
+	 inst->alg.cra_init = eseqiv_init;
+	 inst->alg.cra_exit = skcipher_geniv_exit;
 
-	inst->alg.cra_ctxsize = sizeof(struct eseqiv_ctx);
-	inst->alg.cra_ctxsize += inst->alg.cra_ablkcipher.ivsize;
+	inst->alg.cra_ctxsize = inst->alg.cra_ablkcipher.ivsize;
 
 out:
 	return inst;
 
 free_inst:
 	skcipher_geniv_free(inst);
-	inst = ERR_PTR(err);
+	return ERR_PTR(err);
+}
+
+static struct crypto_instance *eseqiv_aead_alloc(struct rtattr **tb)
+{
+	int err;
+	struct crypto_instance *inst;
+
+	inst = aead_geniv_alloc(&eseqiv_tmpl, tb, 0, 0);
+	if (IS_ERR(inst))
+		goto out;
+
+	err = -EINVAL;
+	if (inst->alg.cra_aead.ivsize != inst->alg.cra_blocksize)
+		goto free_inst;
+
+	inst->alg.cra_aead.givencrypt = eseqiv_aead_givencrypt_first;
+
+	 inst->alg.cra_init = eseqiv_aead_init;
+	 inst->alg.cra_exit = aead_geniv_exit;
+
+	inst->alg.cra_ctxsize = inst->alg.cra_aead.ivsize;
+
+out:
+	return inst;
+
+free_inst:
+	aead_geniv_free(inst);
+	return ERR_PTR(err);
+}
+
+static struct crypto_instance *eseqiv_alloc(struct rtattr **tb)
+{
+	struct crypto_attr_type *algt;
+	struct crypto_instance *inst;
+	int err;
+
+	algt = crypto_get_attr_type(tb);
+	err = PTR_ERR(algt);
+	if (IS_ERR(algt))
+		return ERR_PTR(err);
+
+	err = crypto_get_default_rng();
+	if (err)
+		return ERR_PTR(err);
+
+	if ((algt->type ^ CRYPTO_ALG_TYPE_AEAD) & CRYPTO_ALG_TYPE_MASK)
+		inst = eseqiv_ablkcipher_alloc(tb);
+	else
+		inst = eseqiv_aead_alloc(tb);
+
+	if (IS_ERR(inst))
+		goto put_rng;
+
+	inst->alg.cra_ctxsize += sizeof(struct eseqiv_ctx);
+
+out:
+	return inst;
+
 put_rng:
 	crypto_put_default_rng();
 	goto out;
@@ -255,7 +470,10 @@ put_rng:
 
 static void eseqiv_free(struct crypto_instance *inst)
 {
-	skcipher_geniv_free(inst);
+	if ((inst->alg.cra_flags ^ CRYPTO_ALG_TYPE_AEAD) & CRYPTO_ALG_TYPE_MASK)
+		skcipher_geniv_free(inst);
+	else
+		aead_geniv_free(inst);
 	crypto_put_default_rng();
 }
 
include/linux/crypto.h +1 -0
index ec29fa2..1af50e6 100644
@@ -80,6 +80,7 @@
 #define CRYPTO_TFM_REQ_WEAK_KEY		0x00000100
 #define CRYPTO_TFM_REQ_MAY_SLEEP	0x00000200
 #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
+#define CRYPTO_TFM_REQ_SG_HAS_IV	0x00000800
 #define CRYPTO_TFM_RES_WEAK_KEY		0x00100000
 #define CRYPTO_TFM_RES_BAD_KEY_LEN   	0x00200000
 #define CRYPTO_TFM_RES_BAD_KEY_SCHED 	0x00400000
Signature · 1 line
1.5.4.2
maintainer
#13 lore raw

Re: [RFC] [PATCH 3/5] eseqiv: Add support for aead algorithms

Quoted 4 lines · Steffen Klassert

This adds eseqiv support for aead algorithms, this is usefull for aead algorithms that need eseqiv as it's default IV generator.

I'm going to change the default sync geniv to eseqiv for SMP. That should render this patch unnecessary, right?

Here's the change.

commit 0b67fb65d1b2ba1396de69112b8b9bc95d8d5feb

Author: Herbert Xu <[email protected]>
Date:   Thu Jun 25 18:43:48 2009 +0800

crypto: skcipher - Change default sync geniv on SMP to eseqiv

As it stands we use chainiv for sync algorithms and eseqiv for async algorithms. However, when there is more than one CPU chainiv forces all processing to be serialised which is usually not what you want. Also, the added overhead of eseqiv isn't that great.

Therefore this patch changes the default sync geniv on SMP machines to eseqiv. For the odd situation where the overhead is unacceptable then chainiv is still available as an option.

Note that on UP machines chainiv is still preferred over eseqiv for sync algorithms.

crypto/ablkcipher.c +19 -1
index 43fc8fb..03fb5fa 100644
@@ -14,6 +14,7 @@
  */
 
 #include <crypto/internal/skcipher.h>
+#include <linux/cpumask.h>
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -25,6 +26,8 @@
 
 #include "internal.h"
 
+static const char *skcipher_default_geniv __read_mostly;
+
 static int setkey_unaligned(struct crypto_ablkcipher *tfm, const u8 *key,
 			    unsigned int keylen)
 {
@@ -180,7 +183,8 @@ EXPORT_SYMBOL_GPL(crypto_givcipher_type);
 
 const char *crypto_default_geniv(const struct crypto_alg *alg)
 {
-	return alg->cra_flags & CRYPTO_ALG_ASYNC ? "eseqiv" : "chainiv";
+	return alg->cra_flags & CRYPTO_ALG_ASYNC ?
+	       "eseqiv" : skcipher_default_geniv;
 }
 
 static int crypto_givcipher_default(struct crypto_alg *alg, u32 type, u32 mask)
@@ -361,3 +365,17 @@ err:
 	return ERR_PTR(err);
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_ablkcipher);
+
+static int __init skcipher_module_init(void)
+{
+	skcipher_default_geniv = num_possible_cpus() > 1 ?
+				 "eseqiv" : "chainiv";
+	return 0;
+}
+
+static void skcipher_module_exit(void)
+{
+}
+
+module_init(skcipher_module_init);
+module_exit(skcipher_module_exit);

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#14 lore raw

Re: [RFC] [PATCH 3/5] eseqiv: Add support for aead algorithms

Quoted 9 lines · Herbert Xu
Quoted 4 lines · Steffen Klassert

This adds eseqiv support for aead algorithms, this is usefull for aead algorithms that need eseqiv as it's default IV generator.

I'm going to change the default sync geniv to eseqiv for SMP. That should render this patch unnecessary, right?

Right, this would reduce the patchset to the padata and the pcrypt patch. I'll strip the patchset to these two patches as soon as I see your patch applied to cryptodev-2.6.

author maintainer
#15 lore raw

RFC PATCH 4/5 authenc: Check if the IV is already added to the scatterlist

In reply to Steffen Klassert

aead eseqiv needs to add the IV to the scatterlist itself. So check if the IV is already contained in the scatterlist and add it just if it is not already there.

---
 crypto/authenc.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)
crypto/authenc.c +3 -2
index 5793b64..e11029a 100644
@@ -157,15 +157,16 @@ static int crypto_authenc_genicv(struct aead_request *req, u8 *iv,
 
 	dstp = sg_page(dst);
 	vdst = PageHighMem(dstp) ? NULL : page_address(dstp) + dst->offset;
+	cryptlen = req->cryptlen;
 
-	if (ivsize) {
+	if (ivsize && !(aead_request_flags(req) & CRYPTO_TFM_REQ_SG_HAS_IV)) {
 		sg_init_table(cipher, 2);
 		sg_set_buf(cipher, iv, ivsize);
 		authenc_chain(cipher, dst, vdst == iv + ivsize);
 		dst = cipher;
+		cryptlen += ivsize;
 	}
 
-	cryptlen = req->cryptlen + ivsize;
 	hash = crypto_authenc_hash(req, flags, dst, cryptlen);
 	if (IS_ERR(hash))
 		return PTR_ERR(hash);
Signature · 1 line
1.5.4.2
author maintainer
#16 lore raw

RFC PATCH 5/5 tcrypt: Test algorithms by name

In reply to Steffen Klassert

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

---
 crypto/tcrypt.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)
crypto/tcrypt.c +13 -1
index c3c9124..9d5b33c 100644
@@ -44,6 +44,8 @@
  */
 static unsigned int sec;
 
+static char *alg = NULL;
+static u32 type;
 static int mode;
 static char *tvmem[TVMEMSIZE];
 
@@ -864,6 +866,11 @@ static void do_test(int m)
 	}
 }
 
+static void do_alg_test(const char *alg, u32 type)
+{
+	crypto_has_alg(alg, type, CRYPTO_ALG_TYPE_MASK);
+}
+
 static int __init tcrypt_mod_init(void)
 {
 	int err = -ENOMEM;
@@ -875,7 +882,10 @@ static int __init tcrypt_mod_init(void)
 			goto err_free_tv;
 	}
 
-	do_test(mode);
+	if (alg)
+		do_alg_test(alg, type);
+	else
+		do_test(mode);
 
 	/* We intentionaly return -EAGAIN to prevent keeping
 	 * the module. It does all its work from init()
@@ -901,6 +911,8 @@ static void __exit tcrypt_mod_fini(void) { }
 module_init(tcrypt_mod_init);
 module_exit(tcrypt_mod_fini);
 
+module_param(alg, charp, 0);
+module_param(type, uint, 0);
 module_param(mode, int, 0);
 module_param(sec, uint, 0);
 MODULE_PARM_DESC(sec, "Length in seconds of speed tests "
Signature · 1 line
1.5.4.2
maintainer
#17 lore raw

Re: [RFC] [PATCH 5/5] tcrypt: Test algorithms by name

Quoted 6 lines · Steffen Klassert

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

I'll apply this one right now. Thanks!

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
maintainer
#18 lore raw

Re: [RFC] [PATCH 5/5] tcrypt: Test algorithms by name

Quoted 9 lines · Herbert Xu
Quoted 6 lines · Steffen Klassert

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

I'll apply this one right now. Thanks!

Oops it doesn't apply anymore. Could you rebase this one for me? Thanks!

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#19 lore raw

PATCH 1/1 tcrypt: Test algorithms by name

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

---
 crypto/tcrypt.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)
crypto/tcrypt.c +14 -1
index d59ba50..dfeec0c 100644
@@ -45,6 +45,8 @@
  */
 static unsigned int sec;
 
+static char *alg = NULL;
+static u32 type;
 static int mode;
 static char *tvmem[TVMEMSIZE];
 
@@ -885,6 +887,11 @@ static int do_test(int m)
 	return ret;
 }
 
+static int do_alg_test(const char *alg, u32 type)
+{
+	return crypto_has_alg(alg, type, CRYPTO_ALG_TYPE_MASK);
+}
+
 static int __init tcrypt_mod_init(void)
 {
 	int err = -ENOMEM;
@@ -896,7 +903,11 @@ static int __init tcrypt_mod_init(void)
 			goto err_free_tv;
 	}
 
-	err = do_test(mode);
+	if (alg)
+		err = do_alg_test(alg, type);
+	else
+		err = do_test(mode);
+
 	if (err) {
 		printk(KERN_ERR "tcrypt: one or more tests failed!\n");
 		goto err_free_tv;
@@ -928,6 +939,8 @@ static void __exit tcrypt_mod_fini(void) { }
 module_init(tcrypt_mod_init);
 module_exit(tcrypt_mod_fini);
 
+module_param(alg, charp, 0);
+module_param(type, uint, 0);
 module_param(mode, int, 0);
 module_param(sec, uint, 0);
 MODULE_PARM_DESC(sec, "Length in seconds of speed tests "
Signature · 1 line
1.5.4.2
maintainer
#20 lore raw

Re: [PATCH] tcrypt: Test algorithms by name

Quoted 6 lines · Steffen Klassert

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

That was quick :)

Patch applied. Thanks a lot Steffen!

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
maintainer
#21 lore raw

Re: [PATCH] tcrypt: Test algorithms by name

Quoted 11 lines · Herbert Xu
Quoted 6 lines · Steffen Klassert

This adds the 'alg' module parameter to be able to test an algorithm by name. If the algorithm type is not ad-hoc clear for a algorithm (e.g. pcrypt, cryptd) it is possilbe to set the algorithm type with the 'type' module parameter.

That was quick :)

Patch applied. Thanks a lot Steffen!

BTW, I added this on top so that modprobe doesn't complain about the return code:

tcrypt: one or more tests failed!
sys_init_module: 'tcrypt'->init suspiciously returned 1, it should follow 0/-E convention
sys_init_module: loading module anyway...
Pid: 3064, comm: modprobe Not tainted 2.6.30 #2

Call Trace:
 [<ffffffff81076826>] level2_spare_pgt+0x6e826/0x2d1760
 [<ffffffff8100b4ab>] level2_spare_pgt+0x34ab/0x2d1760

commit ea4006576945195ed35824acfb4007ca7cb78b70

Author: Herbert Xu <[email protected]>
Date:   Fri Jun 19 20:37:00 2009 +0800

crypto: tcrypt - Fix module return code when testing by name

We should return 0/-ENOENT instead of 1/0 when testing by name.

crypto/tcrypt.c +1 -1
index dfeec0c..a890a67 100644
@@ -889,7 +889,7 @@ static int do_test(int m)
 
 static int do_alg_test(const char *alg, u32 type)
 {
-	return crypto_has_alg(alg, type, CRYPTO_ALG_TYPE_MASK);
+	return crypto_has_alg(alg, type, CRYPTO_ALG_TYPE_MASK) ? 0 : -ENOENT;
 }
 
 static int __init tcrypt_mod_init(void)

Cheers,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#22 lore raw

Re: [PATCH] tcrypt: Test algorithms by name

Quoted 8 lines · Herbert Xu
Quoted 4 lines

That was quick :)

Patch applied. Thanks a lot Steffen!

BTW, I added this on top so that modprobe doesn't complain about the return code:

Ugh, I was a bit too quick. Thanks for fixing this up!