| 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
| ||
|
Date: Fri, 19 Jul 2019 13:00:22 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: netdev@...r.kernel.org
Cc: davem@...emloft.net, jakub.kicinski@...ronome.com,
sthemmin@...rosoft.com, dsahern@...il.com, dcbw@...hat.com,
mkubecek@...e.cz, andrew@...n.ch, parav@...lanox.com,
saeedm@...lanox.com, mlxsw@...lanox.com
Subject: [patch net-next rfc 0/7] net: introduce alternative names for network interfaces
From: Jiri Pirko <jiri@...lanox.com>
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
Udev cannot rename these interfaces out-of-the-box and user needs to
create custom rules to handle them.
Also, udev has multiple schemes of netdev names. From udev code:
* Type of names:
* b<number> - BCMA bus core number
* c<bus_id> - bus id of a grouped CCW or CCW device,
* with all leading zeros stripped [s390]
* o<index>[n<phys_port_name>|d<dev_port>]
* - on-board device index number
* s<slot>[f<function>][n<phys_port_name>|d<dev_port>]
* - hotplug slot index number
* x<MAC> - MAC address
* [P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>]
* - PCI geographical location
* [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
* - USB port number chain
* v<slot> - VIO slot number (IBM PowerVM)
* a<vendor><model>i<instance> - Platform bus ACPI instance id
* i<addr>n<phys_port_name> - Netdevsim bus address and port name
One device can be often renamed by multiple patterns at the
same time (e.g. pci address/mac).
This patchset introduces alternative names for network interfaces.
Main goal is to:
1) Overcome the IFNAMSIZ limitation
2) Allow to have multiple names at the same time (multiple udev patterns)
3) Allow to use alternative names as handle for commands
See following examples.
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
-> Add alternative names for dummy0:
$ ip link altname add dummy0 name someothername
$ ip link altname add dummy0 name someotherveryveryveryverylongname
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname someothername
altname someotherveryveryveryverylongname
-> Add bridge brx, add it's alternative name and use alternative names to
do enslavement.
$ ip link add name brx type bridge
$ ip link altname add brx name mypersonalsuperspecialbridge
$ ip link set someotherveryveryveryverylongname master mypersonalsuperspecialbridge
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master brx state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname someothername
altname someotherveryveryveryverylongname
4: brx: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname mypersonalsuperspecialbridge
-> Add ipv4 address to the bridge using alternative name:
$ ip addr add 192.168.0.1/24 dev mypersonalsuperspecialbridge
$ ip addr show mypersonalsuperspecialbridge
4: brx: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname mypersonalsuperspecialbridge
inet 192.168.0.1/24 scope global brx
valid_lft forever preferred_lft forever
-> Delete one of dummy0 alternative names:
$ ip link altname del someotherveryveryveryverylongname
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master brx state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname someothername
4: brx: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7e:a2:d4:b8:91:7a brd ff:ff:ff:ff:ff:ff
altname mypersonalsuperspecialbridge
TODO:
- notifications for alternative names add/removal
- sanitization of add/del cmds (similar to get link)
- test more usecases and write selftests
- extend support for other netlink ifaces (ovs for example)
- add sysfs symlink altname->basename?
Jiri Pirko (7):
net: procfs: use index hashlist instead of name hashlist
net: introduce name_node struct to be used in hashlist
net: rtnetlink: add commands to add and delete alternative ifnames
net: rtnetlink: put alternative names to getlink message
net: rtnetlink: unify the code in __rtnl_newlink get dev with the rest
net: rtnetlink: introduce helper to get net_device instance by ifname
net: rtnetlink: add possibility to use alternative names as message
handle
include/linux/netdevice.h | 14 ++-
include/uapi/linux/if.h | 1 +
include/uapi/linux/if_link.h | 3 +
include/uapi/linux/rtnetlink.h | 7 ++
net/core/dev.c | 152 ++++++++++++++++++++++----
net/core/net-procfs.c | 4 +-
net/core/rtnetlink.c | 192 +++++++++++++++++++++++++++++----
security/selinux/nlmsgtab.c | 4 +-
8 files changed, 334 insertions(+), 43 deletions(-)
--
2.21.0
Powered by blists - more mailing lists