| Message ID | 1252700442.15292.62.camel@Joe-Laptop.home |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
On Fri, 11 Sep 2009 13:20:42 -0700 Joe Perches <joe@perches.com> wrote: > On Fri, 2009-09-11 at 12:15 -0700, David Miller wrote: > > From: Joe Perches <joe@perches.com> > > Date: Thu, 10 Sep 2009 20:02:43 -0700 > > > On Thu, 2009-09-10 at 19:07 -0700, Stephen Hemminger wrote: > > >> On Thu, 10 Sep 2009 18:48:27 -0700 > > >> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote: > > >> > From: Gregory Rose <gregory.v.rose@intel.com> > > >> > This patch changes the default VF MAC address generation to use an Intel > > >> > Organizational Unit Identifier (OUI), instead of a fully randomized > > >> > Ethernet address. This is to help prevent accidental MAC address > > >> > collisions. > > > I think this not a very good idea. > > I also completely agree that this patch is not a wise move. > > Perhaps this? > > random_ether_address should not assign an "0x02" leading octet. > > "02" has the local assignment bit set, > but is actually a value assigned via OUI. > > Do not use get_random_bytes to avoid drawing down entropy pool. > Getting 6 bytes once is not going to be enough of a problem to drain the pool. I prefer not to weaken the randomness here.
On Fri, 2009-09-11 at 14:15 -0700, Stephen Hemminger wrote: > On Fri, 2009-09011 at 13:20 -0700 Joe Perches wrote: > > Do not use get_random_bytes to avoid drawing down entropy pool. > Getting 6 bytes once is not going to be enough of a problem > to drain the pool. I prefer not to weaken the randomness here. I see no reason to draw down the entropy pool. I have a hard time imagining that a random mac address needs more than reasonably random values. Why do you think it's reasonable to draw from the entropy pool? cheers, Joe -- 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
On Fri, 11 Sep 2009 17:57:47 -0700 Joe Perches <joe@perches.com> wrote: > On Fri, 2009-09-11 at 14:15 -0700, Stephen Hemminger wrote: > > On Fri, 2009-09011 at 13:20 -0700 Joe Perches wrote: > > > Do not use get_random_bytes to avoid drawing down entropy pool. > > Getting 6 bytes once is not going to be enough of a problem > > to drain the pool. I prefer not to weaken the randomness here. > > I see no reason to draw down the entropy pool. > > I have a hard time imagining that a random mac address > needs more than reasonably random values. > One factor to consider is the amount of effort involved in troubleshooting duplicate mac address problems. They don't happen very often, and most people won't encounter them at all. That means they're very low on the list of things you suspect when troubleshooting, so you spend a lot of time investigating other things first, without that time providing any value once you work out what the actual fault it. Once you work out what the problem is, working out which devices are causing it can also be an effort, as, of course, they now don't have unique identifiers. > Why do you think it's reasonable to draw from the > entropy pool? > > cheers, Joe > > -- > 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 -- 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
On Sun, 13 Sep 2009 09:44:09 +0930 Mark Smith <lk-netdev@lk-netdev.nosense.org> wrote: > On Fri, 11 Sep 2009 17:57:47 -0700 > Joe Perches <joe@perches.com> wrote: > > > On Fri, 2009-09-11 at 14:15 -0700, Stephen Hemminger wrote: > > > On Fri, 2009-09011 at 13:20 -0700 Joe Perches wrote: > > > > Do not use get_random_bytes to avoid drawing down entropy pool. > > > Getting 6 bytes once is not going to be enough of a problem > > > to drain the pool. I prefer not to weaken the randomness here. > > > > I see no reason to draw down the entropy pool. > > > > I have a hard time imagining that a random mac address > > needs more than reasonably random values. > > > > One factor to consider is the amount of effort involved in > troubleshooting duplicate mac address problems. They don't happen > very often, and most people won't encounter them at all. That means > they're very low on the list of things you suspect when > troubleshooting, so you spend a lot of time investigating other things > first, without that time providing any value once you work out what the > actual fault it. Once you work out what the problem is, working out > which devices are causing it can also be an effort, as, of course, they > now don't have unique identifiers. > Hmm, probably didn't make my point all that clear. IOW, anything that can contribute to avoiding duplicate mac addresses is worth it in my opinion, when compared to the time (usually hours) involved in troubleshooting duplicate mac addresses. > > > > Why do you think it's reasonable to draw from the > > entropy pool? > > > > cheers, Joe > > > > -- > > 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 > -- > 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 -- 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
On Sun, 2009-09-13 at 10:03 +0930, Mark Smith wrote: > Hmm, probably didn't make my point all that clear. IOW, anything that > can contribute to avoiding duplicate mac addresses is worth it in my > opinion, when compared to the time (usually hours) involved in > troubleshooting duplicate mac addresses. Avoiding an initial octet of "02", which is partially assigned to 3Com and others, might be useful. Not drawing from entropy I think useful, but it's debatable. -- 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
On Sat, 12 Sep 2009 17:44:46 -0700 Joe Perches <joe@perches.com> wrote: > On Sun, 2009-09-13 at 10:03 +0930, Mark Smith wrote: > > Hmm, probably didn't make my point all that clear. IOW, anything that > > can contribute to avoiding duplicate mac addresses is worth it in my > > opinion, when compared to the time (usually hours) involved in > > troubleshooting duplicate mac addresses. > > Avoiding an initial octet of "02", which is partially > assigned to 3Com and others, might be useful. > I wouldn't necessarily disagree. I would say that if that path was taken, then you'd probably also want to be avoiding all the other well known mac addresses that do or can fall within the locally assigned range e.g. DECnet 0xAA addresses, Microsoft's use of 02:01:00:00:00:00 and similar addresses for their Network Load Balancing software, the unicast version of the CF:00:00:00:00:00 multicast address use for ECTP, the unicast version of the 33:33:xx:xx:xx:xx IPv6 ND multicast ranges etc. Having thought about this issue a bit before, another thought might be to have somebody get the Linux kernel it's own OUI, and then have addresses randomly selected out of that. As my day job is networking, I'd find some value in being able to see a well known OUI for Linux randomly generated addresses, rather than the complete randomness that is the case now. The drawback there is that there are then only 24 bits octets of randomness in the addresses that each host can independently choose to use, which isn't anywhere near the as random as the 2^46 the LA address space provides. For most ethernet segments, 24 bits of randomness might be ok, however some of the very large metro ethernet networks are starting to carry 16000+ MAC addresses, all within the same, very controlled broadcast domain. > Not drawing from entropy I think useful, but it's debatable. > > I'm guessing there are other things in the kernel that would be taking away far more entropy, far more often. IIRC, TCP connection initial sequence number selection would be one example. -- 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
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h index 3d7a668..ae7f261 100644 --- a/include/linux/etherdevice.h +++ b/include/linux/etherdevice.h @@ -121,9 +121,17 @@ static inline int is_valid_ether_addr(const u8 *addr) */ static inline void random_ether_addr(u8 *addr) { - get_random_bytes (addr, ETH_ALEN); - addr [0] &= 0xfe; /* clear multicast bit */ - addr [0] |= 0x02; /* set local assignment bit (IEEE802) */ + int i; + + /* not calling get_random_bytes to avoid using entropy */ + do { + addr[0] = random32(); + } while (addr[0] == 0 || addr[0] == 1); + /* get a non-zero, non-one leading octet */ + addr[0] &= 0xfe; /* clear multicast bit */ + addr[0] |= 0x02; /* set local assignment bit (IEEE802) */ + for (i = 1; i < ETH_ALEN; i++) + addr[i] = random32(); } /**