netdev - Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream port as well

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:   Tue, 20 Aug 2019 12:40:02 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Ido Schimmel <idosch@...sch.org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        nikolay@...ulusnetworks.com,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream
 port as well

On 8/20/19 10:52 AM, Vivien Didelot wrote:
> Hi Vladimir,
> 
> On Tue, 20 Aug 2019 12:54:44 +0300, Vladimir Oltean <olteanv@...il.com> wrote:
>> I can agree that this isn't one of my brightest moments. But at least
>> we get to see Cunningham's law in action :)
>> When dsa_8021q is cleaning up the switch's VLAN table for the bridge
>> to use it, it is good to really clean it up, i.e. not leave any VLAN
>> installed on the upstream ports.
>> But I think this is just an academical concern at this point. In
>> vlan_filtering mode, the CPU port will accept VLAN frames with the
>> dsa_8021q ID's, but they will eventually get dropped due to no
>> destination. The real breaker is the pvid change. If something like
>> patch 4/6 gets accepted I will drop this one.
> 
> I wish Ward had mentioned to submit such academical concern as RFC :)
> 
> Please submit smaller series, targeting a single functional problem each,
> with clear and detailed messages.

Also, I don't think this change set is useful per-se, if we take care of
removing VLANs on user facing ports, and VLAN filtering is turned on,
then a frame ingressing an user port with a VLAN that is not part of the
VLAN table/entries should simply be discarded on ingress, or on egress
to the CPU port (depending on where the switch performs VID checking),
so the CPU port cannot possibly receive such a frame, and so removing it
from the CPU port is correct from a reference counting perspective, but
useless in practice. Thoughts?
-- 
Florian