netdev - Re: [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port

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]

Message-ID: <20200423213643.GC1054188@lunn.ch>
Date:   Thu, 23 Apr 2020 23:36:43 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Chuanhong Guo <gch981213@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>, netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        bridge@...ts.linux-foundation.org,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        René van Dorst <opensource@...rst.com>
Subject: Re: [RFC PATCH net-next] net: bridge: fix client roaming from DSA
 user port

On Wed, Apr 22, 2020 at 02:01:28PM +0800, Chuanhong Guo wrote:
> Hi!
> 
> On Tue, Apr 21, 2020 at 12:36 AM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > The MAC address needs to move, no argument there. But what are the
> > mechanisms which cause this. Is learning sufficient, or does DSA need
> > to take an active role?
> 
> cpu port learning will break switch operation if for whatever reason
> we want to disable bridge offloading (e.g. ebtables?). In this case
> a packet received from cpu port need to be sent back through
> cpu port to another switch port, and the switch will learn from this
> packet incorrectly.
> 
> If we want cpu port learning to kick in, we need to make sure that:
> 1. When bridge offload is enabled, the switch takes care of packet
>     flooding on switch ports itself, instead of flooding with software
>     bridge.

Hi Chuanhong

This is what the skb->offload_fwd_mark is all about. If this is set to
1, it means the switch has done all the forwarding needed for ports in
that switch. Most of the tag drivers set this unconditionally true.

> 2. Software bridge shouldn't forward any packet between ports
>     on the same switch.

If skb->offload_fwd_mark is true, it won't.

> 3. cpu port learning should only be enabled when bridge
>     offloading is used.

So it should be safe for most switch drivers. And the ones which don't
set offload_fwd_mark are probably relying of software bridging, or are
broken and replicating frames.

> It doesn't have to be a broadcast packet but it needs a packet to go
> through both bridges.
> 
> Say we have bridge A and bridge B, port A1 and B1 are connected
> together and a device is on port A2 first:
> Bridge A knows that this device is on port A2 and will forward traffic
> through A1 to B1 if needed. Bridge B sees these packets and knows
> device is on port B1.
> When the device move from A2 to B2, B updates its fdb and if a
> packet reaches A, A will update its fdb too.

The issue here is 'if a packet reaches A'. B might have no reason to
send a unicast packet to A, if none of the destinations the device is
talking to is reached via A. Which is why i think a
broadcast/multicast packet is more likely to be involved.

		    Andrew