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
| ||
|
Message-Id: <20140715.161838.488578760446734001.davem@davemloft.net> Date: Tue, 15 Jul 2014 16:18:38 -0700 (PDT) From: David Miller <davem@...emloft.net> To: teg@...m.no Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v9 1/4] net: add name_assign_type netdev attribute From: Tom Gundersen <teg@...m.no> Date: Mon, 14 Jul 2014 16:37:22 +0200 > Based on a patch by David Herrmann. > > The name_assign_type attribute gives hints where the interface name of a > given net-device comes from. These values are currently defined: ... > The aim of these patches is to improve user-space renaming of interfaces. As > a general rule, userspace must rename interfaces to guarantee that names stay > the same every time a given piece of hardware appears (at boot, or when > attaching it). However, there are several situations where userspace should > not perform the renaming, and that depends on both the policy of the local > admin, but crucially also on the nature of the current interface name. > > If an interface was created in repsonse to a userspace request, and userspace > already provided a name, we most probably want to leave that name alone. The > main instance of this is wifi-P2P devices created over nl80211, which currently > have a long-standing bug where they are getting renamed by udev. We label such > names NET_NAME_USER. > > If an interface, unbeknown to us, has already been renamed from userspace, we > most probably want to leave also that alone. This will typically happen when > third-party plugins (for instance to udev, but the interface is generic so could > be from anywhere) renames the interface without informing udev about it. A > typical situation is when you switch root from an installer or an initrd to the > real system and the new instance of udev does not know what happened before > the switch. These types of problems have caused repeated issues in the past. To > solve this, once an interface has been renamed, its name is labelled > NET_NAME_RENAMED. > > In many cases, the kernel is actually able to name interfaces in such a > way that there is no need for userspace to rename them. This is the case when > the enumeration order of devices, or in fact any other (non-parent) device on > the system, can not influence the name of the interface. Examples include > statically created devices, or any naming schemes based on hardware properties > of the interface. In this case the admin may prefer to use the kernel-provided > names, and to make that possible we label such names NET_NAME_PREDICTABLE. > We want the kernel to have tho possibilty of performing predictable interface > naming itself (and exposing to userspace that it has), as the information > necessary for a proper naming scheme for a certain class of devices may not > be exposed to userspace. > > The case where renaming is almost certainly desired, is when the kernel has > given the interface a name using global device enumeration based on order of > discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM. > > Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has > not yet been ported. This is mostly useful as a transitionary measure, allowing > us to label the various naming schemes bit by bit. > > v8: minor documentation fixes > v9: move comment to the right commit > > Signed-off-by: Tom Gundersen <teg@...m.no> > Reviewed-by: David Herrmann <dh.herrmann@...il.com> > Reviewed-by: Kay Sievers <kay@...y.org> Applied. -- 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/
Powered by blists - more mailing lists