netdev - Re: [PATCH net-next 0/4] DSA: promisc on master, generic flow dissector code

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: <5d60fb20-f0df-7c02-e8d4-1963ffaf79d5@gmail.com>
Date:   Mon, 11 May 2020 17:03:42 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/4] DSA: promisc on master, generic flow
 dissector code



On 5/11/2020 4:52 PM, Vladimir Oltean wrote:
> On Tue, 12 May 2020 at 02:28, Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>>
>>
>> On 5/11/2020 1:20 PM, Vladimir Oltean wrote:
>>> From: Vladimir Oltean <vladimir.oltean@....com>
>>>
>>> The initial purpose of this series was to implement the .flow_dissect
>>> method for sja1105 and for ocelot/felix. But on Felix this posed a
>>> problem, as the DSA headers were of different lengths on RX and on TX.
>>> A better solution than to just increase the smaller one was to also try
>>> to shrink the larger one, but in turn that required the DSA master to be
>>> put in promiscuous mode (which sja1105 also needed, for other reasons).
>>>
>>> Finally, we can add the missing .flow_dissect methods to ocelot and
>>> sja1105 (as well as generalize the formula to other taggers as well).
>>
>> On a separate note, do you have any systems for which it would be
>> desirable that the DSA standalone port implemented receive filtering? On
>> BCM7278 devices, the Ethernet MAC connected to the switch is always in
>> promiscuous mode, and so we rely on the switch not to flood the CPU port
>> unnecessarily with MC traffic (if nothing else), this is currently
>> implemented in our downstream kernel, but has not made it upstream yet,
>> previous attempt was here:
>>
>> https://www.spinics.net/lists/netdev/msg544361.html
>>
>> I would like to revisit that at some point.
>> --
>> Florian
> 
> Yes, CPU filtering of traffic (not just multicast) is one of the
> problems we're facing. I'll take a look at your patches and maybe I'll
> pick them up.

The part that modifies DSA to program the known MC addresses should
still be largely applicable, there were essentially two problems that I
was facing, which could be tackled separately.

1) flooding of unknown MC traffic on DSA standalone ports is not very
intuitive if you come from NICs that did filtering before. We should
leverage a DSA switch driver's ability to support port_egress_floods and
support port_mdb_add and combine them to avoid flooding the CPU port.

2) Programming of known multicast addresses for VLAN devices on top of
DSA standalone ports while the switch implements global VLAN filtering.
In that case when we get to the DSA slave device's ndo_set_rx_mode() we
have lost all information about which VID the MAC address is coming from
so we cannot insert the MAC address with the correct VID to support
proper filtering. TI's cpsw driver implements a super complicated scheme
to solve that problem and this was worked on by Ivan in a more generic
and usable form: https://lwn.net/Articles/780783/
-- 
Florian