netdev - Re: [RFC] longer netdev names proposal

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, 27 Jun 2019 10:56:09 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, sthemmin@...rosoft.com, dsahern@...il.com,
        mlxsw@...lanox.com
Subject: Re: [RFC] longer netdev names proposal

On Thu, 27 Jun 2019 10:48:08 -0700
Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> > Hi all.
> > 
> > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> > netdevice name length. Now when we have PF and VF representors
> > with port names like "pfXvfY", it became quite common to hit this limit:
> > 0123456789012345
> > enp131s0f1npf0vf6
> > enp131s0f1npf0vf22
> > 
> > Since IFLA_NAME is just a string, I though it might be possible to use
> > it to carry longer names as it is. However, the userspace tools, like
> > iproute2, are doing checks before print out. So for example in output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > completely avoided.
> > 
> > So here is a proposal that might work:
> > 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> >    IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> >    user should be prepared for any string size.
> > 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> >    the kernel.
> > 3) Udev is going to look for the sysfs indication file. In case when
> >    kernel supports long names, it will do rename to longer name, setting
> >    IFLA_NAME_EXT. If not, it does what it does now - fail.
> > 4) There are two cases that can happen during rename:
> >    A) The name is shorter than IFNAMSIZ  
> >       -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:    
> >          original IFLA_NAME     = eth0
> >          original IFLA_NAME_EXT = eth0
> >          renamed  IFLA_NAME     = enp5s0f1npf0vf1
> >          renamed  IFLA_NAME_EXT = enp5s0f1npf0vf1
> >    B) The name is longer tha IFNAMSIZ  
> >       -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would     
> >          contain the new one:
> >          original IFLA_NAME     = eth0
> >          original IFLA_NAME_EXT = eth0
> >          renamed  IFLA_NAME     = eth0
> >          renamed  IFLA_NAME_EXT = enp131s0f1npf0vf22  
> 
> I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
> right?  And maybe there is some crazy application out there which 
> mixes netlink and ioctl.
> 
> I guess it's not worse than status quo, given that today renames 
> will fail and we will either get truncated names or eth0s..
> 
> > This would allow the old tools to work with "eth0" and the new
> > tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> > be symlink from one name to another.
> >       
> > Also, there might be a warning added to kernel if someone works
> > with IFLA_NAME that the userspace tool should be upgraded.
> > 
> > Eventually, only IFLA_NAME_EXT is going to be used by everyone.
> > 
> > I'm aware there are other places where similar new attribute
> > would have to be introduced too (ip rule for example).
> > I'm not saying this is a simple work.
> > 
> > Question is what to do with the ioctl api (get ifindex etc). I would
> > probably leave it as is and push tools to use rtnetlink instead.
> > 
> > Any ideas why this would not work? Any ideas how to solve this
> > differently?  
> 
> Since we'd have to update all user space to make use of the new names
> I'd be tempted to move to a more structured device identification.
> 
> 5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
> 
> vs:
> 
> 5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
> 
> * ;)
> 
> And allow filtering/selection of device based on more attributes than
> just name and ifindex.  In practice in container workloads, for example,
> the names are already very much insufficient to identify the device.
> Refocusing on attributes is probably a big effort and not that practical
> for traditional CLI users?  IDK
> 
> Anyway, IMHO your scheme is strictly better than status quo.

Or Cisco style naming ;-) Ethernet0/0 

There is a better solution for human use already.
the field ifalias allows arbitrary values and hooked into SNMP.

Why not have userspace fill in this field with something by default?