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

Message-ID: <CAJsYDVLZQ=ci1wp1_P0RcwsV8z27zMn4CPHHpueDF7OZ-X9aEg@mail.gmail.com>
Date:   Wed, 22 Apr 2020 14:01:28 +0800
From:   Chuanhong Guo <gch981213@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
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

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.
2. Software bridge shouldn't forward any packet between ports
    on the same switch.
3. cpu port learning should only be enabled when bridge
    offloading is used.

Otherwise we need to manually sync fdb between software bridge
and switch, specifically we need to take over fdb management
on cpu port and tell the switch what devices are on the software
bridge port side.

I haven't read kernel bridge code thoroughly and have no idea
which one is better/easier.

Some switches (e.g. mt753x) have an option to forward packets
with unknown destination port to cpu port only, instead of flooding.
For this type of switch, the solution proposed in this patch is fine,
because removing fdb entries has the same effect as telling switch
that a device is on cpu port. If there's a switch without this feature,
(which I have no idea if it exists) there will be issues on packet
flooding behavior.

>
> Forget about DSA for the moment. How does this work for two normal
> bridges? Is the flow of unicast packets sufficient? Does it requires a
> broadcast packet from the device after it moves?

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 problem addressed in this patch is that switch doesn't update
its fdb when a device moves from switch to software bridge, because
cpu port learning is disabled.

-- 
Regards,
Chuanhong Guo