Re: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
reopen 541835 thanks hey, On 31/08/2009 Sebastian Andrzej Siewior wrote: > * Jonas Meurer | 2009-08-31 17:52:00 [+0200]: > > >> Could someone please look at initramfs to figure out why those three > >> modules are not copied in this reduced setup? > > > >the reason is simply that no other crypto modules define depends on the > >listed ones: > Well yes, but aes cbc is placed in the new initrd. I took a look, read > below. as you already discovered, that's because the initramfs hook script for cryptroot adds some crypto modules manually in debian. currently these are dm-mod, dm-crypt, cbc, aes, sha256 and all the modules they depend on. > >so the following depends should be added/changed: > > > >- chainiv should depend o 'krng' instead of 'rng' at least >rng is a subsubsystem within crypto. krng is one implementation which >provides random numbers. So does ansi_cprng. Another implementation >may come. > > >- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr' > > instead of 'crypto_algapi' >This isn't possible without dummy variables because they don't need >each other in first place. We could move code but crypto_algapi can >live without cryptomgr. However cryptomgr doesn't make sense without >crypto_algapi. >Lets say you have a VIA CPU which provides cbc(aes) in HW. So you >don't need cryptomgr because cbc(aes) is allready available. You need >aes_generic but that's another story :) > > >- crypto_algapi should depend on chainiv >chainiv is one possible implementation eseqiv is another one. The >later is used on async-hw and in 2.6.32+ on SMP afaik. > > >these changes are pure guesses, i don't know the details. but at least > >additional depends need to be defined for crypto modules, don't you > >think so? > > We have them in Kconfig. All required modules are built and are > available. However the things aren't that easy. The crypto subsystem is > very flexible and undocumented and this is the problem here I think. ok, i see the point that it's not enough to simply add some additional dependencies in order to fix the problem. seems like an easy solution doesn't exist. > So this brings me to the following question: Why are you so picky and you > don't take all of the modules? sh 2.6.30-1 on various debian archs: > du -sh x86_64 i386 powerpc s390x mips(r5k-ip32) > crypto 720K636K 1.1M 804K968K > arch//crypto 72K 36K 092K 0 > driver/crypto 32K 60K 60K 0 52K > Total 824K732K 1.2M 896K1020 > > So all modules together have an average footprint of 941.0K. This isn't > that much. There is no size limit on initrd unless you are on a system > with has 32MiB or something like that :) > With *all* those crypto modules which are selected and built you are > able to cover all corner cases. > I took a look at hooks/cryptroot and really and only a few modules are > included. Right now you don't include HW cipher e.g. VIA's padlock or > AMD's geode. If you don't load those module while openning the root > partition (the first request), then the module is never loaded / used. > The other unhandled case are non default ciphers like xts(aes) which one > might use. The brand new aes implementation aesni-intel is also not be > considered. Most modules have _generic in their name if there is > another implementation available and -arch if there is an assembly > variant but I would prefer that this does not become part of an ABI > where one can rely on. > > Would it be okay for you to change the way the crypto modules are picked > and include the full set? i don't like the idea to add _all_ crypto modules into the initramfs per default. the size of crypto and arch//crypto will keep on growing for kernels which do have ship all available modules for ciphers and implementations. i think that the initramfs should be a _minimal_ system, and detecting the required crypto modules should be possible. alternative crypto cipher and blockcipher modules are already detected if required, as information about these are available from the cryptroot configuration (either luks header or cmdline options given to cryptsetup). i added cryptomgr, chainiv and krng to the list of required modules in /usr/share/initramfs-tools/hooks/cryptroot for now. still i see the point that this solution has it's drawbacks. modules for crypto hardware and cipher implementations not following the convention to call modules _generic and -alias aren't detected by the current system. i guess the best solution would be to improve the module dependency system. cipher meta-modules like 'aes' should depend on all available implementations. same for ivciphers, hashs, rng implementations etc. what do you think about it? greetings, jonas signature.asc Description: Digital signature
Re: Crypto oops in async_chainiv_do_postponed
On Mon, Aug 31, 2009 at 11:11:42AM -0500, Brad Bosch wrote:
>
> OK. I was looking for something subtle because the crash takes a long
> time to happen. But do you agree that the race I described above also
> a real bug?
No I don't think it is. CHAINV_STATE_INUSE guarantees that only
one entity can use ctx->err at any time.
> Yes, I see that this bug must be the bug we would likely encounter first.
> Apparently, async_chainiv_do_postponed was never tested? But I don't
> see how the patch you proposed below helps. We still don't seem to be
> returning NULL from skcipher_dequeue_givcrypt when we reach the end of
> the queue because __crypto_dequeue_request is not checking for NULL
> before it subtracts offset.
Where we subtract the offset the pointer can never be NULL. Please
try my patch.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
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: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
* Jonas Meurer | 2009-08-31 17:52:00 [+0200]: >> Could someone please look at initramfs to figure out why those three >> modules are not copied in this reduced setup? > >the reason is simply that no other crypto modules define depends on the >listed ones: Well yes, but aes cbc is placed in the new initrd. I took a look, read below. >so the following depends should be added/changed: > >- chainiv should depend o 'krng' instead of 'rng' at least rng is a subsubsystem within crypto. krng is one implementation which provides random numbers. So does ansi_cprng. Another implementation may come. >- maybe cipher modules like aes,serpent,... should depend on 'cryptomgr' > instead of 'crypto_algapi' This isn't possible without dummy variables because they don't need each other in first place. We could move code but crypto_algapi can live without cryptomgr. However cryptomgr doesn't make sense without crypto_algapi. Lets say you have a VIA CPU which provides cbc(aes) in HW. So you don't need cryptomgr because cbc(aes) is allready available. You need aes_generic but that's another story :) >- crypto_algapi should depend on chainiv chainiv is one possible implementation eseqiv is another one. The later is used on async-hw and in 2.6.32+ on SMP afaik. >these changes are pure guesses, i don't know the details. but at least >additional depends need to be defined for crypto modules, don't you >think so? We have them in Kconfig. All required modules are built and are available. However the things aren't that easy. The crypto subsystem is very flexible and undocumented and this is the problem here I think. Another example: The geode aes HW/driver can handle cbc(aes) requests as long as its keysize is 128bits. Larger keys can't be handled by HW so we fallback to the next implementation. If you just copy the geode module then the geode module won't work because an alternative implementation is missing. So this brings me to the following question: Why are you so picky and you don't take all of the modules? sh 2.6.30-1 on various debian archs: du -sh x86_64 i386 powerpc s390x mips(r5k-ip32) crypto 720K636K 1.1M 804K968K arch//crypto 72K 36K 092K 0 driver/crypto 32K 60K 60K 0 52K Total 824K732K 1.2M 896K1020 So all modules together have an average footprint of 941.0K. This isn't that much. There is no size limit on initrd unless you are on a system with has 32MiB or something like that :) With *all* those crypto modules which are selected and built you are able to cover all corner cases. I took a look at hooks/cryptroot and really and only a few modules are included. Right now you don't include HW cipher e.g. VIA's padlock or AMD's geode. If you don't load those module while openning the root partition (the first request), then the module is never loaded / used. The other unhandled case are non default ciphers like xts(aes) which one might use. The brand new aes implementation aesni-intel is also not be considered. Most modules have _generic in their name if there is another implementation available and -arch if there is an assembly variant but I would prefer that this does not become part of an ABI where one can rely on. Would it be okay for you to change the way the crypto modules are picked and include the full set? >greetings, > jonas Sebastian -- 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: [pkg-cryptsetup-devel] Bug#541835: crypto configuration / dependencies broken
hey, On 30/08/2009 Sebastian Andrzej Siewior wrote: > * Sebastian Andrzej Siewior | 2009-08-28 10:00:56 [+0200]: > > >>> the problem is not reproducible with a debian/unstable 2.6.30.6 kernel, > >>> even though it has cbc compiled as module as well. but if I recompile > >>> the same kernel sources with Celejars kernel .config, the problem > >>> occurs. thus it must be related to the kernel config in some way. > >It must be the kernel confing since I run .30.stable and it works. I try > >to look at it later. > > Your kernel config is fine, the problem is that the initramfs tools do > not copy all of the required modules into the initramfs. The missing > modles are: > - cryptomgr: that one is responsible to load the cbc and aes module and > bind them to cbc(aes) > - chainiv: that one creates IVs if the "user" does not specify one. > dm-crypt probably does not use that one but is required due to the way > crypto works atm. > - krng: provides random numbers and is required by chainiv. > > If you add those three to /etc/initramfs/modules than it should work. > > Could someone please look at initramfs to figure out why those three > modules are not copied in this reduced setup? the reason is simply that no other crypto modules define depends on the listed ones: # modinfo -F depends dm-crypt dm-mod,crypto_blkcipher # modinfo -F aes_generic sha256_generic cbc crypto_algapi crypto_hash crypto_algapi,crypto_blkcipher # modinfo -F crypto_blkcipher crypto_hash crypto_algapi crypto_algapi and even the new modules don't depend on each other: # modinfo -F cryptomgr crypto_hash,crypto_algapi,crypto_blkcipher,aead,pcompress # modinfo -F chainiv crypto_algapi,rng,crypto_wq,crypto_blkcipher # modinfo -F krng rng,crypto_algapi so the following depends should be added/changed: - chainiv should depend o 'krng' instead of 'rng' at least - maybe cipher modules like aes,serpent,... should depend on 'cryptomgr' instead of 'crypto_algapi' - crypto_algapi should depend on chainiv these changes are pure guesses, i don't know the details. but at least additional depends need to be defined for crypto modules, don't you think so? greetings, jonas -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crypto oops in async_chainiv_do_postponed
Herbert Xu writes:
> Thanks for the detailed analysis and patch!
No problem, thanks for looking at it!
>
> > The null dereference occurs when subreq is dereferenced in
> > async_chainiv_do_postponed(). My guess is that the
> > skcipher_givcrypt_request block has been freed and subsequently
> > overwritten by the time the postponed request is processed. This
> > could happen if chainiv_givencrypt() returns anything other than
> > -EINPROGRESS after postponing the request. From what I can see, this
> > could indeed happen since the same err field in async_chainiv_ctx is
> > used both when the request is postponed and also when it is later
> > processed by the worker thread. Neither the lock, nor the
> > CHAINIV_STATE_INUSE bit in ctx->state will prevent this race which
> > results in the -EINPROGRESS err being overwritten between the time it
> > is placed in ctx->err in async_chainiv_postpone_request() and when it
> > is read back out in async_chainiv_schedule_work(). I am curious why
> > this method of returning the error code was used in the first place.
>
> Actually I think the problem is much less subtle than that :)
OK. I was looking for something subtle because the crash takes a long
time to happen. But do you agree that the race I described above also
a real bug?
>
> The problem is that whenever crypto_dequeue_request returns NULL,
> chainiv will never see the NULL pointer because we end up converting
> the pointer to skcipher_givcrypt_request which would have the value
> (NULL - off) where off is non-zero.
Yes, I see that this bug must be the bug we would likely encounter first.
Apparently, async_chainiv_do_postponed was never tested? But I don't
see how the patch you proposed below helps. We still don't seem to be
returning NULL from skcipher_dequeue_givcrypt when we reach the end of
the queue because __crypto_dequeue_request is not checking for NULL
before it subtracts offset.
Wouldn't the following (simpler, but untested) patch work?
Index: skcipher.h
===
RCS file:
/share/cvs/sdg/kernels/kernel.wms/kernel_2_6_27/src/include/crypto/internal/skcipher.h,v
retrieving revision 1.1.1.1.4.2
diff -u -r1.1.1.1.4.2 skcipher.h
--- skcipher.h 10 Mar 2009 05:25:25 - 1.1.1.1.4.2
+++ skcipher.h 31 Aug 2009 15:56:50 -
@@ -85,8 +85,9 @@
static inline struct skcipher_givcrypt_request *skcipher_dequeue_givcrypt(
struct crypto_queue *queue)
{
- return container_of(ablkcipher_dequeue_request(queue),
- struct skcipher_givcrypt_request, creq);
+ struct ablkcipher_request *req = ablkcipher_dequeue_request(queue);
+ return req ? container_of(req, struct skcipher_givcrypt_request, creq)
+ : NULL;
}
static inline void *skcipher_givcrypt_reqctx(
Thanks!
--Brad
>
> Please let me know if this patch fixes the crash for you.
>
> commit 0c7d400fafaeab6014504a6a6249f01bac7f7db4
> Author: Herbert Xu
> Date: Sat Aug 29 20:44:04 2009 +1000
>
> crypto: skcipher - Fix skcipher_dequeue_givcrypt NULL test
>
> As struct skcipher_givcrypt_request includes struct crypto_request
> at a non-zero offset, testing for NULL after converting the pointer
> returned by crypto_dequeue_request does not work. This can result
> in IPsec crashes when the queue is depleted.
>
> This patch fixes it by doing the pointer conversion only when the
> return value is non-NULL. In particular, we create a new function
> __crypto_dequeue_request that does the pointer conversion.
>
> Reported-by: Brad Bosch
> Signed-off-by: Herbert Xu
>
> diff --git a/crypto/algapi.c b/crypto/algapi.c
> index 56c62e2..df0863d 100644
> --- a/crypto/algapi.c
> +++ b/crypto/algapi.c
> @@ -692,7 +692,7 @@ out:
> }
> EXPORT_SYMBOL_GPL(crypto_enqueue_request);
>
> -struct crypto_async_request *crypto_dequeue_request(struct crypto_queue
> *queue)
> +void *__crypto_dequeue_request(struct crypto_queue *queue, unsigned int
> offset)
> {
> struct list_head *request;
>
> @@ -707,7 +707,14 @@ struct crypto_async_request
> *crypto_dequeue_request(struct crypto_queue *queue)
> request = queue->list.next;
> list_del(request);
>
> -return list_entry(request, struct crypto_async_request, list);
> +return (char *)list_entry(request, struct crypto_async_request, list) -
> + offset;
> +}
> +EXPORT_SYMBOL_GPL(__crypto_dequeue_request);
> +
> +struct crypto_async_request *crypto_dequeue_request(struct crypto_queue
> *queue)
> +{
> +return __crypto_dequeue_request(queue, 0);
> }
> EXPORT_SYMBOL_GPL(crypto_dequeue_request);
>
> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
> index 0105454..5a2bd1c 100644
> --- a/include/crypto/algapi.h
> +++ b/include/crypto/algapi.h
> @@ -137,6 +137,7 @@ struct crypto_instance *crypto_a
[PATCH 2/2] crypto: pcrypt - Add pcrypt crypto parallelization wrapper
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
---
crypto/Kconfig| 13 ++
crypto/Makefile |2 +
crypto/pcrypt.c | 409 +
crypto/pcrypt_core.c | 106
include/crypto/pcrypt.h | 51 ++
include/linux/interrupt.h |2 +
6 files changed, 583 insertions(+), 0 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 7623442..dbb1ec0 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -114,6 +114,19 @@ config CRYPTO_NULL
help
These are 'Null' algorithms, used by IPsec, which do nothing.
+config CRYPTO_PCRYPT_CORE
+ bool
+
+config CRYPTO_PCRYPT
+ tristate "Parallel crypto engine (EXPERIMENTAL)"
+ depends on USE_GENERIC_SMP_HELPERS && EXPERIMENTAL
+ select CRYPTO_MANAGER
+ select CRYPTO_PCRYPT_CORE
+ select CRYPTO_AEAD
+ 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 c2ca721..48345da 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -55,6 +55,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..26b6ec1
--- /dev/null
+++ b/crypto/pcrypt.c
@@ -0,0 +1,409 @@
+/*
+ * pcrypt - Parallel crypto wrapper.
+ *
+ * Copyright (C) 2009 secunet Security Networks AG
+ * Copyright (C) 2009 Steffen Klassert
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pcrypt_instance_ctx {
+ struct crypto_spawn spawn;
+ unsigned int tfm_count;
+};
+
+struct pcrypt_aead_ctx {
+ struct crypto_aead *child;
+ 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_index, num_cpus, cb_cpu;
+
+ num_cpus = padata_cpumask_weight(padata_nr);
+ if (!num_cpus)
+ return 0;
+
+ cpu_index = tfm_nr % num_cpus;
+
+ cb_cpu = padata_index_to_cpu(padata_nr, cpu_index);
+
+ 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 pcrypt_aead_ctx *ctx = crypto_aead_ctx(parent);
+
+ return crypto_aead_setkey(ctx->child, key, keylen);
+}
+
+static int pcrypt_aead_setauthsize(struct crypto_aead *parent,
+ unsigned int authsize)
+{
+ struct pcrypt_aead_ctx *ctx = crypto_aead_ctx(parent);
+
+ return crypto_aead_setauthsize(ctx->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 *req = areq->data;
+ struct pcrypt_request *preq = aead_request_ctx(req);
+ struct padata_priv *padata = pcrypt_request_padata(preq);
+
+ padata->info = err;
+ req->base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
+
[PATCH 1/2] 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.
Signed-off-by: Steffen Klassert
---
include/linux/interrupt.h |3 +-
include/linux/padata.h| 121 +++
kernel/Makefile |2 +-
kernel/padata.c | 519 +
kernel/softirq.c |2 +-
5 files changed, 644 insertions(+), 3 deletions(-)
create mode 100644 include/linux/padata.h
create mode 100644 kernel/padata.c
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 35e7df1..b648cca 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -347,7 +347,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
};
diff --git a/include/linux/padata.h b/include/linux/padata.h
new file mode 100644
index 000..a81161d
--- /dev/null
+++ b/include/linux/padata.h
@@ -0,0 +1,121 @@
+/*
+ * padata.h - header for the padata parallelization interface
+ *
+ * Copyright (C) 2008, 2009 secunet Security Networks AG
+ * Copyright (C) 2008, 2009 Steffen Klassert
+ *
+ * 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.
+ */
+
+#ifndef PADATA_H
+#define PADATA_H
+
+#include
+#include
+#include
+
+enum
+{
+ NO_PADATA=0,
+ AEAD_ENC_PADATA,
+ AEAD_DEC_PADATA,
+ NR_PADATA
+};
+
+struct padata_priv {
+ struct list_headlist;
+ struct call_single_data csd;
+ int cb_cpu;
+ int seq_nr;
+ unsigned intnr;
+ int info;
+ void(*parallel)(struct padata_priv *padata);
+ void(*serial)(struct padata_priv *padata);
+};
+
+struct padata_queue {
+ struct list_headlist;
+ atomic_tnum_obj;
+ int cpu_index;
+ spinlock_t lock;
+};
+
+struct parallel_data {
+ struct work_struct work;
+ struct padata_queue *queue;
+ atomic_tseq_nr;
+ atomic_tqueued_objects;
+ cpumask_var_t cpumask;
+ cpumask_var_t new_cpumask;
+ u8 flags;
+#definePADATA_INIT 1
+#definePADATA_FLUSH_HARD 2
+#definePADATA_RESET_IN_PROGRESS4
+ spinlock_t lock;
+};
+
+#ifdef CONFIG_USE_GENERIC_SMP_HELPERS
+extern void __init padata_init(unsigned int nr, const struct cpumask *cpumask);
+extern void padata_dont_wait(unsigned int nr, struct padata_priv *padata);
+extern int padata_do_parallel(unsigned int softirq_nr, unsigned int nr,
+ struct padata_priv *padata, int cb_cpu);
+extern int padata_do_serial(unsigned int nr, struct padata_priv *padata);
+extern int padata_cpumask_weight(unsigned int nr);
+extern int padata_index_to_cpu(unsigned int nr, int cpu_index);
+extern void padata_set_cpumask(unsigned int nr, cpumask_var_t cpumask);
+extern void padata_add_cpu(unsigned int nr, int cpu);
+extern void padata_remove_cpu(unsigned int nr, int cpu);
+extern void padata_start(unsigned int nr);
+extern void padata_stop(unsigned int nr);
+#else
+static inline void padata_init(unsigned int nr, const struct cpumask *cpumask)
+{
+}
+static inline void padata_dont_wait(unsigned int nr, struct padata_priv
*padata)
+{
+}
+static inline int padata_do_parallel(unsigned int softirq_nr, unsigned int nr,
+struct padata_priv *padata, int cb_cpu)
+{
+ return 0;
+}
+static inline int padata_do_serial(unsigned int nr, struct padata_priv *padata)
+{
+ return 0;
+}
+static inline int padata_cpumask_weight(unsigned int nr)
+{
+ return 0;
+}
+static inline int padata_index_to_cpu(unsigned int nr, int cpu_index)
+{
+ return -ENOSYS;
+}
+static inline void padata_set_cpumask(unsigned int nr, cpumask_var_t cpumask)
+{
+}
+static inline padata_add_cpu(unsigned int nr, int cp
[PATCH 0/2] Parallel crypto/IPsec v5
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 v4: - Use the dynamic percpu allocator - Drop of the obsolete eseqiv changes (eseqiv is the default IV generator for blockcipher algorithms on smp machines now). 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. 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
Re: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Mon, Aug 31, 2009 at 03:58:16PM +1000, Herbert Xu wrote: > > In fact it was being instantiated, it was just getting killed > immediately after completing its self-test :) > > Please let me know if this fixes it for you. > Yes, it fixes it. Thanks a lot! So pcrypt would be ready to use from my point of view. I'll send a next version of pcrypt and padata later. -- 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
