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

Date:   Sun, 1 Nov 2020 17:39:06 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        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 Sun, Nov 01, 2020 at 05:04:42PM +0200, Vladimir Oltean wrote:
> On Sun, Nov 01, 2020 at 04:42:17PM +0200, Ido Schimmel wrote:
> > If the goal of this thread is to get packet sockets to work with
> > offloaded traffic, then I think you need to teach these sockets to
> > instruct the bound device to trap / mirror incoming traffic to the CPU.
> > Maybe via a new ndo.
> 
> A new ndo that does what? It would be exclusively called by sockets?
> We have packet traps with tc, packet traps with devlink, a mechanism for
> switchdev host MDBs, and from the discussion with you I also gather that
> there should be an equivalent switchdev object for host FDBs, that the
> bridge would use. So we would need yet another mechanism to extract
> packets from the hardware data path? I am simply lacking the clarity
> about what the new ndo you're talking about should do.

You indicated that you want packet sockets to work without any user
space changes:

"I think that user space today is expecting that when it uses the
*_ADD_MEMBERSHIP API, it is sufficient in order to see that traffic over
a socket. Switchdev and DSA are kernel-only concepts, they have no
user-facing API. I am not sure that it is desirable to change that."

So tc is irrelevant. And it should work regardless if the socket is
bound to an interface that is bridged:

"For PACKET_ADD_MEMBERSHIP, this should work as-is on swpN even if it's
bridged."

So anything related to the bridge is irrelevant as well.

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.