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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAOiHx=kiLgvTBVupJDqZzW1Dfn9RhiWxDfF2ZXiSR8Qk5ea2YQ@mail.gmail.com>
Date: Tue, 6 May 2025 21:48:29 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, 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>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

On Tue, May 6, 2025 at 9:03 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> On 5/6/2025 4:27 PM, Jonas Gorski wrote:
> > On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@...il.com> wrote:
> >>
> >> / 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.
> >
> > The issue isn't the vlan filtering, it's the (missing) FDB isolation
> > on the ASIC.
>
> Could not we just use double tagging to overcome that limitation?

Wouldn't that break VLAN filtering on a vlan aware bridge? AFAICT
double tagging mode is global, the VLAN table is then used for
customer (port) assignment, so you can't filter on the inner/802.1Q
tag anymore. Also learning would then essentially become SVL IIUCT.
Also I think there aren't switches that support double tagging, but
don't support EAP. EAP mode might be the easier way. Assuming there
isn't a gotcha I have overlooked.

Jonas