Re: Backporting ipv6: make fragment identifications less predictable

2011-09-11 Thread Ben Hutchings
On Sat, 2011-09-10 at 16:59 +0200, Eric Dumazet wrote:
 Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
  Is there any chance that this change could be backported to the 2.6.32.y
  longterm branch:
  
  commit 87c48fa3b4630905f98268dde838ee43626a060c
  Author: Eric Dumazet eric.duma...@gmail.com
  Date:   Thu Jul 21 21:25:58 2011 -0700
  
  ipv6: make fragment identifications less predictable
  
  I suspect that it's very much dependent on the earlier changes to dst
  and inetpeer, right?
  
  Ben.
  
 
 Hi Ben
 
 This was the fix meant for next kernels (= 3.1) , not suitable for a
 backport.
 
 I sent a patch for the backport, and David replied he would take care of
 stable submission.

However, he doesn't submit patches for 'longterm' series any more.

 He did so, since it was included in 3.0-stable tree (= 3.0.2)
 
 http://permalink.gmane.org/gmane.linux.kernel.stable/16086
 
 This one is far more easy to be included in old kernels ;)

Right.  So does this the following look right for 2.6.32?

By the way, use of a hash table the size of a cache line doesn't seem
likely to be much better than a spinlock.  Still, anyone who cares about
performance will avoid fragmentation since they are almost certainly
going to lose TX checksum offload.

Ben.

From: Eric Dumazet eric.duma...@gmail.com
Date: Mon, 8 Aug 2011 23:44:00 -0700
Subject: [PATCH] ipv6: make fragment identifications less predictable

[ Backport of upstream commit 87c48fa3b4630905f98268dde838ee43626a060c ]

Fernando Gont reported current IPv6 fragment identification generation
was not secure, because using a very predictable system-wide generator,
allowing various attacks.

IPv4 uses inetpeer cache to address this problem and to get good
performance. We'll use this mechanism when IPv6 inetpeer is stable
enough in linux-3.1

For the time being, we use jhash on destination address to provide less
predictable identifications. Also remove a spinlock and use cmpxchg() to
get better SMP performance.

Reported-by: Fernando Gont ferna...@gont.com.ar
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
[bwh: Backport further to 2.6.32]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 include/net/ipv6.h  |   12 +---
 include/net/transp_v6.h |2 ++
 net/ipv6/af_inet6.c |2 ++
 net/ipv6/ip6_output.c   |   40 +++-
 net/ipv6/udp.c  |2 +-
 5 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 639bbf0..52d86da 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -449,17 +449,7 @@ static inline int ipv6_addr_diff(const struct in6_addr 
*a1, const struct in6_add
return __ipv6_addr_diff(a1, a2, sizeof(struct in6_addr));
 }
 
-static __inline__ void ipv6_select_ident(struct frag_hdr *fhdr)
-{
-   static u32 ipv6_fragmentation_id = 1;
-   static DEFINE_SPINLOCK(ip6_id_lock);
-
-   spin_lock_bh(ip6_id_lock);
-   fhdr-identification = htonl(ipv6_fragmentation_id);
-   if (++ipv6_fragmentation_id == 0)
-   ipv6_fragmentation_id = 1;
-   spin_unlock_bh(ip6_id_lock);
-}
+extern void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt);
 
 /*
  * Prototypes exported by ipv6
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index d65381c..8beefe1 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -16,6 +16,8 @@ extern struct proto tcpv6_prot;
 
 struct flowi;
 
+extern void initialize_hashidentrnd(void);
+
 /* extention headers */
 extern int ipv6_exthdrs_init(void);
 extern voidipv6_exthdrs_exit(void);
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index e127a32..835590d 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -1073,6 +1073,8 @@ static int __init inet6_init(void)
goto out;
}
 
+   initialize_hashidentrnd();
+
err = proto_register(tcpv6_prot, 1);
if (err)
goto out;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index eca3ef7..43c31f9 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -604,6 +604,35 @@ int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
return offset;
 }
 
+static u32 hashidentrnd __read_mostly;
+#define FID_HASH_SZ 16
+static u32 ipv6_fragmentation_id[FID_HASH_SZ];
+
+void __init initialize_hashidentrnd(void)
+{
+   get_random_bytes(hashidentrnd, sizeof(hashidentrnd));
+}
+
+static u32 __ipv6_select_ident(const struct in6_addr *addr)
+{
+   u32 newid, oldid, hash = jhash2((u32 *)addr, 4, hashidentrnd);
+   u32 *pid = ipv6_fragmentation_id[hash % FID_HASH_SZ];
+
+   do {
+   oldid = *pid;
+   newid = oldid + 1;
+   if (!(hash + newid))
+   newid++;
+   } 

Re: Backporting ipv6: make fragment identifications less predictable

2011-09-11 Thread Eric Dumazet
Le dimanche 11 septembre 2011 à 14:52 +0100, Ben Hutchings a écrit :
 On Sat, 2011-09-10 at 16:59 +0200, Eric Dumazet wrote:
  Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
   Is there any chance that this change could be backported to the 2.6.32.y
   longterm branch:
   
   commit 87c48fa3b4630905f98268dde838ee43626a060c
   Author: Eric Dumazet eric.duma...@gmail.com
   Date:   Thu Jul 21 21:25:58 2011 -0700
   
   ipv6: make fragment identifications less predictable
   
   I suspect that it's very much dependent on the earlier changes to dst
   and inetpeer, right?
   
   Ben.
   
  
  Hi Ben
  
  This was the fix meant for next kernels (= 3.1) , not suitable for a
  backport.
  
  I sent a patch for the backport, and David replied he would take care of
  stable submission.
 
 However, he doesn't submit patches for 'longterm' series any more.
 
  He did so, since it was included in 3.0-stable tree (= 3.0.2)
  
  http://permalink.gmane.org/gmane.linux.kernel.stable/16086
  
  This one is far more easy to be included in old kernels ;)
 
 Right.  So does this the following look right for 2.6.32?
 

It seems fine at a first glance.

 By the way, use of a hash table the size of a cache line doesn't seem
 likely to be much better than a spinlock.  Still, anyone who cares about
 performance will avoid fragmentation since they are almost certainly
 going to lose TX checksum offload.
 

Well, its a security issue patch, not a performance fix anyway.

For optimum performances at this layer, the 3.0+ kernels are the way to
go ;)




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1315764199.3174.9.camel@edumazet-laptop



Re: Backporting ipv6: make fragment identifications less predictable

2011-09-10 Thread Eric Dumazet
Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
 Is there any chance that this change could be backported to the 2.6.32.y
 longterm branch:
 
 commit 87c48fa3b4630905f98268dde838ee43626a060c
 Author: Eric Dumazet eric.duma...@gmail.com
 Date:   Thu Jul 21 21:25:58 2011 -0700
 
 ipv6: make fragment identifications less predictable
 
 I suspect that it's very much dependent on the earlier changes to dst
 and inetpeer, right?
 
 Ben.
 

Hi Ben

This was the fix meant for next kernels (= 3.1) , not suitable for a
backport.

I sent a patch for the backport, and David replied he would take care of
stable submission.

He did so, since it was included in 3.0-stable tree (= 3.0.2)

http://permalink.gmane.org/gmane.linux.kernel.stable/16086

This one is far more easy to be included in old kernels ;)




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1315666786.2606.28.camel@edumazet-laptop