netdev - Re: dsa/mv88e6xxx: leaking packets on MV88E6341 switch

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, 01 Dec 2020 13:29:54 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Peter Vollmer <peter.vollmer@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: dsa/mv88e6xxx: leaking packets on MV88E6341 switch

On Tue, Dec 01, 2020 at 09:49, Peter Vollmer <peter.vollmer@...il.com> wrote:
> On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
>> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer <peter.vollmer@...il.com> wrote:
>> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
>> > requests (only the requests) are also seen on client1 connected to
>> > lan1
>> 
>> This is the expected behavior of the current implementation I am
>> afraid. It stems from the fact that the CPU responds to the echo request
>> (or to any other request for that matter) with a FROM_CPU. This means
>> that no learning takes place, and the SA of br0 will thus never reach
>> the switch's FDB. So while client0 knows the MAC of br0, the switch
>> (very counter-intuitively) does not.
>> 
>> The result is that the unicast echo request sent by client0 is flooded
>> as unknown unicast by the switch. This way it reaches the CPU but also,
>> as you have discovered, all other ports that allow unknown unicast to
>> egress.
>> 
>
> Thanks for this explanation. Would there be a way to inject the br0 MAC
> into the switch FDB using 'bridge fdb' or some other tool as a
> workaround ?

Unfortunately not. DSA will only attempt to offload FDB entries on user
ports to the ATU at the moment. Vladimir has started work on a series
that would also offload addresses from "foreign" ports:

https://lore.kernel.org/netdev/20201108131953.2462644-1-olteanv@gmail.com/

His work could possibly be extended to include addresses added to the
bridge itself.

> And is this behaviour the same with all other DSA capable
> switches (or at least the mv88e6xxx ones)?  Will this change eventually 

For mv88e6xxx, yes. These devices will never perform learning on
FROM_CPU frames.

> after the implementation is complete ?

I sure hope so. There are multiple ways forward here. Vladimirs approach
with adding dynamically learned addresses as static entries is one way.

I would like to do some work to optimize multicast forwarding
performance that would also, as a side-effect, solve this
problem. Because it would mean that we would start sending FORWARD
frames from the CPU for bridged traffic, and thus the switch would be
able to learn the location of the source address.