netdev - Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges

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]

Date:   Wed, 19 Feb 2020 11:18:17 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Ido Schimmel <idosch@...sch.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Ivan Vecera <ivecera@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges

On 2/19/20 10:52 AM, Vladimir Oltean wrote:
> On Wed, 19 Feb 2020 at 02:02, Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>> Why not just revert 2ea7a679ca2abd251c1ec03f20508619707e1749 ("net: dsa:
>> Don't add vlans when vlan filtering is disabled")? If a driver wants to
>> veto the programming of VLANs while it has ports enslaved to a bridge
>> that does not have VLAN filtering, it should have enough information to
>> not do that operation.
>> --
>> Florian
> 
> It would be worth mentioning that for sja1105 and hypothetical other
> users of DSA_TAG_PROTO_8021Q, DSA doing that automatically was
> helpful. VLAN manipulations are still being done from tag_8021q.c for
> the purpose of DSA tagging, but the fact that the VLAN EtherType is
> not 0x8100 means that from the perspective of real VLAN traffic, the
> switch is VLAN unaware. DSA was the easiest place to disseminate
> between VLAN requests of its own and VLAN requests coming from
> switchdev.
> Without that logic in DSA, a vlan-unaware bridge would be able to
> destroy the configuration done for source port decoding.
> Just saying - with enough logic in .port_vlan_prepare, I should still
> be able to accept only what's whitelisted to work for tagging, and
> then it won't matter who issued that VLAN command.

I suppose I am fine with Russell's approach, but maybe its meaning
should be reversed, that is, you get VLAN objects notifications by
default for a  VLAN unaware bridge and if you do set a specific
dsa_switch flag, then you do not get those.
-- 
Florian