netdev - Re: [net-next PATCH] etherdevice.h: random_ether

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1252822152.4400.108.camel@Joe-Laptop.home>
Date:	Sat, 12 Sep 2009 23:09:12 -0700
From:	Joe Perches <joe@...ches.com>
To:	Mark Smith <lk-netdev@...netdev.nosense.org>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>,
	jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org,
	gospo@...hat.com, gregory.v.rose@...el.com,
	donald.c.skidmore@...el.com
Subject: Re: [net-next PATCH] etherdevice.h: random_ether_addr update

On Sun, 2009-09-13 at 13:17 +0930, Mark Smith wrote:
> On Sat, 12 Sep 2009 17:44:46 -0700
> Joe Perches <joe@...ches.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@...ches.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html