netdev - Re: [RFC] ethernet: avoid pre-assigned OUI values in 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] [day] [month] [year] [list]

Message-ID: <20110520120102.465d6a25@nehalam>
Date:	Fri, 20 May 2011 12:01:02 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Joe Perches <joe@...ches.com>, netdev@...r.kernel.org
Subject: Re: [RFC] ethernet: avoid pre-assigned OUI values in
 random_ether_addr

On Mon, 16 May 2011 08:46:44 -0700
Stephen Hemminger <shemminger@...tta.com> wrote:

> On Sun, 15 May 2011 23:10:26 +0200
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> > Le dimanche 15 mai 2011 à 13:20 -0700, Joe Perches a écrit :
> > > On Sun, 2011-05-15 at 21:46 +0200, Eric Dumazet wrote:
> > > > Le vendredi 13 mai 2011 à 17:17 -0700, Stephen Hemminger a écrit :
> > > > > There are some addresses in the assigned vendor block that don't obey
> > > > > the locally assigned convention. These should be avoided by random_ether_addr
> > > > > assignment.
> > > > We call random_ether_addr() for some virtual devices, maybe we can add a
> > > > __random_ether_addr() helper for them and not avoid these OUI ?
> > > 
> > > Unless it's speed critical, it's probably not worthwhile.
> > > 
> > 
> > Speed was not my concern, but getting idea of why avoiding pre-assigned
> > OUI was a concern for them, if they dont hit a real Ethernet domain.
> 
> My concern was that after some discussion with IEEE committee that many
> virtual environments are using locally assigned addresses that get bridged
> onto real networks.
> 
> That started me thinking that the current code should be more careful
> to avoid potential conflicts. My opinion is that this not worth worrying
> about because the likelihood of conflict with any one of these old
> addresses is as about as the unlikely as two hosts choosing the same
> value. But I wanted to raise the issue for explicit discussion and frame
> it with what would be required to handle it.

I thought of one problem that the current code has related to udev.
If a virtual device chooses one of the pre-assigned OUI values then
udev will put in the persistent network device file.
This will cause the device to change name.

If you look at /lib/udev/rules.d/75-persistent-net-generator-rules
it has special case code for this.


# ignore KVM virtual interfaces
ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"

# These vendors are known to violate the local MAC address assignment scheme
# Interlan, DEC (UNIBUS or QBUS), Apollo, Cisco, Racal-Datacom
ENV{MATCHADDR}=="02:07:01:*", GOTO="globally_administered_whitelist"
# 3Com
ENV{MATCHADDR}=="02:60:60:*", GOTO="globally_administered_whitelist"
# 3Com IBM PC; Imagen; Valid; Cisco; Apple
ENV{MATCHADDR}=="02:60:8c:*", GOTO="globally_administered_whitelist"
# Intel
ENV{MATCHADDR}=="02:a0:c9:*", GOTO="globally_administered_whitelist"
# Olivetti
ENV{MATCHADDR}=="02:aa:3c:*", GOTO="globally_administered_whitelist"
# CMC Masscomp; Silicon Graphics; Prime EXL
ENV{MATCHADDR}=="02:cf:1f:*", GOTO="globally_administered_whitelist"
# Prominet Corporation Gigabit Ethernet Switch
ENV{MATCHADDR}=="02:e0:3b:*", GOTO="globally_administered_whitelist"
# BTI (Bus-Tech, Inc.) IBM Mainframes
ENV{MATCHADDR}=="02:e6:d3:*", GOTO="globally_administered_whitelist"
# Realtek
ENV{MATCHADDR}=="52:54:00:*", GOTO="globally_administered_whitelist"
# Novell 2000
ENV{MATCHADDR}=="52:54:4c:*", GOTO="globally_administered_whitelist"
# Realtec
ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
# Kingston Technologies
ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"

# match interface dev_id
ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"

# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""

LABEL="globally_administered_whitelist"
--
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