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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