netdev - Re: [PATCH] dsa: vsc73xx: add support for vlan filtering

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] [day] [month] [year] [list]

Date:   Tue, 27 Jul 2021 14:57:31 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Paweł Dembicki <paweldembicki@...il.com>
Cc:     netdev <netdev@...r.kernel.org>,
        Linus Wallej <linus.walleij@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dsa: vsc73xx: add support for vlan filtering

Hi Pawel,

On Thu, Jan 28, 2021 at 02:37:55AM +0200, Vladimir Oltean wrote:
> With even more enhancements to the bridge and DSA data path, the source
> port information might not even matter for the network stack when the
> port is bridged, since the packet will end up in the data path of the
> bridge anyway, regardless of which bridged port the packet came in
> through (a notable exception to this is link-local traffic like bridge
> PDUs - some switches treat link-local packets differently than normal
> data ones). On transmission, the imprecise steering to the correct
> egress port poses further complications, because of the flooding
> implementation in the Linux bridge: a packet that is to be flooded
> towards swp0, swp1 and swp2 will be cloned by the bridge once per egress
> port, and each skb will be individually delivered to each net_device
> driver for xmit. The bridge does not know that the packet transmission
> through a DSA driver with no tagging protocol is imprecise, and instead
> of delivering the packet just towards the requested egress port, that
> the switch will likely flood the packet.  So each packet will end up
> flooded once by the software bridge, and twice by the hardware bridge.
> This can be modeled as a TX-side offload for packet flooding, and could
> be used to prevent the bridge from cloning the packets in the first
> place, and just deliver them once to a randomly chosen port which is
> bridged.

Did you make any progress with getting rid of DSA_TAG_PROTO_NONE for
vsc73xx?

Just FYI, the bridge and DSA enhancement that I was talking about above
got accepted and you should be able to make use of it.
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=356ae88f8322066a2cd1aee831b7fb768ff2905c
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=beeee08ca1d432891f9e1f6188eea85ffac68527

Assuming you haven't solved your issue with link-local packets, you
should at least be able to configure the switch as follows:
- in standalone mode and under a VLAN-unaware bridge: enable Shared VLAN
  Learning, set VLAN_TCI_IGNORE_ENA to always classify packets to the
  port-based VLAN and not look at the VLAN headers, reserve the
  1024-3071 VID range for tag_8021q, and call dsa_tag_8021q_register().
- under a VLAN-aware bridge: same as the above except enable Independent
  VLAN Learning and disable VLAN_TCI_IGNORE_ENA. Packets from ports
  under a VLAN-aware bridge will come tagged with the bridge VLAN, so
  you can draw inspiration from net/dsa/tag_sja1105.c to see how to
  perform reception for those (dsa_find_designated_bridge_port_by_vid).
This should give you the ability to expose the switch as an STP-incapable
bridge accelerator with port isolation and VLAN support, which frankly
seems about all that the hardware can offer.