netdev - Re: [PATCH net-next 0/4] vxlan: Join / leave MC group when reconfigured

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] [day] [month] [year] [list]

Message-ID: <dd666dd8-f0a5-42dc-aad6-855b69ccef3c@blackwall.org>
Date: Mon, 10 Feb 2025 13:24:31 +0200
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Petr Machata <petrm@...dia.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc: Ido Schimmel <idosch@...dia.com>, mlxsw@...dia.com,
 Andrew Lunn <andrew+netdev@...n.ch>, Roopa Prabhu <roopa@...dia.com>,
 Menglong Dong <menglong8.dong@...il.com>, Guillaume Nault <gnault@...hat.com>
Subject: Re: [PATCH net-next 0/4] vxlan: Join / leave MC group when
 reconfigured

On 2/7/25 19:34, Petr Machata wrote:
> When a vxlan netdevice is brought up, if its default remote is a multicast
> address, the device joins the indicated group.
> 
> Therefore when the multicast remote address changes, the device should
> leave the current group and subscribe to the new one. Similarly when the
> interface used for endpoint communication is changed in a situation when
> multicast remote is configured. This is currently not done.
> 
> Both vxlan_igmp_join() and vxlan_igmp_leave() can however fail. So it is
> possible that with such fix, the netdevice will end up in an inconsistent
> situation where the old group is not joined anymore, but joining the
> new group fails. Should we join the new group first, and leave the old one
> second, we might end up in the opposite situation, where both groups are
> joined. Undoing any of this during rollback is going to be similarly
> problematic.
> 
> One solution would be to just forbid the change when the netdevice is up.
> However in vnifilter mode, changing the group address is allowed, and these
> problems are simply ignored (see vxlan_vni_update_group()):
> 
>  # ip link add name br up type bridge vlan_filtering 1
>  # ip link add vx1 up master br type vxlan external vnifilter local 192.0.2.1 dev lo dstport 4789
>  # bridge vni add dev vx1 vni 200 group 224.0.0.1
>  # tcpdump -i lo &
>  # bridge vni add dev vx1 vni 200 group 224.0.0.2
>  18:55:46.523438 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s)
>  18:55:46.943447 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s)
>  # bridge vni
>  dev               vni                group/remote
>  vx1               200                224.0.0.2
> 
> Having two different modes of operation for conceptually the same interface
> is silly, so in this patchset, just do what the vnifilter code does and
> deal with the errors by crossing fingers real hard.
> 
> Petr Machata (4):
>   vxlan: Join / leave MC group after remote changes
>   selftests: forwarding: lib: Move require_command to net, generalize
>   selftests: test_vxlan_fdb_changelink: Convert to lib.sh
>   selftests: test_vxlan_fdb_changelink: Add a test for MC remote change
> 
>  drivers/net/vxlan/vxlan_core.c                |  15 +++
>  tools/testing/selftests/net/forwarding/lib.sh |  10 --
>  tools/testing/selftests/net/lib.sh            |  19 +++
>  .../net/test_vxlan_fdb_changelink.sh          | 111 ++++++++++++++++--
>  4 files changed, 132 insertions(+), 23 deletions(-)
> 

For the set,
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>