Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Neil Horman
On Wed, May 13, 2009 at 11:30:50AM +1000, Herbert Xu wrote:
 On Tue, May 12, 2009 at 08:37:27PM -0400, Neil Horman wrote:
 
   Would there be any objections to dropping the noexit parameter
   entirely and just making its behavior the default? It would make
   all users regardless of fips mode notice failures more readily.
   
  I think thats a fine idea.  Theres no reason that a user of the tcrypt 
  module
  can't manually rmmod it when the testing is done.  Doing it that way just 
  seems
  more sane to me to begin with anyway.
 
 No, tcrypt is only a relic for correctness testing.  Its main
 purpose these days is for speed testing.  Having to rmmod it
 is silly.
 
 There's really no need to load tcrypt for correctness testing
 anymore.
 

Not really sure I agree with the logic here.  I agree that its pretty clear that
its major value is for quickly testing all the algorithms in a system, but
universally failing the loading of the module simply to save a few milliseconds
seems like a poor choice.  In so doing you create an alias effect, as jarod
noted between a non-existent module and a module that failed to load.  The
aliasing can be resolved, if you want to parse dmesg, but if speed is the issue
at hand, that parsing is a significant impact.  If you allow the module to load
properly, then for the cost of an rmmod, you can tell simply from the exit code
of modprobe:
1) If the module was found 
2) If the tests passed

And if the rmmod is simply to expensive for whatever reason, then for the cost
of a few k of ram taken up by the module, you can choose not to unload it.

Of course, if tcrypt is really as much of a relic as you say, perhaps that is an
argument for removing the module entirely.  Perhaps the testmgr interface could
be exported to userspace and the tcrypt tests be packaged as a userspace suite.

Regards
Neil

 Cheers,
 -- 
 Visit Openswan at http://www.openswan.org/
 Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Herbert Xu
On Wed, May 13, 2009 at 07:08:26AM -0400, Neil Horman wrote:

 Not really sure I agree with the logic here.  I agree that its pretty clear 
 that
 its major value is for quickly testing all the algorithms in a system, but
 universally failing the loading of the module simply to save a few 
 milliseconds
 seems like a poor choice.  In so doing you create an alias effect, as jarod
 noted between a non-existent module and a module that failed to load.  The
 aliasing can be resolved, if you want to parse dmesg, but if speed is the 
 issue
 at hand, that parsing is a significant impact.  If you allow the module to 
 load
 properly, then for the cost of an rmmod, you can tell simply from the exit 
 code
 of modprobe:
 1) If the module was found 
 2) If the tests passed

As I said, tcrypt should no longer be used to test algorithms.
Algorithms are tested as they load, with the result available
in /proc/crypto.  tcrypt is just a relic that will be going away.

Do not rely on it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RFC] [PATCH 0/5] Parallel IPsec v3

2009-05-13 Thread Steffen Klassert
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 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
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-05-13 Thread 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.

