netdev - Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

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: <20220706111239.n6sjggkebyrsu6x3@skbuf>
Date:   Wed, 6 Jul 2022 11:12:40 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     "Arun.Ramadoss@...rochip.com" <Arun.Ramadoss@...rochip.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "petrm@...dia.com" <petrm@...dia.com>,
        "idosch@...dia.com" <idosch@...dia.com>,
        "linux@...pel-privat.de" <linux@...pel-privat.de>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hauke@...ke-m.de" <hauke@...ke-m.de>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "martin.blumenstingl@...glemail.com" 
        <martin.blumenstingl@...glemail.com>,
        "Woojung.Huh@...rochip.com" <Woojung.Huh@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: never skip VLAN configuration

Hi Arun,

On Wed, Jul 06, 2022 at 10:51:34AM +0000, Arun.Ramadoss@...rochip.com wrote:
> Hi Vladimir,
> 
> On Tue, 2022-07-05 at 20:31 +0300, Vladimir Oltean wrote:
> > - For ksz9477, REG_PORT_DEFAULT_VID seems to be only modified by the
> >   bridge VLAN add/del handlers, so there is no logic to update it on
> >   VLAN awareness change. I don't know exactly how the switch behaves
> >   after ksz9477_port_vlan_filtering() is called with "false".
> >   If packets are classified to the REG_PORT_DEFAULT_VID, then it is
> >   broken. Similar thing can be said for KSZ8.
> 
> When ksz9477_port_vlan_filtering is set to false, then it clears the
> 802.1Q vlan enable bit in the switch. So the packets are not classified
> based on vlan tag. Only if the vlan bit is set, packets are classified
> based on pvid.

So bit 7 of the global Switch Lookup Engine Control 0 Register says:

802.1Q VLAN Enable
This is the master enable for VLAN forwarding and filtering. Note that the
VLAN Table must be set up before VLAN mode is enabled.
1 = VLAN mode enabled
0 = VLAN mode disabled

I'm not completely clear, personally, from the chosen wording.

More interesting is the definition for the Port Control 1 Register,
where it says

Port VLAN Membership
Each bit corresponds to a device port. This feature does not utilize VLAN
tags or the VLAN Table, and is unrelated to tag-based VLAN functions. Also
refer to bit 1 in the Queue Management Control 0 Register.
Bit 0 is for port 1
Bit 1 is for port 2, etc.
1 = Frames may be forwarded to the corresponding port
0 = Frames are blocked from being forwarded to corresponding port

So you may be right, if the VLAN mode is disabled, the packet is
forwarded within the "port VLAN". It would be good to check,
nonetheless.

> > In any case, see commit 8b6836d82470 ("net: dsa: mv88e6xxx: keep the
> > pvid at 0 when VLAN-unaware") for an example of how to deal with the
> > problem, and test pvid_change() in
> > tools/testing/selftests/drivers/net/dsa/bridge_vlan_unaware.sh for
> > how
> > to check whether the driver behaves correctly. I don't have the
> > hardware
> > to test any changes.
> 
> I can test it and report the observation. But I haven't run the
> selftests before. I looked in the scripts today, but couldn't find out
> how to compile it as part of kernel and program it to the target &
> test. I infer that, this scripts should be run on target (I have
> SAMA5D3 + KSZ9477) with 4 switch ports. Can you guide me on testing
> this.

To be honest I've no idea how to run the kselftests "correctly" either,
I just rsync -avr tools/testing/selftests/ root@<board-ip>:selftests/,
then install the packages I need (running the selftest usually shows
what those are), then run the test itself:

$ cd selftests/drivers/net/dsa/ocelot
$ ./bridge_vlan_unaware.sh lan1 lan2 lan3 lan4

The topology for most of these selftests is pretty standard. There are 2
host interfaces $h1 and $h2 (the first and the last one), and 2 switch
interfaces $swp1 and $swp2 (the middle 2). There is supposed to be a
loopback cable between $h1 and $swp1, and a cable between $swp2 and $h2.
The $h1 and $h2 can be any physical Ethernet interfaces, $swp1 and $swp2
need to be switchdev.