netdev - RE: [PATCH] Use firmware provided index to register a network interface

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: <EDA0A4495861324DA2618B4C45DCB3EE6A0AFD@blrx3m08.blr.amer.dell.com>
Date:	Thu, 23 Sep 2010 21:20:57 +0530
From:	<Narendra_K@...l.com>
To:	<greg@...ah.com>
Cc:	<netdev@...r.kernel.org>, <linux-hotplug@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <Matt_Domsch@...l.com>,
	<Charles_Rose@...l.com>, <Jordan_Hargrave@...l.com>,
	<Vijay_Nijhawan@...l.com>
Subject: RE: [PATCH] Use firmware provided index to register a network interface

> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Thursday, September 23, 2010 8:58 PM
> To: K, Narendra
> Cc: netdev@...r.kernel.org; linux-hotplug@...r.kernel.org; linux-
> pci@...r.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> Nijhawan, Vijay
> Subject: Re: [PATCH] Use firmware provided index to register a network
> interface
> 
> > >
> > > Ick, again, what's wrong with using udev for this as it is
designed
> > to?
> > > That way no kernel changes are needed, and no one has to rely on
> the
> > > BIOS getting the firmware number right (meaning it will work on
all
> > > types of systems.)
> > >
> >
> > 1. We tried addressing this issue using udev only and without any
> kernel
> > changes, during Nov-Dec 2008 timeframe using Biosdevname udev helper
> > utility. Biosdevname utility has the ability to suggest BIOS
intended
> > name of an interface given its OS name.
> >
> > /sbin/biosdevname -I eth2 - (OS name)
> > eth0 - (Name according to the BIOS)
> >
> > KERNEL!="eth*", GOTO="biosdevname_end"
> > ACTION!="add",  GOTO="biosdevname_end"
> > NAME=="?*",     GOTO="biosdevname_end"
> >
> > PROGRAM="/sbin/biosdevname --policy=all_ethN -i %k",
> > ENV{INTERFACE_NAME}="%c"
> >
> > LABEL="biosdevname_end"
> >
> > We observed that renames in the same namespace, which is ethN
> namespace,
> > resulted in interface names like eth_rename_ren. The solution was
> > susceptible to driver load order. Please refer to this bug report-
> > https://bugzilla.novell.com/show_bug.cgi?id=441079.
> >
> > This solution was not favored.
> 
> That's because for some reason you don't want to accept the fact that
> if
> you want to rename things in a persistant manner, you have to do so in
> a
> namespace that is outside of the kernel's normal one.
> 
> Now trying to change the kernel namespace itself seems like a bad hack
> around this fact.
> 

The patch does not change the existing kernel name space. It adheres to
the existing ethN name space with IFNAMSIZ length requirements. The
patch only makes sure that eth0 always corresponds to what is labeled as
'Gb1' on server chassis, on systems where SMBIOS type 41 record is
available. And removes the need for any renames for the interfaces which
have a firmware index assigned by system firmware, as the very first
name assigned by the kernel will be as expected and deterministic.

With regards,
Narendra K






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