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: <aca3151b-e550-4e3b-b677-504151f5fff7@gmail.com>
Date: Wed, 7 May 2025 09:30:27 +0200
From: Florian Fainelli <f.fainelli@...il.com>
To: Jonas Gorski <jonas.gorski@...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 5/6/2025 9:48 PM, Jonas Gorski wrote:
> 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.

If EAP works, sure that seems like the way to go then.
-- 
Florian