linux-kernel - Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250506134252.y3y2rqjxp44u74m2@skbuf>
Date: Tue, 6 May 2025 16:42:52 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jonas Gorski <jonas.gorski@...il.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
	Andrew Lunn <andrew@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>,
	Kurt Kanzenbach <kurt@...utronix.de>,
	Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

/ unrelated to patches /

On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
> > > I have a fix/workaround for that, but as it is a bit more controversial
> > > and makes use of an unrelated feature, I decided to hold off from that
> > > and post it later.
> >
> > Can you expand on the fix/workaround you have?
> 
> It's setting EAP mode to simplified on standalone ports, where it
> redirects all frames to the CPU port where there is no matching ARL
> entry for that SA and port. That should work on everything semi recent
> (including BCM63XX), and should work regardless of VLAN. It might
> cause more traffic than expected to be sent to the switch, as I'm not
> sure if multicast filtering would still work (not that I'm sure that
> it currently works lol).
> 
> At first I moved standalone ports to VID 4095 for untagged traffic,
> but that only fixed the issue for untagged traffic, and you would have
> had the same issue again when using VLAN uppers. And VLAN uppers have
> the same issue on vlan aware bridges, so the above would be a more
> complete workaround.

I don't understand the logic, can you explain "you would have had the
same issue again when using VLAN uppers"? The original issue, as you
presented it, is with bridges with vlan_filtering=0, and does not exist
with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
not committed to hardware RX filters. And bridges with mixed
vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
So I don't see how making VID 4095 be the PVID of just standalone ports
(leaving VLAN-unaware bridge ports with a different VID) would not be
sufficient for the presented problem.

That being said, trapping to CPU all packets on standalone ports is not
uncontroversial, as long as it works correctly for the hardware
controlled by this driver. You seem concerned about losing RX filtering,
but if you look at dsa_switch_supports_uc_filtering() and
dsa_switch_supports_mc_filtering() you'll see b53 never had it - it
depends, among other things, on ds->fdb_isolation == true and
ds->vlan_filtering_is_global == false. Here you're working on improving
the fdb_isolation requirements, but there is still no support in the
core for devices where VLAN filtering is a global setting.