[net-next PATCH] igb: Use Intel OUI for VF MAC addresses

[net-next PATCH] igb: Use Intel OUI for VF MAC addresses

[Jeff Kirsher]

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.

Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
---

 drivers/net/igb/igb.h      |    1 +
 drivers/net/igb/igb_main.c |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/net/igb/igb.h b/drivers/net/igb/igb.h
index 7126fea..463d178 100644
--- a/drivers/net/igb/igb.h
+++ b/drivers/net/igb/igb.h
@@ -65,6 +65,7 @@ struct igb_adapter;
 #define IGB_MAX_VF_MC_ENTRIES              30
 #define IGB_MAX_VF_FUNCTIONS               8
 #define IGB_MAX_VFTA_ENTRIES               128
+#define OUI_LEN                            3
 
 struct vf_data_storage {
 	unsigned char vf_mac_addresses[ETH_ALEN];
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 943186b..290555c 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1315,6 +1315,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
 		unsigned int num_vfs = (max_vfs > 7) ? 7 : max_vfs;
 		int i;
 		unsigned char mac_addr[ETH_ALEN];
+		unsigned char oui[OUI_LEN] = {0x02, 0xAA, 0x00};
 
 		if (num_vfs) {
 			adapter->vf_data = kcalloc(num_vfs,
@@ -1335,6 +1336,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
 					     i < adapter->vfs_allocated_count;
 					     i++) {
 						random_ether_addr(mac_addr);
+						memcpy(mac_addr, oui, OUI_LEN);
 						igb_set_vf_mac(adapter, i,
 						               mac_addr);
 					}

Re: [net-next PATCH] igb: Use Intel OUI for VF MAC addresses

[Stephen Hemminger]

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.

How can probability of collision be lower when the address space
is smaller? If you are going to use Intel OUI, then you should constrain
the selection to a portion of that space that is not being used
by other hardware. I.e if you know Intel assigns addresses to their
devices in ranges, choose a range that is not in use.

Re: [net-next PATCH] igb: Use Intel OUI for VF MAC addresses

[Joe Perches]

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.

> How can probability of collision be lower when the address space
> is smaller? If you are going to use Intel OUI, then you should constrain
> the selection to a portion of that space that is not being used
> by other hardware. I.e if you know Intel assigns addresses to their
> devices in ranges, choose a range that is not in use.

Some other possibilities might be:

o Apply for a Linux specific OUI, maybe via the Linux Foundation,
  and assign MAC random addresses using only that OUI.
o Avoid assigning random MAC addresses that use the initial values
  of already assigned OUIs.

  http://standards.ieee.org/regauth/oui/oui.txt

  Unfortunately, this is not a complete list because several
  vendors have just picked a number at random.

  Nominally assigned leading bytes are:

  00 02 04 08 0C
  10 11 14 18 1C
  20 24 28
  30 34 3C
  40 44 48
  58
  60 64 68 6C
  70 74 78 7C
  80 88
  90 94 98 9C
  A0 A4 A8 AA AC
  B0 B4 B8 BC
  C0 C4 C8 CC
  D4 D8 DC
  E0 E4 E8 EC
  F0 F4

  Maybe just pick an unused specific leading byte.

Re: [net-next PATCH] igb: Use Intel OUI for VF MAC addresses

[David Miller]

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.
> 
>> How can probability of collision be lower when the address space
>> is smaller? If you are going to use Intel OUI, then you should constrain
>> the selection to a portion of that space that is not being used
>> by other hardware. I.e if you know Intel assigns addresses to their
>> devices in ranges, choose a range that is not in use.
> 
> Some other possibilities might be:

I also completely agree that this patch is not a wise move.

[net-next PATCH] etherdevice.h: random_ether_addr update

[Joe Perches]

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.

Signed-off-by: Joe Perches <joe@perches.com>

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();
 }
 
 /**

Re: [net-next PATCH V2] etherdevice.h: random_ether_addr update

[Joe Perches]

Perhaps this is slightly better, it doesn't call
random32 for each octet and makes sure the leading
octet is >= 0x04.

random_ether_address should assign a leading octet >= "0x04"

Does not use get_random_bytes to avoid drawing down entropy pool.

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 3d7a668..fddcabf 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -121,9 +121,26 @@ 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) */
+	u32 val;
+
+	/* not calling get_random_bytes to avoid using entropy */
+	do {
+		val = random32();
+		addr[0] = val;
+	} while (addr[0] < 4);
+	addr[0] &= 0xfe;	/* clear multicast bit */
+	addr[0] |= 0x02;	/* set local assignment bit (IEEE802) */
+
+	val >>= 8;
+	addr[1] = val;
+	val >>= 8;
+	addr[2] = val;
+	val >>= 8;
+	addr[3] = val;
+	val = random32();
+	addr[4] = val;
+	val >>= 8;
+	addr[5] = val;
 }
 
 /**

RE: [net-next PATCH V2] etherdevice.h: random_ether_addr update

[Rose, Gregory V]

The addresses generated here will likely never be used in a production environment.  They are place holders so that the device will function before any management console has done what 99.9% of all vendors will do, which is assign their own address.  OK, that 99% is not a real number, but consider it illustrative of the fact that almost all VMM vendors will assign their own MAC addresses.

They're useful for test and development and that's about it.  We're in discussion with partners about how best to approach the management interface for this and each vendor has his own preferred approach (which complicates the solution) but for now the accepted method is for the igbvf driver to set it's own assigned MAC address in the guest.

The discussion is useful but I think we should keep in mind that the addresses in question will be transitory in nature, likely to be never used except for test and development.

One thing, the original patch described it as ncessary to help prevent collisions among MAC address and this is incorrect.  It was intended to help reduce collisions with other vendors MAC addresses.  If the list doesn't consider that a worth while goal then we can withdraw the patch or take one of the suggested permutations.

Thanks,

- Greg Rose
LAN Access Division
Intel Corp.

-----Original Message-----
From: Joe Perches [mailto:joe@perches.com] 
Sent: Friday, September 11, 2009 1:44 PM
To: David Miller
Cc: shemminger@vyatta.com; Kirsher, Jeffrey T; netdev@vger.kernel.org; gospo@redhat.com; Rose, Gregory V; Skidmore, Donald C
Subject: Re: [net-next PATCH V2] etherdevice.h: random_ether_addr update

Perhaps this is slightly better, it doesn't call
random32 for each octet and makes sure the leading
octet is >= 0x04.

random_ether_address should assign a leading octet >= "0x04"

Does not use get_random_bytes to avoid drawing down entropy pool.

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 3d7a668..fddcabf 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -121,9 +121,26 @@ 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) */
+	u32 val;
+
+	/* not calling get_random_bytes to avoid using entropy */
+	do {
+		val = random32();
+		addr[0] = val;
+	} while (addr[0] < 4);
+	addr[0] &= 0xfe;	/* clear multicast bit */
+	addr[0] |= 0x02;	/* set local assignment bit (IEEE802) */
+
+	val >>= 8;
+	addr[1] = val;
+	val >>= 8;
+	addr[2] = val;
+	val >>= 8;
+	addr[3] = val;
+	val = random32();
+	addr[4] = val;
+	val >>= 8;
+	addr[5] = val;
 }
 
 /**

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Stephen Hemminger]

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.


-- 

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Joe Perches]

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

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Mark Smith]

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

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Mark Smith]

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

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Joe Perches]

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.

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Mark Smith]

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.

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Joe Perches]

On Sun, 2009-09-13 at 13:17 +0930, Mark Smith wrote:
> On Sat, 12 Sep 2009 17:44:46 -0700
> Joe Perches <joe@perches.com> wrote:
> > 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.

The existing code already has the first wire bit cleared so it
is not multicast and has the locally assigned bit set so the
first octet is a multiple of 2.

The suggested patch requires an initial octet >= 0x04.

Skipping AA seems a good idea.

> Having thought about this issue a bit before, another thought might be
> to have somebody get the Linux kernel its own OUI,

That's been suggested.

> > 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.

These MAC assignments are generally done at system startup
when entropy often isn't available and possibly should be
conserved.

Maybe this:

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 3d7a668..40233db 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -118,12 +118,30 @@ static inline int is_valid_ether_addr(const u8 *addr)
  *
  * Generate a random Ethernet address (MAC) that is not multicast
  * and has the local assigned bit set.
+ * Does not assign a leading octet of 0x02 or 0xaa.
  */
 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) */
