netdev - Re: [PATCH v2 net-next 0/2] Allow unknown unicast traffic to CPU for Felix DSA

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, 25 Feb 2020 15:57:24 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "Y.b. Lu" <yangbo.lu@....com>, netdev <netdev@...r.kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH v2 net-next 0/2] Allow unknown unicast traffic to CPU for
 Felix DSA

Hi Andrew,

On Tue, 25 Feb 2020 at 15:37, Andrew Lunn <andrew@...n.ch> wrote:
>
> > Secondly, even traffic that the CPU _intends_ to terminate remains
> > "unknown" from the switch's perspective, due to the
> > no-learning-from-injected-traffic issue. So that traffic is still
> > going to be flooded, potentially to unwanted ports as well.
>
> Hi Vladimir
>
> Can you add an entry to its table to solve this? Make it known
> traffic. Hook into dsa_slave_set_rx_mode() and
> dsa_slave_set_mac_address()?
>
>         Andrew

What about bridging a felix port with a "foreign interface" and
passing traffic to a DMAC that is not even on this board (a host
connected to the foreign interface)?
There are so many cases that the Ocelot approach will not work for,
and even adapting that to DSA is going to be tricky for the
implementation. Consider that even a Linux bridge may have a MAC
address that differs from the addresses of its slave devices. Do we
add code in DSA to learn the bridge's address too? Do we add code to
forget it when the last port leaves the bridge? Is it even sufficient?

Regards,
-Vladimir