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:   Thu, 20 Feb 2020 10:56:17 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Vladimir Oltean <olteanv@...il.com>, 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 3:15 PM, Russell King - ARM Linux admin wrote:
> On Wed, Feb 19, 2020 at 11:18:17AM -0800, Florian Fainelli wrote:
>> 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.
> 
> If we reverse it, I'll need someone to tell me which DSA switches
> should not get the vlan object notifications.  Maybe also in that
> case, we should deny the ability to toggle the state of
> vlan_filtering as well?
> 

Let's get your patch series merged. If you re-spin while addressing
Vivien's comment not to use the term "vtu", I think I would be fine with
the current approach of having to go after each driver and enabling them
where necessary.

Thanks
-- 
Florian