netdev - Re: DSA: some questions regarding TX forwarding offload

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, 5 Oct 2021 19:50:40 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <vladimir.oltean@....com>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: DSA: some questions regarding TX forwarding offload

On 10/5/2021 3:12 AM, Vladimir Oltean wrote:
> I don't want to answer any of these questions until I understand how
> does your hardware intend the FID and FID_EN bits from the DSA header to
> be used. The FID only has 2 bits, so it is clear to me that it doesn't
> have the same understanding of the term as mv88e6xxx, if the Realtek
> switch has up to 4 FIDs while Marvell up to 4K.
> 
> You should ask yourself not only how to prevent leakage, but also the
> flip side, how should I pass the packet to the switch in such a way that
> it will learn its MAC SA in the right FID, assuming that you go with FDB
> isolation first and figure that out. Once that question is answered, you
> can in premise specify an allowance port mask which is larger than
> needed (the entire mask of user ports) and the switch should only
> forward it towards the ports belonging to the same FID, which are
> roughly equivalent with the ports under a specific bridge. You can
> create a mapping between a FID and dp->bridge_num. Makes sense or am I
> completely off?
> 

Sorry for sort of hijacking this discussion.

Broadcom switches do not have FIDs however using Alvin's topology, and 
given the existing bridge support in b53, it also does not look like 
there is leaking from one bridge to other because of the port matrix 
configuration which is enforced in addition to the VLAN membership. 
However based on what I see in tag_dsa.c for the transmit case with 
skb->offload_fwd_mark, I would have to dig into the bridge's members in 
order to construct a bitmask of ports to provide to tag_brcm.c, so that 
does not really get me anywhere, does it?

Those switches also always do double VLAN tag (802.1ad) normalization 
within their data path whenever VLAN is globally enabled within the 
switch, so in premise you could achieve the same isolation by reserving 
one of the outer VLAN tags per bridge, enabling IVL and hope that the 
FDB is looked including the outer and inner VLAN tags and not just the 
inner VLAN tag.

If we don't have a FID concept, and not all switches do, how we can 
still support tx forwarding offload here?
-- 
Florian