| Message ID | 20131024124149.GA10587@gondor.apana.org.au |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Thu, Oct 24, 2013 at 08:41:49PM +0800, Herbert Xu wrote: > Hi: > > Previously we would use eseqiv on all async ciphers in all cases, > and sync ciphers if we have more than one CPU. This meant that > chainiv is only used in the case of sync ciphers on a UP machine. > > As chainiv may aid attackers by making the IV predictable, even > though this risk itself is small, the above usage pattern causes > it to further leak information about the host. > > This patch addresses these issues by using eseqiv even if we're > on a UP machine. > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > That's fine by me. Acked-by: Steffen Klassert <steffen.klassert@secunet.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steffen Klassert <steffen.klassert@secunet.com> Date: Fri, 25 Oct 2013 08:50:49 +0200 > On Thu, Oct 24, 2013 at 08:41:49PM +0800, Herbert Xu wrote: >> Hi: >> >> Previously we would use eseqiv on all async ciphers in all cases, >> and sync ciphers if we have more than one CPU. This meant that >> chainiv is only used in the case of sync ciphers on a UP machine. >> >> As chainiv may aid attackers by making the IV predictable, even >> though this risk itself is small, the above usage pattern causes >> it to further leak information about the host. >> >> This patch addresses these issues by using eseqiv even if we're >> on a UP machine. >> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> >> > > That's fine by me. > > Acked-by: Steffen Klassert <steffen.klassert@secunet.com> I'm ok with this too: Acked-by: David S. Miller <davem@davemloft.net> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/crypto/ablkcipher.c +++ b/crypto/ablkcipher.c @@ -16,9 +16,7 @@ #include <crypto/internal/skcipher.h> #include <linux/cpumask.h> #include <linux/err.h> -#include <linux/init.h> #include <linux/kernel.h> -#include <linux/module.h> #include <linux/rtnetlink.h> #include <linux/sched.h> #include <linux/slab.h> @@ -30,8 +28,6 @@ #include "internal.h" -static const char *skcipher_default_geniv __read_mostly; - struct ablkcipher_buffer { struct list_head entry; struct scatter_walk dst; @@ -527,8 +523,7 @@ const char *crypto_default_geniv(const struct crypto_alg *alg) alg->cra_blocksize) return "chainiv"; - return alg->cra_flags & CRYPTO_ALG_ASYNC ? - "eseqiv" : skcipher_default_geniv; + return "eseqiv"; } static int crypto_givcipher_default(struct crypto_alg *alg, u32 type, u32 mask) @@ -709,17 +704,3 @@ err: return ERR_PTR(err); } EXPORT_SYMBOL_GPL(crypto_alloc_ablkcipher); - -static int __init skcipher_module_init(void) -{ - skcipher_default_geniv = num_possible_cpus() > 1 ? - "eseqiv" : "chainiv"; - return 0; -} - -static void skcipher_module_exit(void) -{ -} - -module_init(skcipher_module_init); -module_exit(skcipher_module_exit);
Hi: Previously we would use eseqiv on all async ciphers in all cases, and sync ciphers if we have more than one CPU. This meant that chainiv is only used in the case of sync ciphers on a UP machine. As chainiv may aid attackers by making the IV predictable, even though this risk itself is small, the above usage pattern causes it to further leak information about the host. This patch addresses these issues by using eseqiv even if we're on a UP machine. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c index 7d4a8d2..40886c4 100644 Cheers,