netdev - Re: [Patch RFC net-next 2/4] net: dsa: microchip: lan937x: remove vlan_filtering_is

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: <20220803110723.hym43imgsnnrgdnj@skbuf>
Date:   Wed, 3 Aug 2022 14:07:23 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Arun.Ramadoss@...rochip.com
Cc:     andrew@...n.ch, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, vivien.didelot@...il.com,
        linux@...linux.org.uk, f.fainelli@...il.com, kuba@...nel.org,
        edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org,
        Woojung.Huh@...rochip.com, davem@...emloft.net
Subject: Re: [Patch RFC net-next 2/4] net: dsa: microchip: lan937x: remove
 vlan_filtering_is_global flag

On Tue, Aug 02, 2022 at 04:09:35PM +0000, Arun.Ramadoss@...rochip.com wrote:
> I have done some study on this SW_VLAN_ENABLE bit. By default the pvid
> of the port is 1 and vlan port membership (0xNA04) is 0xff. So if the
> bit is 0, then unknown dest addr packets are broadcasted which is the
> default behaviour of switch.
> Now consider when the bit is 1,
> - If the invalid vlan packet is received, then based on drop invalid
> vid or unknown vid forward bit, packets are discarded or forwarded.
> - If the valid vlan packet is received, then broadcast to ports in vlan
> port membership list.
> The port membership register set using the ksz9477_cfg_port_member
> function.
> In summary, I infer that we can enable this bit in the port_setup and
> based on the port membership packets can be forwarded. Is my
> understanding correct?
> Can I remove this patch from this series and submit as the separate
> one?

I'm not sure that the switch's capabilities are quite in line with the
Linux kernel expectations if you always force the 802.1Q VLAN Enable bit
to true.

I am looking at Table 4-8: VLAN forwarding from the KSZ9563 datasheet,
and it says that when the "Unknown VID forward" bit is set and we are in
VLAN enable mode, packets are forwarded to the Unknown VID packet
forward list regardless of ALU match (which is "don't care" in this table).
In essence this is because the switch failed to resolve the unknown VID
to a FID. Other switches have a default FID for this case, but it
doesn't appear to hold true for KSZ.

The last thing you want is for packets under a VLAN-unaware bridge to be
always flooded to the ports in the Unknown VID packet forward list, and
bypass ALU lookups.