linux-kernel - Re: [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into a bridge

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]

Date:   Fri, 26 Oct 2018 16:16:06 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Ido Schimmel <idosch@...lanox.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Petr Machata <petrm@...lanox.com>,
        "privat@...l-hjelmeland.no" <privat@...l-hjelmeland.no>,
        "Woojung.Huh@...rochip.com" <Woojung.Huh@...rochip.com>,
        "tristram.ha@...rochip.com" <tristram.ha@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into
 a bridge

On 10/26/18 8:10 AM, Ido Schimmel wrote:
> On Wed, Oct 24, 2018 at 12:36:57PM -0700, Florian Fainelli wrote:
>> Commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
>> disabled") changed the behavior of DSA switches when the switch ports
>> are enslaved into the bridge and only pushed the VLAN configuration down
>> to the switch if the bridge is configured with VLAN filtering enabled.
> 
> This is what mlxsw is doing.
> 
>> This is unfortunately wrong, because what vlan_filtering configures is a
>> policy on the acceptance of VLAN tagged frames with an unknown VID.
>>
>> vlan_filtering=0 means a frame with a VLAN tag that is not part of the
>> VLAN table should be allowed to ingress the switch, and vlan_fltering=1
>> would reject that frame.
> 
> While you correctly describe the logic, this is not how VLAN-unaware
> bridges are actually used. The expectation is that packets will be
> untagged when entering the bridge. Either because they are truly
> untagged or because they were untagged by a VLAN netdev.
> 
> For a long time we rejected the enslavement of physical ports to
> VLAN-unaware bridges and only allowed VLAN netdevs to be enslaved. In
> order to support the logic you described, we would need to map all 4K
> VLANs on each port to 4K different FIDs. In addition, each FDB entry
> would need to be programmed 4K times, each time with a different FID.
> This is because FDB lookup is performed using {MAC, FID} and not only
> MAC. I can go into more details about why we cannot map different VLANs
> on a port to the same FID, but I do not think it is pertinent to our
> discussion.
> 
> Eventually, users started complaining about this constraint and we
> relaxed it in commit 65b53bfd497b ("mlxsw: spectrum_switchdev: Allow
> port enslavement to a VLAN-unaware bridge").

Thanks for providing more context, I suppose we will keep the current
logic then, if nothing else it aligns us with mlxsw.
-- 
Florian