kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/crypto/chainiv.c

317 lines
7.6 KiB
Raw Permalink Normal View History

[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: skcipher - Use RNG interface instead of get_random_bytes This patch makes the IV generators use the new RNG interface so that the user can pick an RNG other than the default get_random_bytes. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-14 22:21:31 +10:00
crypto: chainiv - Use kcrypto_wq instead of keventd_wq keventd_wq has potential starvation problem, so use dedicated kcrypto_wq instead. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-19 14:44:02 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: chainiv - Move IV seeding into init function We currently do the IV seeding on the first givencrypt call in order to conserve entropy. However, this does not work with DRBG which cannot be called from interrupt context. In fact, with DRBG we don't need to conserve entropy anyway. So this patch moves the seeding into the init function. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-03 14:49:23 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: chainiv - Move IV seeding into init function We currently do the IV seeding on the first givencrypt call in order to conserve entropy. However, this does not work with DRBG which cannot be called from interrupt context. In fact, with DRBG we don't need to conserve entropy anyway. So this patch moves the seeding into the init function. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-03 14:49:23 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Invoke completion function When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-07-10 17:42:36 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
arch: Mass conversion of smp_mb__*() Mostly scripted conversion of the smp_mb__* barriers. Signed-off-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-arch@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-03-17 18:06:10 +01:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Use kcrypto_wq instead of keventd_wq keventd_wq has potential starvation problem, so use dedicated kcrypto_wq instead. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2009-02-19 14:44:02 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Invoke completion function When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-07-10 17:42:36 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Invoke completion function When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-07-10 17:42:36 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Invoke completion function When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-07-10 17:42:36 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
crypto: use ERR_CAST Replace PTR_ERR followed by ERR_PTR by ERR_CAST, to be more concise. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression err,x; @@ - err = PTR_ERR(x); if (IS_ERR(x)) - return ERR_PTR(err); + return ERR_CAST(x); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-01-22 12:29:26 +01:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
[CRYPTO] chainiv: Avoid lock spinning where possible This patch makes chainiv avoid spinning by postponing requests on lock contention if the user allows the use of asynchronous algorithms. If a synchronous algorithm is requested then we behave as before. This should improve IPsec performance on SMP when two CPUs attempt to transmit over the same SA. Currently one of them will spin doing nothing waiting for the other CPU to finish its encryption. This patch makes it postpone the request and get on with other work. If only one CPU is transmitting for a given SA, then we will process the request synchronously as before. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-12-14 22:28:14 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: chainiv - Offer normal cipher functionality without RNG The RNG may not be available during early boot, e.g., the relevant modules may not be included in the initramfs. As the RNG Is only needed for IPsec, we should not let this prevent use of ciphers without IV generators, e.g., for disk encryption. This patch postpones the RNG allocation to the init function so that one failure during early boot does not make the RNG unavailable for all subsequent users of the same cipher. More importantly, it lets the cipher live even if RNG allocation fails. Of course we no longer offer IV generation and which will fail with an error if invoked. But all other cipher capabilities will function as usual. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-21 19:11:46 +08:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: skcipher - Move IV generators into their own modules This patch moves the default IV generators into their own modules in order to break a dependency loop between cryptomgr, rng, and blkcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-17 18:04:30 +10:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: skcipher - Move IV generators into their own modules This patch moves the default IV generators into their own modules in order to break a dependency loop between cryptomgr, rng, and blkcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-17 18:04:30 +10:00
[CRYPTO] chainiv: Add chain IV generator The chain IV generator is the one we've been using in the IPsec stack. It simply starts out with a random IV, then uses the last block of each encrypted packet's cipher text as the IV for the next packet. It can only be used by synchronous ciphers since we have to make sure that we don't start the encryption of the next packet until the last one has completed. It does have the advantage of using very little CPU time since it doesn't have to generate anything at all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-27 23:17:23 +08:00
crypto: skcipher - Move IV generators into their own modules This patch moves the default IV generators into their own modules in order to break a dependency loop between cryptomgr, rng, and blkcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-08-17 18:04:30 +10:00
crypto: include crypto- module prefix in template This adds the module loading prefix "crypto-" to the template lookup as well. For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly includes the "crypto-" prefix at every level, correctly rejecting "vfat": net-pf-38 algif-hash crypto-vfat(blowfish) crypto-vfat(blowfish)-all crypto-vfat Reported-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-11-24 16:32:38 -08:00