netdev - Re: [PATCH net-next 03/14] net: dsa: b53: Properly account for VLAN filtering

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: <4d2fbe46-0675-a0b3-0cdb-c34e8bc9147a@gmail.com>
Date:   Thu, 17 Jan 2019 11:06:54 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vivien Didelot <vivien.didelot@...il.com>
Cc:     netdev@...r.kernel.org, andrew@...n.ch, davem@...emloft.net,
        idosch@...lanox.com, jiri@...lanox.com,
        ilias.apalodimas@...aro.org, ivan.khoronzhuk@...aro.org,
        roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com
Subject: Re: [PATCH net-next 03/14] net: dsa: b53: Properly account for VLAN
 filtering

On 1/17/19 10:47 AM, Vivien Didelot wrote:
> On Thu, 17 Jan 2019 09:48:53 -0800, Florian Fainelli <f.fainelli@...il.com> wrote:
>> On 1/17/19 8:36 AM, Vivien Didelot wrote:
>>> Hi Florian,
>>>
>>> On Wed, 16 Jan 2019 12:00:51 -0800, Florian Fainelli <f.fainelli@...il.com> wrote:
>>>
>>>> +	/* Handle the case were multiple bridges span the same switch device
>>>> +	 * and one of them has a different setting than what is being requested
>>>> +	 * which would be breaking filtering semantics for any of the other
>>>> +	 * bridge devices.
>>>> +	 */
>>>> +	b53_for_each_port(dev, i) {
>>>> +		bridge_dev = dsa_to_port(ds, i)->bridge_dev;
>>>> +		if (bridge_dev &&
>>>> +		    bridge_dev != dsa_to_port(ds, port)->bridge_dev &&
>>>> +		    br_vlan_enabled(bridge_dev) != vlan_filtering) {
>>>> +			netdev_err(bridge_dev,
>>>> +				   "VLAN filtering is global to the switch!\n");
>>>> +			return -EINVAL;
>>>> +		}
>>>> +	}
>>>  
>>> Unbridged ports must act as standard NICs and thus forward taggued frames.
>>> What happens to them if there's a bridge with VLAN filtering enabled spawned
>>> on other ports of your switch? Will the unbridged ports filter VLAN?
>> Because VLAN filtering a global setting to the switch, unbridged network
>> ports will effectively have VLAN filtering enabled, which is why the
>> ndo_vlan_rx_{add,kill}_vid functions to permit that use case.
> 
> But then vlan_filtering must simply not be allowed on your switch if you
> have unbridged ports, no?

VLAN filtering is an attribute that applies to the bridge, not the
non-bridged network ports.

> 
> I might be mixing things up here but I don't understand yet how you can
> have bridged and unbridged ports working correctly on your switch when it
> has global VLAN filtering turned on. I understand that the switch will drop
> the tagged frames on ingress.

With ndo_vlan_rx_{add,kill}_vid(), you get proper VLAN entries
programmed into the switch for non-bridged ports, therefore your switch
can allow VLAN tagged traffic (which these interfaces only support) just
fine, even when a bridge has VLAN filtering turned on on a bridge device
that has other switch ports enslaved.
-- 
Florian