linux-kernel - Re: RFC: Platform data for onboard USB assets

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:	Wed, 23 Mar 2011 09:22:51 -0700
From:	Greg KH <greg@...ah.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	andy.green@...aro.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

On Wed, Mar 23, 2011 at 05:12:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 23 March 2011, Greg KH wrote:
> > On Wed, Mar 23, 2011 at 11:32:02AM +0100, Arnd Bergmann wrote:
> > > On Wednesday 23 March 2011, Andy Green wrote:
> > > > It's the case for even usbnet, which is using a broken heuristic to 
> > > > decide what to call the interface not even based on vid / pid.
> > > 
> > > I agree that the heuristics in usbnet is less than helpful here,
> > > which among other things leads people to mixing up the two problems
> > > of fixing the device naming and fixing the MAC address assignment.
> > > 
> > > Even though I know Greg disagrees, I'd still prefer sanitising the
> > > rules for the default device name that usbnet assigns.
> > 
> > I'm all for that, but recall, we can't because of previous
> > implementations and past history.  I.e. you will break working systems
> > if you do this.  So we are stuck with what we have at the moment, sorry.
> 
> I would still consider it a bug fix and argue that the number of actual
> people impacted by the current behaviour is much larger than the potential
> number people that might suffer from changing the behavior in an incompatible
> way, given that:
> 
> * The common case for this hardware seems to be to ship with an eeprom
>   with a valid mac address, as identified by the fact that f4e8ab7c
>   "smsc95xx: generate random MAC address once, not every ifup" only recently
>   got into the kernel as a bug fix for the random case, though the driver
>   has been around since 2008.
> 
> * A google search on the term "smsc95xx" find almost exclusively discussions
>   about how to get the device to come up with a proper name on the panda
>   board, and various proposed workarounds.
> 
> * The comment in usbnet.c about this suggests that the intent has always
>   been what is proposed now, it just doesn't match the code:
> 
>            // heuristic:  "usb%d" for links we know are two-host,
>            // else "eth%d" when there's reasonable doubt.  userspace
>            // can rename the link if it knows better.
>                 if ((dev->driver_info->flags & FLAG_ETHER) != 0 &&
>                     (net->dev_addr [0] & 0x02) == 0)
>                         strcpy (net->name, "eth%d");
> 
>   In case of smsc95xx, we *know* that it's ethernet and not two-host,
>   there is no reasonable doubt about this. The code almost makes sense
>   on generic cdc devices, but not for anything else.

Ok, let's fix it up and see who complains :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/