[PATCH] crypto: Unlink and free instances when deleted
We leak the crypto instance when we unregister an instance with
crypto_del_alg(). Therefore we introduce crypto_unregister_instance()
to unlink the crypto instance from the template's instances list and
to free the recources of the instance properly.
Signed-off-by: Steffen Klassert steffen.klass...@secunet.com
---
crypto/algapi.c | 29 +
crypto/crypto_user.c|2 +-
include/crypto/algapi.h |1 +
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 54dd4e3..9d4a9fe 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -518,6 +518,35 @@ err:
}
EXPORT_SYMBOL_GPL(crypto_register_instance);
+int crypto_unregister_instance(struct crypto_alg *alg)
+{
+ int err;
+ struct crypto_instance *inst = (void *)alg;
+ struct crypto_template *tmpl = inst-tmpl;
+ LIST_HEAD(users);
+
+ if (!(alg-cra_flags CRYPTO_ALG_INSTANCE))
+ return -EINVAL;
+
+ BUG_ON(atomic_read(alg-cra_refcnt) != 1);
+
+ down_write(crypto_alg_sem);
+
+ hlist_del_init(inst-list);
+ err = crypto_remove_alg(alg, users);
+
+ up_write(crypto_alg_sem);
+
+ if (err)
+ return err;
+
+ tmpl-free(inst);
+ crypto_remove_final(users);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_instance);
+
int crypto_init_spawn(struct crypto_spawn *spawn, struct crypto_alg *alg,
struct crypto_instance *inst, u32 mask)
{
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index 0605a2b..3ba6ef5 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -298,7 +298,7 @@ static int crypto_del_alg(struct sk_buff *skb, struct
nlmsghdr *nlh,
if (atomic_read(alg-cra_refcnt) != 1)
return -EBUSY;
- return crypto_unregister_alg(alg);
+ return crypto_unregister_instance(alg);
}
static int crypto_add_alg(struct sk_buff *skb, struct nlmsghdr *nlh,
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index ecc721d..418d270 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -134,6 +134,7 @@ struct crypto_template *crypto_lookup_template(const char
*name);
int crypto_register_instance(struct crypto_template *tmpl,
struct crypto_instance *inst);
+int crypto_unregister_instance(struct crypto_alg *alg);
int crypto_init_spawn(struct crypto_spawn *spawn, struct crypto_alg *alg,
struct crypto_instance *inst, u32 mask);
--
1.7.0.4
--
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: Add IPSec IP Range in Linux kernel
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote: Hello! Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation. It'd be even better if you could write a patch for us to review. Cheers, -PJ I was a little not so put it:) I'd certainly be happy and he would write a patch, but I'm afraid do not have the necessary knowledge to implement IPSec Linux. I turned to you, the developers, but rather to urge you to implement this feature using IP range. I hope very much for your help and support. This is especially beneficial for all - the Linux kernel will be more flexible and more compatible with different devices and software. Regards Daniil Stolnikov -- 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: Add IPSec IP Range in Linux kernel
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr peter.p.waskiewicz...@intel.com wrote: On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote: Hello! Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation. It'd be even better if you could write a patch for us to review. oh, come on! changing addr_match() is trivial for ipv4 and easy for ipv6. :-) -- 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: Add IPSec IP Range in Linux kernel
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr peter.p.waskiewicz...@intel.com wrote: On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote: Hello! Found that the stack IPSec in Linux does not support any IP range. Many people ask this question. The archives say strongswan said that their daemon supports a range, but the Linux IPSec stack supports only the subnets. I am writing to you to implement support for IP range in Linux. I think that a lot more people will appreciate this innovation. It'd be even better if you could write a patch for us to review. oh, come on! changing addr_match() is trivial for ipv4 and easy for ipv6. :-) Is not entirely clear how this function works. It seems that it works again with the subnet bits and comparing the length of the prefix networks. Probably you mean that you need to add back the comparison ranges? If so, what if we use zywall we do not know the format of the range. Well, as I said, I badly oriented in the kernel code. I can tell kettle. A change in the function code certainly entail a change in at least the data types passed to the function. -- 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: Add IPSec IP Range in Linux kernel
From: Daniil Stolnikov danila...@mail.ru Date: Tue, 08 Nov 2011 12:40:13 +0400 I turned to you, the developers, but rather to urge you to implement this feature using IP range. This won't be implemented, the keys used for IPSEC rule lookups supported by the kernel are already way too complex. From: Alexey Dobriyan adobri...@gmail.com Date: Tue, 8 Nov 2011 14:08:24 +0200 changing addr_match() is trivial for ipv4 and easy for ipv6. :-) No, this is not happening. This added complexity screws up all the hash table and lookup optimizations we have in the XFRM layer. I never imagined that it will cause some difficulties. Several questions arise: 1) How complex is this implementation? 2) How to do this time? 3) Will this feature is implemented vsetaki? If so, how soon and what will it take? Ranges can be synthesized by userspace, and that's the way it has to be supported. That is, you want to say that all this can be done at the user level? How so? In general, if there are alternative implementations of this feature without support at the kernel level? What are some loopholes, tricks? It is meant to create multiple connections to the same subnet subranges without the use of masks such as / 29. Perhaps this can be achieved through l2tp? There, in the present setup IP range. Or is it both? -- 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: talitos - fix descriptor buffer access code
On Tue, 8 Nov 2011 19:34:57 -0600 Kim Phillips kim.phill...@freescale.com wrote: commit 3e721ae (crypto: talitos - handle descriptor not found in error path) used the wrong offset method to access a channel's descriptor buffer registers - the TALITOS_DESCBUF macro doesn't take a channel argument. Fix it to use the base chan[x].reg offset instead. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- scratch this - I got confused working on a merge branch. existing code is fine - ignore me. Kim -- 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: Add IPSec IP Range in Linux kernel
From: Daniil Stolnikov danila...@mail.ru Date: Wed, 9 Nov 2011 09:36:07 +0800 I never imagined that it will cause some difficulties. Ever feature has side effects and costs associated with it. Some of which can be non-trivial. Like I said, if you want address ranges, ask the userland IPSEC daemon authors to synthesize it. I'm really not able to devote the time necessary to explain every nuance of how we store IPSEC rules in the kernel side database and what implications that has for expanding the kind of match keys we support. -- 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: Add IPSec IP Range in Linux kernel
David Miller da...@davemloft.net wrote: Like I said, if you want address ranges, ask the userland IPSEC daemon authors to synthesize it. Alternatively you can do this with marking and use netfilter to set the mark. Cheers, -- Email: Herbert Xu 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: Add IPSec IP Range in Linux kernel
Like I said, if you want address ranges, ask the userland IPSEC daemon authors to synthesize it. In this letter, the mailing list http://marc.info/?l=strongswan-usersm=130613736616488w=4 strongswan-users say that their product has support for IP ranges, but the stack of Linux is based on network masks. So I do not understand how this would work without the support at the kernel level? How will coordination of policies? -- 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: Add IPSec IP Range in Linux kernel
Herbert Xu herb...@gondor.apana.org.au wrote: Alternatively you can do this with marking and use netfilter to set the mark. Cheers, We focus on connections to devices zywall. If you choose to zywall IP range as the remote side will not harmonize policies. The connection is not established. And this alternative makes no sense. Regards Daniil Stolnikov -- 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: Add IPSec IP Range in Linux kernel
Daniil Stolnikov danila...@mail.ru wrote: Like I said, if you want address ranges, ask the userland IPSEC daemon authors to synthesize it. In this letter, the mailing list http://marc.info/?l=strongswan-usersm=130613736616488w=4 strongswan-users say that their product has support for IP ranges, but the stack of Linux is based on network masks. So I do not understand how this would work without the support at the kernel level? How will coordination of policies? Simple, you break a range policy into parts that can be expressed as network/mask and install multiple policies. The actual policies in the kernel just has to have the same effect as the one you negotiated with the other side, it does not have to look the same. This is also why you can do the same thing with masks + netfilter. Cheers, -- Email: Herbert Xu 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 00/18] crypto: Add helper functions for parallelized LRW and XTS modes
On Tue, Oct 18, 2011 at 01:32:08PM +0300, Jussi Kivilinna wrote: This series adds lrw_crypt() and xts_crypt() functions for cipher implementations that can benefit from parallel cipher block operations. To make interface flexible, caller is reponsible of allocating buffer large enough to store temporary cipher blocks. This buffer size should be as large as size of parallel blocks processed at once. Cryption callback is called with buffer size at maximum of parallel blocks size and at minimum size of one block. Series adds LRW/XTS support to serpent-sse2 and twofish-x86_64-3way, and therefore depends on those series. Patches 1-4: include LRW fixes/cleanups, export gf128mul table and add lrw_crypt(). Patches 5-7: add LRW support to serpent-sse2, with tcrypt tests and test vectors. Patches 8-10: add LRW support to twofish-x86_64-3way, with tcrypt tests and test vectors. Patches 11-12: include XTS cleanup for blocksize usage and add xts_crypt(). Patches 13-15: add XTS support to serpent-sse2, with tcrypt tests and test vectors. Patches 16-18: add XTS support to twofish-x86_64-3way, with tcrypt tests and test vectors. All applied except for the serpent patches. Please resend those after you've fixed up the previous serpent patches. I've also merged your later fixes into these. Thanks, -- Email: Herbert Xu 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][RESEND] fix typo in crypto/Kconfig
On Mon, Nov 07, 2011 at 01:51:51AM -0500, valdis.kletni...@vt.edu wrote: (Sent this a while back, I don't see it in next-2004, so resending) Fix a typo in the Kconfig file help text. Signed-off-by: Valdis Kletnieks valdis.kletni...@vt.edu Your patch still does not apply: $ git apply ~/p error: patch failed: crypto/Kconfig:104 error: crypto/Kconfig: patch does not apply $ Thanks, -- Email: Herbert Xu 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: Small spelling correction for Kconfig CRYPTO_USER
On Sun, Nov 06, 2011 at 10:41:44AM +0100, Jörg Sommer wrote: Signed-off-by: Jörg Sommer jo...@alea.gnuu.de Your patch doesn't apply against my tree: error: patch failed: crypto/Kconfig:104 error: crypto/Kconfig: patch does not apply Patch failed at 0001. When you have resolved this problem run git-am --resolved. If you would prefer to skip this patch, instead run git-am --skip. Thanks, -- Email: Herbert Xu 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 v2] ansi_cprng: enforce key != seed in fips mode
On Fri, Nov 04, 2011 at 11:25:13AM -0400, Neil Horman wrote: On Fri, Nov 04, 2011 at 10:01:25AM -0400, Jarod Wilson wrote: Apparently, NIST is tightening up its requirements for FIPS validation with respect to RNGs. Its always been required that in fips mode, the ansi cprng not be fed key and seed material that was identical, but they're now interpreting FIPS 140-2, section AS07.09 as requiring that the implementation itself must enforce the requirement. Easy fix, we just do a memcmp of key and seed in fips_cprng_reset and call it a day. v2: Per Neil's advice, ensure slen is sufficiently long before we compare key and seed to avoid looking at potentially unallocated mem. CC: Neil Horman nhor...@tuxdriver.com CC: Stephan Mueller smuel...@atsec.com CC: Steve Grubb sgr...@redhat.com Signed-off-by: Jarod Wilson ja...@redhat.com Thanks Jarod. Adding Herbert to the cc list so he can pull this into the crypto tree. Acked-by: Neil Horman nhor...@tuxdriver.com Patch applied. Jarod, please cc me in future for patches. Thanks! -- Email: Herbert Xu 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: Add IPSec IP Range in Linux kernel
Simple, you break a range policy into parts that can be expressed as network/mask and install multiple policies. The actual policies in the kernel just has to have the same effect as the one you negotiated with the other side, it does not have to look the same. This is also why you can do the same thing with masks + netfilter. Cheers, Please describe in detail, including the schema and sample configuration files! The fact that I have already tried some options and I did not. Here is a link to a Russian-language correspondence on my problem: http://www.opennet.ru/openforum/vsluhforumID10/4941.html. Once again, draw a diagram of which should be implemented: (server) (client 1) ___ ___ | | | |---192.168.7.1 | | | |---192.168.7.2 192.168.1.0/24---| |192.168.5.1/24192.168.5.2/24| |---192.168.7.3 | | | | |---192.168.7.4 |__| | |__|---192.168.7.5 | | (client 2) | ___ | | |---192.168.7.6 | | |---192.168.7.7 ---192.168.5.3/24| |---192.168.7.8 | | |---192.168.7.9 | |__|---192.168.7.10 | | (client 3) | ___ | | |---192.168.7.11 | | |---192.168.7.12 ---192.168.5.4/24| |---192.168.7.13 | |---192.168.7.14 |__|---192.168.7.15 Tried to do the following: 1) network to host. The connection of course been established, but not all traffic be encrypted. 2) host to host. similarly to 1. 3) network to IP range. I tried different configurations, but the connection did not succeed. So I came to the conclusion that when we point to the IP range zywall IPSec we actually prescribe what kind of traffic will be encrypted. The rest will be routed but no encryption. Correct if I'm wrong. If you are not working hard to lay out the configuration files! -- 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
