linux-kernel - Re: [PATCH net] net: dsa: Treat VLAN ID 0 as PVID untagged

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, 12 Feb 2020 13:28:19 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev <netdev@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>, michal.vokac@...ft.com,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: dsa: Treat VLAN ID 0 as PVID untagged

On 2/12/20 12:47 PM, Vladimir Oltean wrote:
> Hi Florian,
> 
> On Wed, 12 Feb 2020 at 22:06, Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>> VLAN ID 0 is special by all kinds and is really meant to be the default
>> ingress and egress untagged VLAN. We were not configuring it that way
>> and so we would be ingress untagged but egress tagged.
>>
>> When our devices are interfaced with other link partners such as switch
>> devices, the results would be entirely equipment dependent. Some
>> switches are completely fine with accepting an egress tagged frame with
>> VLAN ID 0 and would send their responses untagged, so everything works,
>> but other devices are not so tolerant and would typically reject a VLAN
>> ID 0 tagged frame.
> 
> Are you sure that it's not in fact those devices that are not doing
> what they're supposed to? VID 0 should be sent as tagged and no port
> membership checks should be enforced on it.

Where everything works what I see is the following:

- Linux on egress sends an untagged frame (as captured by tcpdump) but
the VLAN entry for VID 0 makes it egress tagged and the machine on the
other sees it as such as well
- the response from that machine is also ingress tagged as captured from
the DSA master network device

what I do not have visibility into are systems where this does not work
but will try to request that. Breaking users is obviously bad which
prompted me for doing this specification violating frame. I am not sure
whether DSA standalone ports qualify as managed ports or not, sounds
like no given we have not added support for doing much UC/MC filtering
unlike what NICs do.

> 
>>
>> Fixes: 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation")
>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>> ---
>> Hi all,
>>
>> After looking at all DSA drivers and how they implement port_vlan_add()
>> I think this is the right change to do, but would appreciate if you
>> could test this on your respective platforms to ensure this is not
>> problematic.
> 
> I'm pretty sure this is problematic, for the simple reason that with
> this change, DSA is insisting that the default PVID is 0, contrary to
> the bridge core which insists it is 1. And some switches, like the
> Microchip Ocelot/Felix, don't support more than 1 egress-untagged
> VLAN, so adding one of the VIDs 0 or 1 will fail (I don't know the
> exact order off-hand). See 1c44ce560b4d ("net: mscc: ocelot: fix
> vlan_filtering when enslaving to bridge before link is up") for more
> details of how that is going to work.

OK, I do wonder if we would be better off just skipping the VLAN
programming for VID = 0 and/or just defining a different
reserved/default VLAN ID for switches that have global VLAN filtering.

> 
>>
>> Thank you
>>
>>
>>  net/dsa/slave.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>> index 088c886e609e..d3a2782eb94d 100644
>> --- a/net/dsa/slave.c
>> +++ b/net/dsa/slave.c
>> @@ -1100,6 +1100,7 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>>  {
>>         struct dsa_port *dp = dsa_slave_to_port(dev);
>>         struct bridge_vlan_info info;
>> +       u16 flags = 0;
>>         int ret;
>>
>>         /* Check for a possible bridge VLAN entry now since there is no
>> @@ -1118,7 +1119,13 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>>                         return -EBUSY;
>>         }
>>
>> -       ret = dsa_port_vid_add(dp, vid, 0);
>> +       /* VLAN ID 0 is special and should be the default egress and ingress
>> +        * untagged VLAN, make sure it gets programmed as such.
>> +        */
>> +       if (vid == 0)
>> +               flags = BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED;
> 
> IEEE 802.1Q-2018, page 247, Table 9-2—Reserved VID values:
> 
> The null VID. Indicates that the tag header contains only priority
> information; no VID is
> present in the frame. This VID value shall not be configured as a PVID
> or a member of a VID
> Set, or configured in any FDB entry, or used in any Management operation.
> 
>> +
>> +       ret = dsa_port_vid_add(dp, vid, flags);
>>         if (ret)
>>                 return ret;
>>
>> --
>> 2.17.1
>>
> 
> Is this a test?

Of course, I am always testing you, that way you do not know if I am
incredibly smart or stupid.
-- 
Florian