netdev - Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic

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]

Message-ID: <20211213185835.ltvv5qz7pincloyj@skbuf>
Date:   Mon, 13 Dec 2021 20:58:35 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Kurt Kanzenbach <kurt@...-computers.de>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic

On Mon, Dec 13, 2021 at 09:11:40AM -0800, Richard Cochran wrote:
> On Mon, Dec 13, 2021 at 02:31:47PM +0200, Vladimir Oltean wrote:
> 
> > With other drivers, all packets injected from the CPU port act as if in
> > "god mode", bypassing any STP state. It then becomes the responsibility
> > of the software to not send packets on a port that is blocking,
> > except for packets for control protocols. Would you agree that ptp4l
> > should consider monitoring whether its ports are under a bridge, and
> > what STP state that bridge port is in?
> 
> Perhaps.  linuxptp TC mode will forward frames out all configured
> interfaces.  If the bridge can't drop the PTP frames automatically,
> then this could cause loops.

Considering that in this configuration:

ip link add br0 type bridge
ip link set swp0 master br0
ip link set swp1 master br0
ip link set swp2 master br0
ip link set swp3 master br0
ptp4l -i swp0 -i swp1 -i swp2 -i swp3 -f configs/P2P-TC.cfg -m

the kernel code path for PTP packets has nothing to do with the bridge
driver (unless maybe an explicit netfilter rule to tell the bridge RX
handler to not steal those packets from the physical port), I think it's
safe to say that yes, the bridge can't drop the PTP frames automatically.

> So if switch HW in general won't drop them, then, yes, the TC user
> space stack will need to follow the STP state.

The hardware offloads tend to follow the software model as closely as
possible, and as mentioned, I think this has to do with the software
model in this case, rather than a hardware quirk. I would consider the
hardware to be quirky quite in the opposite case: you send a packet
through a physical port rather than the bridge, and that one is affected
by the STP state. We have switch drivers like that too, but let's not go
there, they're rather the exception.

> > I think this isn't even specific
> > to DSA, the same thing would happen with software bridging:
> 
> (Linux doesn't support even SW time stamping on SW bridges, so you
> can't have a TC running in this case.)

As also rephrased in the replies above, the point was that STP state has
nothing to do, in general, with whether this is a DSA switch or not.
It is a bridging service concept, and applies to data plane packets,
which ptp4l isn't sending/receiving, since as you very well point out,
your socket is opened on the physical port and not on the bridge device.
So don't expect the STP state of the port to do something here. If you
send a packet on a socket opened on an interface that is backed by a
physical port, expect that packet to be sent - is the main point.
The fact that I used the "software bridging" term was just to clarify
that it hasn't got anything to do with whether the bridging is offloaded
or not.