netdev - Re: [RFC PATCH net-next] net: dsa: tag_8021q: Allow DSA tags and VLAN filtering simultaneously

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: <50186dc9-88e1-12f4-f8c8-894e48a1eae9@gmail.com>
Date:   Thu, 21 Nov 2019 09:37:40 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] net: dsa: tag_8021q: Allow DSA tags and VLAN
 filtering simultaneously

On 11/21/19 2:29 AM, Vladimir Oltean wrote:
> On Mon, 18 Nov 2019 at 06:30, Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>> On 11/17/2019 1:14 PM, Vladimir Oltean wrote:
>> [snip]
>>
>>> +best_effort_vlan_filtering
> 
> [snip]
> 
>>> +                     - Cannot terminate VLAN-tagged traffic on local device.
>>> +                       There is no way to deduce the source port from these.
>>> +                       One could still use the DSA master though.
>>
>> Could we use QinQ to possibly solve these problems and would that work
>> for your switch? I do not really mind being restricted to not being able
>> to change the default_pvid or have a reduced VLAN range, but being able
>> to test VLAN tags terminated on DSA slave network devices is a valuable
>> thing to do.
>> --
>> Florian
> 
> I took another look at the hardware manual and there exists a feature
> called the Retagging Table whose purpose I did not understand
> originally. It can do classification on frames with a given { ingress
> port mask, egress port mask, vlan id }, and clone them towards a given
> list of destination ports with a new VID. The table only has space for
> 32 entries though. I think I can use it to keep the CPU copied to all
> non-pvid VLANs received on the front-panel ports. The CPU will still
> see a pvid-tagged frame for each of those, but with the PCP from the
> original frame. The result is that VLAN filtering is still performed
> correctly (non-member VIDs of the front-panel ports are dropped), but
> the tag is consumed by DSA and sockets still see those frames as
> untagged. To me that's fine except for the fact that the CPU will now
> be spammed by offloaded flows even if the switch learns the
> destination to be a front-panel. Just wanted to hear your opinion
> before attempting to prototype this.

That seems like a good idea to me. Back to your RFC patch here, instead
of introducing a "best effort vlan filtering" configuration knob, how
about just restricting the possible VID range when vlan_filtering=1
through the port_vlan_prepare() callback to exclude the problematic
dsa_tag_8021q VID ranges used for port discrimination?
-- 
Florian