Signed-off-by: Steffen Klassert steffen.klass...@secunet.com
---
 crypto/Kconfig|   13 ++
 crypto/Makefile   |2 +
 crypto/pcrypt.c   |  353 +
 crypto/pcrypt_core.c  |  106 ++
 include/crypto/pcrypt.h   |   56 +++
 include/linux/interrupt.h |2 +
 kernel/softirq.c  |3 +-
 7 files changed, 534 insertions(+), 1 deletions(-)
 create mode 100644 crypto/pcrypt.c
 create mode 100644 crypto/pcrypt_core.c
 create mode 100644 include/crypto/pcrypt.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 74d0e62..36da74f 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -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 wrapper (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
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 673d9f7..84b9d17 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -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
diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
new file mode 100644
index 000..32e88fb
--- /dev/null
+++ b/crypto/pcrypt.c
@@ -0,0 +1,353 @@
+/*
+ * pcrypt - Parallel crypto wrapper.
+ *
+ * Copyright (C) 2009 secunet Security Networks AG
+ * Copyright (C) 2009 Steffen Klassert steffen.klass...@secunet.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include crypto/algapi.h
+#include crypto/internal/aead.h
+#include linux/err.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include crypto/pcrypt.h
+
+struct pcrypt_instance_ctx {
+   struct crypto_spawn spawn;
+   unsigned int tfm_count;
+};
+
+struct pcrypt_aead_ctx {
+   unsigned int tfm_nr;
+};
+
+static int pcrypt_do_parallel(struct padata_priv *padata, unsigned int tfm_nr,
+ unsigned int softirq, unsigned int padata_nr)
+{
+   unsigned int cpu, cpu_index, num_cpus, cb_cpu;
+   cpumask_t cpu_map;
+
+   cpu_map = padata_get_cpumap(padata_nr);
+   num_cpus = cpus_weight(cpu_map);
+
+   cpu_index = tfm_nr % num_cpus;
+
+   cb_cpu = first_cpu(cpu_map);
+   for (cpu = 0; cpu  cpu_index; cpu++)
+   cb_cpu = next_cpu(cb_cpu, cpu_map);
+
+   return padata_do_parallel(softirq, padata_nr, padata, cb_cpu);
+}
+
+static int pcrypt_aead_setkey(struct crypto_aead *parent,
+ const u8 *key, unsigned int keylen)
+{
+   struct crypto_aead *child = crypto_aead_crt(parent)-base;
+
+   return crypto_aead_setkey(child, key, keylen);
+}
+
+static int pcrypt_aead_setauthsize(struct crypto_aead *parent,
+  unsigned int authsize)
+{
+   struct crypto_aead *child = crypto_aead_crt(parent)-base;
+
+   return crypto_aead_setauthsize(child, authsize);
+}
+
+static void pcrypt_aead_serial(struct padata_priv *padata)
+{
+   struct pcrypt_request *preq = pcrypt_padata_request(padata);
+   struct aead_request *req = pcrypt_request_ctx(preq);
+
+   aead_request_complete(req-base.data, padata-info);
+}
+
+static void pcrypt_aead_giv_serial(struct padata_priv *padata)
+{
+   struct pcrypt_request *preq = pcrypt_padata_request(padata);
+   struct aead_givcrypt_request *req = pcrypt_request_ctx(preq);
+
+   aead_request_complete(req-areq.base.data, padata-info);
+}
+
+static void pcrypt_aead_done(struct crypto_async_request *areq, int err)
+{
+   struct aead_request 

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

2009-05-13 Thread Steffen Klassert
This adds eseqiv support for aead algorithms, this is usefull
for aead wrappers that need eseqiv as it's default IV generator.

Signed-off-by: Steffen Klassert steffen.klass...@secunet.com
---
 crypto/eseqiv.c|  248 +---
 include/linux/crypto.h |1 +
 2 files changed, 235 insertions(+), 14 deletions(-)

diff --git a/crypto/eseqiv.c b/crypto/eseqiv.c
index 2a342c8..b6185f4 100644
--- a/crypto/eseqiv.c
+++ b/crypto/eseqiv.c
@@ -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)
 {
@@ -153,7 +177,93 @@ static int eseqiv_givencrypt(struct 
skcipher_givcrypt_request *req)
if (err)
goto out;
 
-   eseqiv_complete2(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;
@@ -182,6 +292,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 = 

Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Herbert Xu
On Wed, May 13, 2009 at 09:12:46AM -0400, Jarod Wilson wrote:
 
 Hm... FIPS has the requirement that we test all algs before we use any
 algs, self-tests on demand before first use for each alg is
 insufficient. At first blush, I'm not seeing how we ensure this
 happens. How can we trigger a cbc(des3_ede) self-test from userspace?
 I see that modprobe'ing des.ko runs the base des and des3_ede
 self-tests, but modprobe'ing cbc.ko doesn't lead to any self-tests
 being run.

Once we have a user-space interface crypto API you will be able
to instantiate any given algorithm.

For now I suggest that you create your own module to instantiate
these FIPS algorithms.  Or just load tcrypt and ignore the exit
status, or make tcrypt return 0 if we're in FIPS mode.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Jarod Wilson
On Wednesday 13 May 2009 09:27:52 Herbert Xu wrote:
 On Wed, May 13, 2009 at 09:12:46AM -0400, Jarod Wilson wrote:
  
  Hm... FIPS has the requirement that we test all algs before we use any
  algs, self-tests on demand before first use for each alg is
  insufficient. At first blush, I'm not seeing how we ensure this
  happens. How can we trigger a cbc(des3_ede) self-test from userspace?
  I see that modprobe'ing des.ko runs the base des and des3_ede
  self-tests, but modprobe'ing cbc.ko doesn't lead to any self-tests
  being run.
 
 Once we have a user-space interface crypto API you will be able
 to instantiate any given algorithm.
 
 For now I suggest that you create your own module to instantiate
 these FIPS algorithms.  Or just load tcrypt and ignore the exit
 status, or make tcrypt return 0 if we're in FIPS mode.

The latter option is more or less what the patch at the start of this
thread did, although via a param to tcrypt, not keying off the fips
flag. If I were to modify the patch to drop the mod param usage, and
instead key off the fips flag to not exit, would that be acceptable
for committing until such time as the userspace interface is ready?

-- 
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Neil Horman
On Wed, May 13, 2009 at 11:27:52PM +1000, Herbert Xu wrote:
 On Wed, May 13, 2009 at 09:12:46AM -0400, Jarod Wilson wrote:
  
  Hm... FIPS has the requirement that we test all algs before we use any
  algs, self-tests on demand before first use for each alg is
  insufficient. At first blush, I'm not seeing how we ensure this
  happens. How can we trigger a cbc(des3_ede) self-test from userspace?
  I see that modprobe'ing des.ko runs the base des and des3_ede
  self-tests, but modprobe'ing cbc.ko doesn't lead to any self-tests
  being run.
 
 Once we have a user-space interface crypto API you will be able
 to instantiate any given algorithm.
 
Thats a good idea.  Jarod, didn't you create a generic netlink socket family
module that created just such an interface for testing purposes?  That might be
worth polishing and submitting to provide that user space crypto api

Neil

 
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: tcrypt: add option to not exit on success

2009-05-13 Thread Jarod Wilson
On Wednesday 13 May 2009 10:02:25 Neil Horman wrote:
 On Wed, May 13, 2009 at 11:27:52PM +1000, Herbert Xu wrote:
  On Wed, May 13, 2009 at 09:12:46AM -0400, Jarod Wilson wrote:
   
   Hm... FIPS has the requirement that we test all algs before we use any
   algs, self-tests on demand before first use for each alg is
   insufficient. At first blush, I'm not seeing how we ensure this
   happens. How can we trigger a cbc(des3_ede) self-test from userspace?
   I see that modprobe'ing des.ko runs the base des and des3_ede
   self-tests, but modprobe'ing cbc.ko doesn't lead to any self-tests
   being run.
  
  Once we have a user-space interface crypto API you will be able
  to instantiate any given algorithm.
  
 Thats a good idea.  Jarod, didn't you create a generic netlink socket family
 module that created just such an interface for testing purposes?

Indeed. Works quite well for my somewhat specific needs...

 That might be
 worth polishing and submitting to provide that user space crypto api

It would likely need a LOT of polish, and I'm not sure if its at all
close to what we have (Herbert has?) in mind At the moment, it
consists of:

1) a kernel module, which duplicates many of the functions in testmgr,
more or less, but gets its input over a generic netlink socket, rather
than from a static array, and sends the result back out over the same
socket.

2) a userspace binary that feeds very specifically formatted vectors
to the kernel via the netlink socket, listens for the result and
spits it out -- it doesn't actually verify the correctness of the
result, but adding support for passing in an expected result and
checking against it would be trivial.

I guess the place to start would be to ask exactly what sort of
user-space interface to the crypto API did we have in mind here?
i.e., what sort of user-space-kernel-space communication is
envisioned, and what sort of functionality should be present?

I could see the desire for a simpler interface that doesn't rely upon
a specific userspace binary -- something sysfs or proc-based -- but
netlink is reasonably flexible...

-- 
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html