netdev - Re: [PATCH net] net: usb: usbnet: fix name regression

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: <Z01xo_7lbjTVkLRt@atmark-techno.com>
Date: Mon, 2 Dec 2024 17:36:51 +0900
From: 'Dominique MARTINET' <dominique.martinet@...ark-techno.com>
To: David Laight <David.Laight@...lab.com>
Cc: Oliver Neukum <oneukum@...e.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Greg Thelen <gthelen@...gle.com>,
	John Sperbeck <jsperbeck@...gle.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH net] net: usb: usbnet: fix name regression


(Sorry for back-to-back replies, hadn't noticed this when I wrote the
previous mail)

David Laight wrote on Mon, Dec 02, 2024 at 08:17:59AM +0000:
> > So we hit the exact inverse problem with this patch: our device ships an
> > LTE modem which exposes a cdc-ethernet interface that had always been
> > named usb0, and with this patch it started being named eth1, breaking
> > too many hardcoded things expecting the name to be usb0 and making our
> > devices unable to connect to the internet after updating the kernel.
> 
> Erm does that mean your modem has a locally administered MAC address?
> It really shouldn't.

Unfortunately, that's what it gives us:
# ip a show dev eth1
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 02:80:72:78:15:10 brd ff:ff:ff:ff:ff:ff

# udevadm info /sys/class/net/eth1
P: /devices/platform/soc/2100000.bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/net/eth1
E: DEVPATH=/devices/platform/soc/2100000.bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/net/eth1
E: ID_BUS=usb
E: ID_MM_CANDIDATE=1
E: ID_MODEL=GTO
E: ID_MODEL_ENC=GTO
E: ID_MODEL_ID=00a0
E: ID_NET_NAME_MAC=enx028072781510
E: ID_REVISION=0307
E: ID_SERIAL=Gemalto_GTO_101578728002
E: ID_SERIAL_SHORT=101578728002
E: ID_TYPE=generic
E: ID_USB_DRIVER=cdc_ether
E: ID_USB_INTERFACES=:020600:0a0000:020201:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Gemalto
E: ID_VENDOR_ENC=Gemalto
E: ID_VENDOR_ID=1e2d
E: IFINDEX=4
E: INTERFACE=eth1
E: NM_UNMANAGED=1
E: SUBSYSTEM=net
E: USEC_INITIALIZED=23339186

(that mac is stable accross reboots)

afaiu, this modem generates a pointtopoint ethernet device and then
routes packets sent there to LTE.

I've just checked what my phone does when I do USB tethering and it's
pretty similar, the mac is also a local 02:xx mac (02:36:05) which is
also not in OUI lookup tables.
(the only difference is, I plugged it on my laptop which runs systemd,
so it got named enx023605xxxxxx and none of this matters..)

> > > +++ b/drivers/net/usb/usbnet.c
> > > @@ -1767,7 +1767,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
> > >  		// can rename the link if it knows better.
> > >  		if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
> > >  		    ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
> > > -		     (net->dev_addr [0] & 0x02) == 0))
> > > +		     /* somebody touched it*/
> > > +		     !is_zero_ether_addr(net->dev_addr)))
> > 
> > ... or actually now I'm looking at it again, perhaps is the check just
> > backwards, or am I getting this wrong?
> > previous check was rename if (mac[0] & 0x2 == 0), which reads to me as
> > "nobody set the 2nd bit"
> > new check now renames if !is_zero, so renames if it was set, which is
> > the opposite?...
> 
> The 2nd bit (aka mac[0] & 2) is the 'locally administered' bit.
> The intention of the standard was that all manufacturers would get
> a valid 14-bit OUI and the EEPROM (or equivalent) would contain an
> addresses with that bit clear, such addresses should be globally unique.
> Alternatively the local network administrator could assign an address
> with that bit set, required by protocols like DECnet.
> 
> This has never actually been strictly true, a few manufacturers used
> 'locally administered addresses' (02:cf:1f:xx:xx:xx comes to mind)
> and systems typically allow any (non-broadcast) be set.
> 
> So basing any decision on whether a MAC address is local or global
> is always going to be confusing.

Thank you for the explanation, I now understand the old check better --
point to point devices that are a local MAC addresses (0x2 set) would
get to keep the usb0 name.

The new check however no longer cares about the address globality, and
just basically always renames the interface if the driver provided a
mac ?

If that is what was intended, I am fine with this, but I think these
local ppp usb interfaces are rather common in the cheap modem world.


> Linux will allocate a random (locally administered) address if none
> is found - usually due to a corrupt eeprom.

Thanks,
-- 
Dominique