netdev - Re: [PATCH v3 net-next 13/24] net: dsa: Allow drivers to filter packets they can decode source port from

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: <20190413153959.GE17901@lunn.ch>
Date:   Sat, 13 Apr 2019 17:39:59 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     f.fainelli@...il.com, vivien.didelot@...il.com,
        davem@...emloft.net, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, georg.waibel@...sor-technik.de
Subject: Re: [PATCH v3 net-next 13/24] net: dsa: Allow drivers to filter
 packets they can decode source port from

On Sat, Apr 13, 2019 at 04:28:11AM +0300, Vladimir Oltean wrote:
> Frames get processed by DSA and redirected to switch port net devices
> based on the ETH_P_XDSA multiplexed packet_type handler found by the
> network stack when calling eth_type_trans().
> 
> The running assumption is that once the DSA .rcv function is called, DSA
> is always able to decode the switch tag in order to change the skb->dev
> from its master.
> 
> However there are tagging protocols (such as the new DSA_TAG_PROTO_SJA1105,
> user of DSA_TAG_PROTO_8021Q) where this assumption is not completely
> true, since switch tagging piggybacks on the absence of a vlan_filtering
> bridge. Moreover, management traffic (BPDU, PTP) for this switch doesn't
> rely on switch tagging, but on a different mechanism. So it would make
> sense to at least be able to terminate that.

Hi Vladimir

Let me see if i get this correct.

If the filter fails to match, the frame is received on the master
interface? So BPDUs and PTT packets are going to go to the master
interface?

How does the bridge get these BPDUs, and associated to the correct
slave port?

How does the PTP core code get these frames, and associated to the
correct slave port?

You say there is a different mechanism to do this. Maybe a later patch
i've not yet looked at. But cannot this mechanism be built into the
tagger? That is what the tagger is there for, to demultiplex a frame
to the correct slave. The current code assume the needed information
is in the header, but there is nothing to stop it looking deeper into
the packet if needed. So far, we have been reluctant for a tagger to
call into the DSA driver, but if need be, it could happen.

     Andrew