netdev - Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves

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]

Date:	Thu, 05 Nov 2009 22:08:58 -0800
From:	Roland Dreier <rdreier@...co.com>
To:	Simon Horman <horms@...ge.net.au>
Cc:	Liran Liss <liranl@...lanox.co.il>,
	Or Gerlitz <or.gerlitz@...il.com>,
	Yevgeny Petrilin <yevgenyp@...lanox.co.il>,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
	Tziporet Koren <tziporet@...lanox.co.il>
Subject: Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves

 > > igb uses the full output of random_ether_addr().  I'd be fine with
 > > that.  However setting the OUI means you only get 24 bits of randomness
 > > which makes a collision a lot more likely.
 > 
 > IIRC that was precisely why the OUI isn't used for the igb driver.
 > 
 > Perhaps some infrastructure (by which I mean a random_mac() function)
 > is warranted so at least this discussion can be concentrated around that
 > rather than repeating it for each driver that needs random mac addresses.

What would be the difference between random_mac() and the existing
random_ether_addr() function?

If one chooses a random address with a given OUI, then with only 24 bits
of randomness, the birthday paradox says it takes only a few thousand
addresses to get a collision (easy to hit given even a modest-sized
virtualization setup).  With the 46 bits that random_ether_addr() gives
it takes millions of addresses to be likely to get a collision, which is
probably comfortable for most ethernets.

So it seems that random_ether_addr() is exactly what we should be using
for VFs -- the only alternative I see is for the manufacturer to
allocate N extra ethernet addresses for a NIC that supports N virtual
functions, and use those assigned addresses.  But if the kernel is
making up ethernet addresses then we better use all the bits we can.

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