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]

Message-ID: <20201101120644.c23mfjty562t5xue@skbuf>
Date:   Sun, 1 Nov 2020 14:06:44 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
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 01:27:31PM +0200, Ido Schimmel wrote:
> IIRC, getting PTP to work on bridged interfaces is tricky and this is
> something that is not currently supported by mlxsw or Cumulus:
> https://github.com/Mellanox/mlxsw/wiki/Precision-Time-Protocol#configuring-ptp
> https://docs.cumulusnetworks.com/cumulus-linux-42/System-Configuration/Setting-Date-and-Time/#configure-the-ptp-boundary-clock
> 
> If the purpose of this discussion is to get PTP working in this
> scenario, then lets have a separate discussion about that. This is
> something we looked at in the past, but didn't make any progress (mainly
> because we only got requirements for PTP over routed ports).
> 
> Anyway, opening packet sockets on interfaces (bridged or not) that pass
> offloaded traffic will not get you this traffic to the packet sockets.

I don't think it's a different discussion, I think my issues with what
you're proposing are coming exactly from there. 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. I hope you aren't telling me that
we should add a --please argument to the PACKET_ADD_MEMBERSHIP /
IP_ADD_MEMBERSHIP UAPI just in case the network interface is a switchdev
port...

> There was already a discussion about this last year (I think Microchip
> guys started it) in the context of tcpdump.

The discussion with Microchip people was slightly different, as it was
tackling the notion of promiscuity on switchdev interfaces.