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
Re: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Wed, Aug 19, 2009 at 09:15:49AM +0200, Steffen Klassert wrote:
>
> Any ideas why it's not possible to instantiate pcrypt?
Sorry for the late response.
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.
commit 2bf2901669a564b402cd0e40eb3f941c391e64c4
Author: Herbert Xu
Date: Mon Aug 31 15:56:54 2009 +1000
crypto: api - Do not displace newly registered algorithms
We have a mechanism where newly registered algorithms of a higher
priority can displace existing instances that use a different
implementation of the same algorithm with a lower priority.
Unfortunately the same mechanism can cause a newly registered
algorithm to displace itself if it depends on an existing version
of the same algorithm.
This patch fixes this by keeping all algorithms that the newly
reigstered algorithm depends on, thus protecting them from being
removed.
Signed-off-by: Herbert Xu
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 6a98076..feb77e4 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -81,16 +81,35 @@ static void crypto_destroy_instance(struct crypto_alg *alg)
crypto_tmpl_put(tmpl);
}
+static struct list_head *crypto_more_spawns(struct crypto_alg *alg,
+ struct list_head *stack,
+ struct list_head *top,
+ struct list_head *secondary_spawns)
+{
+ struct crypto_spawn *spawn, *n;
+
+ if (list_empty(stack))
+ return NULL;
+
+ spawn = list_first_entry(stack, struct crypto_spawn, list);
+ n = list_entry(spawn->list.next, struct crypto_spawn, list);
+
+ if (spawn->alg && &n->list != stack && !n->alg)
+ n->alg = (n->list.next == stack) ? alg :
+&list_entry(n->list.next, struct crypto_spawn,
+list)->inst->alg;
+
+ list_move(&spawn->list, secondary_spawns);
+
+ return &n->list == stack ? top : &n->inst->alg.cra_users;
+}
+
static void crypto_remove_spawn(struct crypto_spawn *spawn,
- struct list_head *list,
- struct list_head *secondary_spawns)
+ struct list_head *list)
{
struct crypto_instance *inst = spawn->inst;
struct crypto_template *tmpl = inst->tmpl;
- list_del_init(&spawn->list);
- spawn->alg = NULL;
-
if (crypto_is_dead(&inst->alg))
return;
@@ -106,25 +125,55 @@ static void crypto_remove_spawn(struct crypto_spawn
*spawn,
hlist_del(&inst->list);
inst->alg.cra_destroy = crypto_destroy_instance;
- list_splice(&inst->alg.cra_users, secondary_spawns);
+ BUG_ON(!list_empty(&inst->alg.cra_users));
}
-static void crypto_remove_spawns(struct list_head *spawns,
-struct list_head *list, u32 new_type)
+static void crypto_remove_spawns(struct crypto_alg *alg,
+struct list_head *list,
+struct crypto_alg *nalg)
{
+ u32 new_type = (nalg ?: alg)->cra_flags;
struct crypto_spawn *spawn, *n;
LIST_HEAD(secondary_spawns);
+ struct list_head *spawns;
+ LIST_HEAD(stack);
+ LIST_HEAD(top);
+ spawns = &alg->cra_users;
list_for_each_entry_safe(spawn, n, spawns, list) {
if ((spawn->alg->cra_flags ^ new_type) & spawn->mask)
continue;
- crypto_remove_spawn(spawn, list, &secondary_spawns);
+ list_move(&spawn->list, &top);
}
- while (!list_empty(&secondary_spawns)) {
- list_for_each_entry_safe(spawn, n, &secondary_spawns, list)
- crypto_remove_spawn(spawn, list, &secondary_spawns);
+ spawns = ⊤
+ do {
+ while (!list_empty(spawns)) {
+ struct crypto_instance *inst;
+
+ spawn = list_first_entry(spawns, struct crypto_spawn,
+list);
+ inst = spawn->inst;
+
+ BUG_ON(&inst->alg == alg);
+
+ list_move(&spawn->list, &stack);
+
+ if (&inst->alg == nalg)
+ break;
+
+ spawn->alg = NULL;
+ spawns = &inst->alg.cra_users;
+ }
+ } while ((spawns = crypto_more_spawns(alg, &stack, &top,
+ &secondary_spawns)));
+
+ list_for_each_entry_safe(spawn, n, &secondary_spawns, list) {
+ if (spawn->alg)
+ list_move(&spawn->list, &spawn->alg->cra_users);
+ else
+ crypto_remove
Re: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Mon, Jun 29, 2009 at 03:52:57PM +0200, Steffen Klassert wrote: > On Mon, Jun 29, 2009 at 07:59:50PM +0800, Herbert Xu wrote: > > > > OK. Can you send me the patches you used against the current > > cryptodev tree (I only just pushed so give it an hour or so)? > > I'll see if I can reproduce it here. > > > > I'll send the remaining two patches in reply to this mail. > The strange thing is that I can instantiate pcrypt if the priority is > lower than the priority of authenc, but not if it's equal or higher. Any ideas why it's not possible to instantiate pcrypt? In between I updated padata to use the dynamic percpu allocator, so the instantiating of pcrypt is the last issue I know of for the moment. -- 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, Jun 29, 2009 at 07:59:50PM +0800, Herbert Xu wrote: > > OK. Can you send me the patches you used against the current > cryptodev tree (I only just pushed so give it an hour or so)? > I'll see if I can reproduce it here. > I'll send the remaining two patches in reply to this mail. The strange thing is that I can instantiate pcrypt if the priority is lower than the priority of authenc, but not if it's equal or higher. -- 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, Jun 29, 2009 at 01:04:10PM +0200, Steffen Klassert wrote:
>
> I applied your patch on top of the last pcrypt patchset, but
> unfortunately it does not change anything here.
>
> If I do
> modprobe tcrypt alg='pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))'
> type=3
>
> it instantiates
>
> authenc(hmac(sha1-generic),cbc(aes-generic))
>
> but not
>
> pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))
>
> regardless your patch applied or not.
OK. Can you send me the patches you used against the current
cryptodev tree (I only just pushed so give it an hour or so)?
I'll see if I can reproduce it here.
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Thu, Jun 25, 2009 at 02:51:12PM +0800, Herbert Xu wrote: > > OK, the patch I just posted to the list should fix the problem. > > I was able to test it suing > > modprobe tcrypt alg='pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))' > type=3 > I applied your patch on top of the last pcrypt patchset, but unfortunately it does not change anything here. If I do modprobe tcrypt alg='pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))' type=3 it instantiates authenc(hmac(sha1-generic),cbc(aes-generic)) but not pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic))) regardless your patch applied or not. -- 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, Jun 08, 2009 at 08:45:18AM +0200, Steffen Klassert wrote:
>
> Yes, I will send the full patchset including the tcrypt changes to
> instantiate pcrypt.
OK, the patch I just posted to the list should fix the problem.
I was able to test it suing
modprobe tcrypt alg='pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))'
type=3
Cheers,
--
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Mon, Jun 08, 2009 at 03:28:08PM +1000, Herbert Xu wrote: > On Fri, Jun 05, 2009 at 11:34:30AM +0200, Steffen Klassert wrote: > > > > In pcrypt_alloc_instance() I do > > inst->alg.cra_priority = alg->cra_priority + 100; > > > > So, in my case authenc has priority 2000 and pcrypt has priority 2100. > > In this case pcrypt is not instantiated if I use %s for pcrypt as > > cra_name. If I do > > inst->alg.cra_priority = alg->cra_priority - 100 > > it will be instantiated with priority 1900 but it will not be used > > because the priority of authenc is higher. > > > > So I did the priority check in crypto_alg_tested() the other way around. > > Then I can instantiate pcrypt with priority 2100 and I can use it. > > Can you send me a pcrypt patch that I can use to reproduce this? Yes, I will send the full patchset including the tcrypt changes to instantiate pcrypt. As the patchset is, I'm not able to instantiate pcrypt here. I need to either change the priority check in crypto_alg_tested() or to make pcrypt using a lower priority than authenc. > > The check modified is meant to replace instances of the same > implementation (i.e., you're replaceing aes-x86-64 with a newer > version of aes-x86-64). It should never do anything when you add > a different implementation of the same algorithm. > > So I'm surprised that you're seeing a difference when changing > that check. Because unless you're creating two pcrypt objects > with the same driver name, or your pcrypt object has the wrong > driver name, then this change should make no difference whatsoever. > I was just surprised that I was able to instantiate pcrypt if it has a lower priority than the underlying authenc algorithm. So I searched for priority checks like the one in crypto_alg_tested() and in fact changing this check got it to work as I described above. -- 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 Fri, Jun 05, 2009 at 11:34:30AM +0200, Steffen Klassert wrote:
>
> In pcrypt_alloc_instance() I do
> inst->alg.cra_priority = alg->cra_priority + 100;
>
> So, in my case authenc has priority 2000 and pcrypt has priority 2100.
> In this case pcrypt is not instantiated if I use %s for pcrypt as
> cra_name. If I do
> inst->alg.cra_priority = alg->cra_priority - 100
> it will be instantiated with priority 1900 but it will not be used
> because the priority of authenc is higher.
>
> So I did the priority check in crypto_alg_tested() the other way around.
> Then I can instantiate pcrypt with priority 2100 and I can use it.
Can you send me a pcrypt patch that I can use to reproduce this?
The check modified is meant to replace instances of the same
implementation (i.e., you're replaceing aes-x86-64 with a newer
version of aes-x86-64). It should never do anything when you add
a different implementation of the same algorithm.
So I'm surprised that you're seeing a difference when changing
that check. Because unless you're creating two pcrypt objects
with the same driver name, or your pcrypt object has the wrong
driver name, then this change should make no difference whatsoever.
Cheers,
--
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Fri, Jun 05, 2009 at 07:20:21PM +1000, Herbert Xu wrote: > On Fri, Jun 05, 2009 at 11:20:30AM +0200, Steffen Klassert wrote: > > > > As it is, I can instantiate pcrypt if the priority of pcrypt is lower > > than the priority of the underlying algorithm. If I do the priority > > check in crypto_alg_tested() the other way arround, I get it to work if > > pcrypt has a higher priority than the underlying algorithm. So I guess > > we need the patch below, right? If so, I would send a signed-off patch. > > Can you give me an example with actual numbers and what you expect > to happen? > In pcrypt_alloc_instance() I do inst->alg.cra_priority = alg->cra_priority + 100; So, in my case authenc has priority 2000 and pcrypt has priority 2100. In this case pcrypt is not instantiated if I use %s for pcrypt as cra_name. If I do inst->alg.cra_priority = alg->cra_priority - 100 it will be instantiated with priority 1900 but it will not be used because the priority of authenc is higher. So I did the priority check in crypto_alg_tested() the other way around. Then I can instantiate pcrypt with priority 2100 and I can use it. -- 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 Wed, Jun 03, 2009 at 09:59:31PM +1000, Herbert Xu wrote: > > When pcrypt instantiates an algorithm, it should set cra_name to > %s and cra_driver_name to pcrypt(%s). So as long as the pcrypt > priority is higher than the underlying algorithm, it should all > work. > As it is, I can instantiate pcrypt if the priority of pcrypt is lower than the priority of the underlying algorithm. If I do the priority check in crypto_alg_tested() the other way arround, I get it to work if pcrypt has a higher priority than the underlying algorithm. So I guess we need the patch below, right? If so, I would send a signed-off patch. diff --git a/crypto/algapi.c b/crypto/algapi.c index 56c62e2..2492e6c 100644 --- a/crypto/algapi.c +++ b/crypto/algapi.c @@ -255,7 +255,7 @@ found: continue; if (strcmp(alg->cra_driver_name, q->cra_driver_name) && - q->cra_priority > alg->cra_priority) + q->cra_priority < alg->cra_priority) continue; crypto_remove_spawns(&q->cra_users, &list, alg->cra_flags); -- 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 Fri, Jun 05, 2009 at 11:20:30AM +0200, Steffen Klassert wrote:
>
> As it is, I can instantiate pcrypt if the priority of pcrypt is lower
> than the priority of the underlying algorithm. If I do the priority
> check in crypto_alg_tested() the other way arround, I get it to work if
> pcrypt has a higher priority than the underlying algorithm. So I guess
> we need the patch below, right? If so, I would send a signed-off patch.
Can you give me an example with actual numbers and what you expect
to happen?
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Wed, Jun 03, 2009 at 02:14:35PM +0200, Steffen Klassert wrote:
>
> Aha, ok I see. So I will see whether I can instantiate pcrypt
> with tcrypt as you suggested and drop the wrapper from the next
> patchset.
It should be straightforward as you just need to call crypto_has_alg.
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Wed, Jun 03, 2009 at 09:59:31PM +1000, Herbert Xu wrote: > > When pcrypt instantiates an algorithm, it should set cra_name to > %s and cra_driver_name to pcrypt(%s). So as long as the pcrypt > priority is higher than the underlying algorithm, it should all > work. > > See for instance how cryptd does it. > Aha, ok I see. So I will see whether I can instantiate pcrypt with tcrypt as you suggested and drop the wrapper from the next patchset. Thanks! -- 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 Wed, Jun 03, 2009 at 01:23:53PM +0200, Steffen Klassert wrote:
> On Wed, Jun 03, 2009 at 07:40:50PM +1000, Herbert Xu wrote:
> >
> > I see. How about if we let tcrypt test algorithms by name, e.g.,
> > something like
> >
> > modprobe tcrypt alg='pcrypt(authenc(hmac(sha1),cbc(aes))'
> >
>
> I'm not that sure whether this does what I want.
>
> If pcrypt has cra_name = pcrypt(authenc(hmac(sha1),cbc(aes))) this
> would instatiate this algorithm, but esp wants an algorithm with
> cra_name = authenc(hmac(sha1),cbc(aes)).
> These names are not matching, so __crypto_alg_lookup() will not
> choose for the pcrypt version regardless of the higher priority.
When pcrypt instantiates an algorithm, it should set cra_name to
%s and cra_driver_name to pcrypt(%s). So as long as the pcrypt
priority is higher than the underlying algorithm, it should all
work.
See for instance how cryptd does it.
Cheers,
--
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Wed, Jun 03, 2009 at 07:40:50PM +1000, Herbert Xu wrote: > > I see. How about if we let tcrypt test algorithms by name, e.g., > something like > > modprobe tcrypt alg='pcrypt(authenc(hmac(sha1),cbc(aes))' > I'm not that sure whether this does what I want. If pcrypt has cra_name = pcrypt(authenc(hmac(sha1),cbc(aes))) this would instatiate this algorithm, but esp wants an algorithm with cra_name = authenc(hmac(sha1),cbc(aes)). These names are not matching, so __crypto_alg_lookup() will not choose for the pcrypt version regardless of the higher priority. Setting cra_name = authenc(hmac(sha1),cbc(aes)) for pcrypt seems to be not possible too, because pcrypt needs authenc as an underlain algorithm and the system will not load two aead algorithms with the same name. This was one of the reasons why I added a wrapper to authenc that is instantiated along with authenc. Is this the case or do I miss something? -- 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 Wed, Jun 03, 2009 at 11:32:16AM +0200, Steffen Klassert wrote:
>
> > So what I suggest is that you make pcrypt take a higher priority
> > for now, so that it always is the default once instantiated.
> > After all if you instantiate it then you probably want to use it
> > as the default.
>
> Yes, in fact the instantiating is my problem. E.g. esp asks for an
> authenc(...,...) algorithm, so the crypto manager tries to instantiate
> a template with name authenc. If I don't want to touch the network
> subsystem I can't change the name to pcrypt(authenc(...,...)) easy.
> So one solution was to add a default wrapper template arround authenc
> that will be instantiated along with authenc.
I see. How about if we let tcrypt test algorithms by name, e.g.,
something like
modprobe tcrypt alg='pcrypt(authenc(hmac(sha1),cbc(aes))'
which would simply call crypto_has_alg on the string alg?
That should instantiate alg, and test it too if there are vectors.
This is a new interface too, but at least it pretends to be
generic :)
Cheers,
--
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Tue, Jun 02, 2009 at 07:28:15PM +1000, Herbert Xu wrote: > On Tue, Jun 02, 2009 at 11:21:51AM +0200, Steffen Klassert wrote: > > > > The reason for the wrap work is to have a possibility to choose a > > certain version of an algorithm as the system default. The advantage > > e.g. for pcrypt is that we can turn over the whole system to pcrypt, > > or we can choose for pcrypt by the algorithm name if we want to use > > it just for a subset of transforms. In particular we have a possibility > > to use pcrypt without touching other subsystems (like networking) and > > userspace tools for now. > > Yes but what you're creating is a user-space API. IMHO we don't > want to have ad-hoc APIs such as this scattered around the place. > pcrypt is certainly not the only algorithm that needs to be able > to decide whether it should serve as the system default. Hm, I have not considered this as an user-space API. It just adds the possibility to wrap an arbitrary crypto template arround a given aead type algorithm, similar than aead_geniv wraps a IV generator template arround a nivaead type algorithm. The thing that connects this to user-space is the authenc patch by adding the possibility to set a wrapper name with a module parameter. This is probaply such an ad-hoc API that you want to avoid, right? > > So what I suggest is that you make pcrypt take a higher priority > for now, so that it always is the default once instantiated. > After all if you instantiate it then you probably want to use it > as the default. Yes, in fact the instantiating is my problem. E.g. esp asks for an authenc(...,...) algorithm, so the crypto manager tries to instantiate a template with name authenc. If I don't want to touch the network subsystem I can't change the name to pcrypt(authenc(...,...)) easy. So one solution was to add a default wrapper template arround authenc that will be instantiated along with authenc. I'm not insisting on that wap work. I just want to have a easy possibility to instantiate pcrypt on the users choice for now, at best without the need to touch other subsystems. -- 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 Tue, Jun 02, 2009 at 11:21:51AM +0200, Steffen Klassert wrote:
>
> The reason for the wrap work is to have a possibility to choose a
> certain version of an algorithm as the system default. The advantage
> e.g. for pcrypt is that we can turn over the whole system to pcrypt,
> or we can choose for pcrypt by the algorithm name if we want to use
> it just for a subset of transforms. In particular we have a possibility
> to use pcrypt without touching other subsystems (like networking) and
> userspace tools for now.
Yes but what you're creating is a user-space API. IMHO we don't
want to have ad-hoc APIs such as this scattered around the place.
pcrypt is certainly not the only algorithm that needs to be able
to decide whether it should serve as the system default.
So what I suggest is that you make pcrypt take a higher priority
for now, so that it always is the default once instantiated.
After all if you instantiate it then you probably want to use it
as the default.
We can then work on the generic user-space API to control crypto
API algorithms, in particular, allow the user to change their
priorities so as to determine the system default.
This has been on my todo list for years, but it has never risen
to the top. What I have in mind is a netlink protocol not unlike
xfrm which controls crypto algorithm properties (and queries them
so we can obsolete /proc/crypto).
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Tue, Jun 02, 2009 at 01:50:41PM +1000, Herbert Xu wrote: > > Hmm, it seems that this patch is completely intertwined into the > rest of the patches so we can't just kill it. Can you elaborate > on the rationale behind this wrap work? I'm curious to find out > what we gain by this over the much simpler patch you had in your > previous set. > The reason for the wrap work is to have a possibility to choose a certain version of an algorithm as the system default. The advantage e.g. for pcrypt is that we can turn over the whole system to pcrypt, or we can choose for pcrypt by the algorithm name if we want to use it just for a subset of transforms. In particular we have a possibility to use pcrypt without touching other subsystems (like networking) and userspace tools for now. -- 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 Wed, May 13, 2009 at 03:08:18PM +0200, Steffen Klassert wrote:
> This patch adds an interface to wrap aead algorithms with an
> arbitrary crypto template. This is useful to make a certain
> version of an aead algorithm the system default of that algorithm.
>
> Signed-off-by: Steffen Klassert
Hmm, it seems that this patch is completely intertwined into the
rest of the patches so we can't just kill it. Can you elaborate
on the rationale behind this wrap work? I'm curious to find out
what we gain by this over the much simpler patch you had in your
previous set.
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: [RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
On Wed, May 13, 2009 at 03:08:18PM +0200, Steffen Klassert wrote:
> This patch adds an interface to wrap aead algorithms with an
> arbitrary crypto template. This is useful to make a certain
> version of an aead algorithm the system default of that algorithm.
>
> Signed-off-by: Steffen Klassert
Sorry for the late response, but rather than making ad-hoc user
interfaces like this, I'd like this to be part of the crypto user-
space API where you should be able to configure the priorities
of each implementation which determines the system default.
Do we really need this patch right now? If not I think it could
be removed from this set so the others can go in first.
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
[RFC] [PATCH 2/5] aead: Add generic aead wrapper interface
This patch adds an interface to wrap aead algorithms with an
arbitrary crypto template. This is useful to make a certain
version of an aead algorithm the system default of that algorithm.
Signed-off-by: Steffen Klassert
---
crypto/aead.c | 286 +++-
include/crypto/internal/aead.h |8 +
include/linux/crypto.h | 10 +-
3 files changed, 295 insertions(+), 9 deletions(-)
diff --git a/crypto/aead.c b/crypto/aead.c
index d9aa733..f45e27a 100644
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -286,6 +286,7 @@ struct crypto_instance *aead_geniv_alloc(struct
crypto_template *tmpl,
inst->alg.cra_aead.ivsize = alg->cra_aead.ivsize;
inst->alg.cra_aead.maxauthsize = alg->cra_aead.maxauthsize;
inst->alg.cra_aead.geniv = alg->cra_aead.geniv;
+ inst->alg.cra_aead.wrapper = alg->cra_aead.wrapper;
inst->alg.cra_aead.setkey = alg->cra_aead.setkey;
inst->alg.cra_aead.setauthsize = alg->cra_aead.setauthsize;
@@ -407,6 +408,262 @@ out:
return err;
}
+static int crypto_init_wrapaead_ops(struct crypto_tfm *tfm, u32 type, u32 mask)
+{
+ struct aead_alg *alg = &tfm->__crt_alg->cra_aead;
+ struct aead_tfm *crt = &tfm->crt_aead;
+
+ if (max(alg->maxauthsize, alg->ivsize) > PAGE_SIZE / 8)
+ return -EINVAL;
+
+ crt->setkey = alg->setkey;
+ crt->encrypt = alg->encrypt;
+ crt->decrypt = alg->decrypt;
+ crt->givencrypt = alg->givencrypt ?: no_givcrypt;
+ crt->givdecrypt = alg->givdecrypt ?: no_givcrypt;
+ crt->base = __crypto_aead_cast(tfm);
+ crt->ivsize = alg->ivsize;
+ crt->authsize = alg->maxauthsize;
+
+ return 0;
+}
+
+static void crypto_wrapaead_show(struct seq_file *m, struct crypto_alg *alg)
+ __attribute__ ((unused));
+static void crypto_wrapaead_show(struct seq_file *m, struct crypto_alg *alg)
+{
+ struct aead_alg *aead = &alg->cra_aead;
+
+ seq_printf(m, "type : wrapped aead\n");
+ seq_printf(m, "async: %s\n", alg->cra_flags & CRYPTO_ALG_ASYNC ?
+"yes" : "no");
+ seq_printf(m, "blocksize: %u\n", alg->cra_blocksize);
+ seq_printf(m, "ivsize : %u\n", aead->ivsize);
+ seq_printf(m, "maxauthsize : %u\n", aead->maxauthsize);
+ seq_printf(m, "geniv: %s\n", aead->geniv ?: "");
+ seq_printf(m, "wrapper : %s\n", alg->cra_flags & CRYPTO_ALG_WRAP ?
+aead->wrapper : "");
+}
+
+const struct crypto_type crypto_wrapaead_type = {
+ .ctxsize = crypto_aead_ctxsize,
+ .init = crypto_init_wrapaead_ops,
+#ifdef CONFIG_PROC_FS
+ .show = crypto_wrapaead_show,
+#endif
+};
+EXPORT_SYMBOL_GPL(crypto_wrapaead_type);
+
+static int crypto_grab_wrapaead(struct crypto_aead_spawn *spawn,
+ const char *name, u32 type, u32 mask)
+{
+ struct crypto_alg *alg;
+ int err;
+
+ type &= ~(CRYPTO_ALG_TYPE_MASK | CRYPTO_ALG_WRAP);
+ type |= CRYPTO_ALG_TYPE_AEAD;
+ mask |= CRYPTO_ALG_TYPE_MASK | CRYPTO_ALG_WRAP;
+
+ alg = crypto_alg_mod_lookup(name, type, mask);
+ if (IS_ERR(alg))
+ return PTR_ERR(alg);
+
+ err = crypto_init_spawn(&spawn->base, alg, spawn->base.inst, mask);
+ crypto_mod_put(alg);
+ return err;
+}
+
+struct crypto_instance *aead_wrap_alloc(struct crypto_template *tmpl,
+struct rtattr **tb,
+unsigned int ctx_size, u32 type,
+u32 mask)
+{
+ const char *name;
+ struct crypto_aead_spawn *spawn;
+ struct crypto_attr_type *algt;
+ struct crypto_instance *inst;
+ struct crypto_alg *alg;
+ int err;
+
+ algt = crypto_get_attr_type(tb);
+ err = PTR_ERR(algt);
+ if (IS_ERR(algt))
+ return ERR_PTR(err);
+
+ if ((algt->type ^ (CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_WRAP)) &
+ algt->mask)
+ return ERR_PTR(-EINVAL);
+
+ name = crypto_attr_alg_name(tb[1]);
+ err = PTR_ERR(name);
+ if (IS_ERR(name))
+ return ERR_PTR(err);
+
+ inst = kzalloc(sizeof(*inst) + ctx_size, GFP_KERNEL);
+ if (!inst)
+ return ERR_PTR(-ENOMEM);
+
+ spawn = crypto_instance_ctx(inst);
+
+ /* Ignore async algorithms if necessary. */
+ mask |= crypto_requires_sync(algt->type, algt->mask);
+
+ crypto_set_aead_spawn(spawn, inst);
+ err = crypto_grab_wrapaead(spawn, name, type, mask);
+ if (err)
+ goto err_free_inst;
+
+ alg = crypto_aead_spawn_alg(spawn);
+
+ err = -EINVAL;
+ if (alg->cra_type != &crypto_aead_type)
+ goto err_drop_alg;
+
+ if (algt->mask & CRYPTO_ALG_WRAP) {
+ if (strcmp(tmpl->name, alg->cra_aead.wrapper))
+
