netdev - Re: [PATCH net-next] net: dsa: mv88e6xxx: do not flood CPU with unknown multicast

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: <20190615182646.GB26321@t480s.localdomain>
Date:   Sat, 15 Jun 2019 18:26:46 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     linux@...linux.org.uk, netdev@...r.kernel.org, andrew@...n.ch,
        f.fainelli@...il.com
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: do not flood CPU with
 unknown multicast

Hi David, Russell,

On Sat, 15 Jun 2019 13:35:13 -0700 (PDT), David Miller <davem@...emloft.net> wrote:
> From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> Date: Sat, 15 Jun 2019 21:28:10 +0100
> 
> > On Sat, Jun 15, 2019 at 01:25:55PM -0700, David Miller wrote:
> >> From: Vivien Didelot <vivien.didelot@...il.com>
> >> Date: Wed, 12 Jun 2019 18:33:44 -0400
> >> 
> >> > The DSA ports must flood unknown unicast and multicast, but the switch
> >> > must not flood the CPU ports with unknown multicast, as this results
> >> > in a lot of undesirable traffic that the network stack needs to filter
> >> > in software.
> >> > 
> >> > Signed-off-by: Vivien Didelot <vivien.didelot@...il.com>
> >> 
> >> Applied.
> > 
> > Hi Dave,
> > 
> > We found this breaks IPv6, so it shouldn't have been applied (which is
> > the point I raised when I replied to Vivien).  Vivien is now able to
> > reproduce that.
> > 
> > I guess you need a revert patch now?
> 
> Yep, I'll revert, thanks for letting me know.

Indeed this patch requires to enable multicast_querier in some scenarios,
while flooding the CPU ports with unknown multicast traffic may still be
necessary in some cases, e.g. when a non-DSA interface is member of the bridge.

To give a bit more details, Russell's shown me that pinging the bridge's
IPv6 address won't work as is with this patch because the bridge won't flood
the IPv6 neighbor solicitation to the CPU. A good reflex here is to enable
multicast_querier on the bridge, to program its address into the switch.

But I will propose another patch making the flooding of unknown multicast
configurable, to work with all scenarios without making the code too complex.

Thanks,
Vivien