+	u32 val;
+
+	/* not calling get_random_bytes to avoid using entropy */
+	do {
+		val = random32();
+		addr[0] = val;
+		addr[0] &= 0xfe;	/* clear multicast bit */
+		addr[0] |= 0x02;	/* set local assignment bit (IEEE802) */
+	} while (addr[0] == 0x02 || addr[0] == 0xaa);
+
+	val >>= 8;
+	addr[1] = val;
+	val >>= 8;
+	addr[2] = val;
+	val >>= 8;
+	addr[3] = val;
+	val = random32();
+	addr[4] = val;
+	val >>= 8;
+	addr[5] = val;
 }
 
 /**

Re: [net-next PATCH] etherdevice.h: random_ether_addr update

[Mark Smith]

On Sat, 12 Sep 2009 23:09:12 -0700
Joe Perches <joe@perches.com> wrote:

> On Sun, 2009-09-13 at 13:17 +0930, Mark Smith wrote:
> > On Sat, 12 Sep 2009 17:44:46 -0700
> > Joe Perches <joe@perches.com> wrote:
> > > 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.
> 
> The existing code already has the first wire bit cleared so it
> is not multicast

Agreed. However I think that if there is a well-known multicast address
that has 0x02 set, there is a future, slight possibility that unicast
addresses might be assigned out of that same LA space, and so they're
worth avoiding. It probably seems a bit paranoid, but LAs are supposed
to be private use only in the first place, and not supposed to be seen
outside of the organisation or entity assigning them (e.g. Microsoft
should have got an OUI to use with their NLB product). If people are
crossing those privacy boundaries with LA multicast addresses, I'd
suggest they might be willing to do it with LA unicast addresses in the
future too - and hopefully they'd restrict themselves to the OUI bytes
they've used for their multicast addresses.

> and has the locally assigned bit set so the
> first octet is a multiple of 2.
> 
> The suggested patch requires an initial octet >= 0x04.
> 
> Skipping AA seems a good idea.
> 
> > Having thought about this issue a bit before, another thought might be
> > to have somebody get the Linux kernel its own OUI,
> 
> That's been suggested.
> 
> > > 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.
> 
> These MAC assignments are generally done at system startup
> when entropy often isn't available and possibly should be
> conserved.
> 
> Maybe this:
> 

I'd suggest documenting in the comment why 0x02 or 0xaa are special
values that have been avoided.

> Signed-off-by: Joe Perches <joe@perches.com>
> 
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 3d7a668..40233db 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -118,12 +118,30 @@ static inline int is_valid_ether_addr(const u8 *addr)
>   *
>   * Generate a random Ethernet address (MAC) that is not multicast
>   * and has the local assigned bit set.
> + * Does not assign a leading octet of 0x02 or 0xaa.
>   */
>  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) */
> +	u32 val;
> +
> +	/* not calling get_random_bytes to avoid using entropy */
> +	do {
> +		val = random32();
> +		addr[0] = val;
> +		addr[0] &= 0xfe;	/* clear multicast bit */
> +		addr[0] |= 0x02;	/* set local assignment bit (IEEE802) */
> +	} while (addr[0] == 0x02 || addr[0] == 0xaa);
> +
> +	val >>= 8;
> +	addr[1] = val;
> +	val >>= 8;
> +	addr[2] = val;
> +	val >>= 8;
> +	addr[3] = val;
> +	val = random32();
> +	addr[4] = val;
> +	val >>= 8;
> +	addr[5] = val;
>  }
>  
>  /**
> 
> 
> --
> 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