netdev - Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches

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, 10 Nov 2020 20:12:33 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        Ido Schimmel <idosch@...sch.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>,
        Ivan Vecera <ivecera@...hat.com>, vyasevich@...il.com,
        netdev <netdev@...r.kernel.org>, UNGLinuxDriver@...rochip.com,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches



On 11/1/2020 8:13 AM, Vladimir Oltean wrote:
> On Sun, Nov 01, 2020 at 05:39:06PM +0200, Ido Schimmel wrote:
>> You also wondered which indication you would get down to the driver that
>> eventually needs to program the hardware to get the packets:
>>
>> "Who will notify me of these multicast addresses if I'm bridged and I
>> need to terminate L2 or L4 PTP through the data path of the slave
>> interfaces and not of the bridge."
>>
>> Which kernel entity you want to get the notification from? The packet
>> socket wants the packets, so it should notify you. The kernel is aware
>> that traffic is offloaded and can do whatever it needs (e.g., calling
>> the ndo) in order to extract packets from the hardware data path to the
>> CPU and to the socket.
> 
> Honestly, just as I was saying, I was thinking about using the
> dev_mc_add call that is emitted today, and simply auditing the
> dev_mc_add and dev_uc_add calls which are unnecessary (like in the case
> of non-automatic bridge interfaces), for example like this:
> 
> if (!(dev->features & NETIF_F_PROMISC_BY_DEFAULT))
> 	dev_uc_add(dev, static bridge fdb entry);
> 
> To me this would be the least painful way forward.

Vladimir, what do you think about re-posting this series with the DSA
ports operating in standalone or bridge mode with the bridge being
multicast aware, and tackle the termination of PTP frames on DSA ports
being bridged separately?

>From what I could read there does not appear to be a problem with doing
RX filtering for standalone ports since we all agree that these
net_device should look like a regular NIC port with RX filtering capability.
-- 
Florian