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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 6 Apr 2019 00:21:09 -0700 From: si-wei liu <si-wei.liu@...cle.com> To: Stephen Hemminger <stephen@...workplumber.org>, "Michael S. Tsirkin" <mst@...hat.com> Cc: sridhar.samudrala@...el.com, davem@...emloft.net, kubakici@...pl, alexander.duyck@...il.com, jiri@...nulli.us, netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org, liran.alon@...cle.com, boris.ostrovsky@...cle.com, vijay.balakrishna@...cle.com Subject: Re: [PATCH net v6] failover: allow name change on IFF_UP slave interfaces On 4/5/2019 2:47 PM, Stephen Hemminger wrote: > On Fri, 5 Apr 2019 17:28:55 -0400 > "Michael S. Tsirkin" <mst@...hat.com> wrote: > >> On Wed, Apr 03, 2019 at 12:52:47AM -0400, Si-Wei Liu wrote: >>> When a netdev appears through hot plug then gets enslaved by a failover >>> master that is already up and running, the slave will be opened >>> right away after getting enslaved. Today there's a race that userspace >>> (udev) may fail to rename the slave if the kernel (net_failover) >>> opens the slave earlier than when the userspace rename happens. >>> Unlike bond or team, the primary slave of failover can't be renamed by >>> userspace ahead of time, since the kernel initiated auto-enslavement is >>> unable to, or rather, is never meant to be synchronized with the rename >>> request from userspace. >>> >>> As the failover slave interfaces are not designed to be operated >>> directly by userspace apps: IP configuration, filter rules with >>> regard to network traffic passing and etc., should all be done on master >>> interface. In general, userspace apps only care about the >>> name of master interface, while slave names are less important as long >>> as admin users can see reliable names that may carry >>> other information describing the netdev. For e.g., they can infer that >>> "ens3nsby" is a standby slave of "ens3", while for a >>> name like "eth0" they can't tell which master it belongs to. >>> >>> Historically the name of IFF_UP interface can't be changed because >>> there might be admin script or management software that is already >>> relying on such behavior and assumes that the slave name can't be >>> changed once UP. But failover is special: with the in-kernel >>> auto-enslavement mechanism, the userspace expectation for device >>> enumeration and bring-up order is already broken. Previously initramfs >>> and various userspace config tools were modified to bypass failover >>> slaves because of auto-enslavement and duplicate MAC address. Similarly, >>> in case that users care about seeing reliable slave name, the new type >>> of failover slaves needs to be taken care of specifically in userspace >>> anyway. >>> >>> It's less risky to lift up the rename restriction on failover slave >>> which is already UP. Although it's possible this change may potentially >>> break userspace component (most likely configuration scripts or >>> management software) that assumes slave name can't be changed while >>> UP, it's relatively a limited and controllable set among all userspace >>> components, which can be fixed specifically to listen for the rename >>> and/or link down/up events on failover slaves. Userspace component >>> interacting with slaves is expected to be changed to operate on failover >>> master interface instead, as the failover slave is dynamic in nature >>> which may come and go at any point. The goal is to make the role of >>> failover slaves less relevant, and userspace components should only >>> deal with failover master in the long run. >>> >>> Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module") >>> Signed-off-by: Si-Wei Liu <si-wei.liu@...cle.com> >>> Reviewed-by: Liran Alon <liran.alon@...cle.com> >> Acked-by: Michael S. Tsirkin <mst@...hat.com> >> >> Stephen are you happy with this approach? > I think it is the best solution for what you want to do. Since you're asking specifically, I tried what you suggested below. > Did you test with some things like Free Range Routing, Although there might be spurious warning (which is a check for sanity more than an error) while slave interface is up, slave rename had been handled quite well there, no matter which state slave is at. https://github.com/FRRouting/frr/blob/master/zebra/if_netlink.c#L97 The FRR users are supposed to operate on failover master interface anyway. No one is expected to configure those passive interfaces for routing. > VPP Nothing particular was seen for this one. The netlink usage there doesn't seem related to my change: https://github.com/FDio/vpp/blob/master/src/vnet/devices/netlink.c > or other userspace > control planes that consume netlink? dhcpcd (https://github.com/kobolabs/dhcpcd/blob/kobo/if-linux.c#L761) was tested OK. In addition, the patch seems to play quite well with systemd-udev and dracut/initramfs-tools. No breakage, no weird error message was seen. What else do you suggest we should try/test with? Thanks, -Siwei
Powered by blists - more mailing lists