netdev - Re: VLAN filtering with DSA

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: <a5e0a066-0193-beca-7773-5933d48696e8@gmail.com>
Date:   Thu, 10 Sep 2020 11:41:04 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: VLAN filtering with DSA

+Ido,

On 9/10/2020 8:07 AM, Vladimir Oltean wrote:
> Florian, can you please reiterate what is the problem with calling
> vlan_vid_add() with a VLAN that is installed by the bridge?
> 
> The effect of vlan_vid_add(), to my knowledge, is that the network
> interface should add this VLAN to its filtering table, and not drop it.
> So why return -EBUSY?

I suppose that if you wanted to have an 802.1Q just for the sake of 
receiving VLAN tagged frames but not have them ingress the to the CPU, 
you could install an 802.1Q upper, but why would you do that unless the 
CPU should also receive that traffic?

The case that I wanted to cover was to avoid the two programming 
interfaces or the same VLAN, and prefer the bridge VLAN management over 
the 802.1Q upper, because once the switch port is in a bridge, that is 
what an user would expect to use.

If you have a bridge that is VLAN aware, it will manage the data and 
control path for us and that is all good since it is capable of dealing 
with VLAN tagged frames.

A non-VLAN aware bridge's data path is only allowed to see untagged 
traffic, so if you wanted somehow to inject untagged traffic into the 
bridge data path, then you would add a 802.1Q upper to that switch port, 
and somehow add that device into the bridge. There is a problem with 
that though, if you have mutliple bridge devices spanning the same 
switch, and you do the same thing on another switch port, with another 
802.1Q upper, I believe you could break isolation between bridges for 
that particular VID.

Most of this was based on discussions we had with Ido and him explaining 
to me how they were doing it in mlxsw.

AFAIR the other case which is that you already have a 802.1Q upper, and 
then you add the switch port to the bridge is permitted and the bridge 
would inherit the VLAN into its local database.

I did not put much thoughts back then into a cascading set-up, so some 
assumptions can certainly be broken, and in fact, are broken today as 
you experimented.
-- 
Florian