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: <531074c1-f818-4c0a-b8d1-be63ace38d5f@gmail.com>
Date: Tue, 6 May 2025 21:03:13 +0200
From: Florian Fainelli <f.fainelli@...il.com>
To: Jonas Gorski <jonas.gorski@...il.com>, Vladimir Oltean <olteanv@...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>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes



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?
-- 
Florian