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: <20211213121045.GA14042@hoboy.vegasvil.org>
Date:   Mon, 13 Dec 2021 04:10:45 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     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>,
        Vladimir Oltean <olteanv@...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 Sat, Dec 11, 2021 at 07:39:26AM -0800, Richard Cochran wrote:
> On Fri, Dec 10, 2021 at 09:14:10PM -0800, Jakub Kicinski wrote:
> > On Fri, 10 Dec 2021 01:07:59 +0100 Tobias Waldekranz wrote:
> > > Do we know how PTP is supposed to work in relation to things like STP?
> > > I.e should you be able to run PTP over a link that is currently in
> > > blocking?
> > 
> > Not sure if I'm missing the real question but IIRC the standard
> > calls out that PTP clock distribution tree can be different that
> > the STP tree, ergo PTP ignores STP forwarding state.
> 
> That is correct.  The PTP will form its own spanning tree, and that
> might be different than the STP.  In fact, the Layer2 PTP messages
> have special MAC addresses that are supposed to be sent
> unconditionally, even over blocked ports.

Let me correct that statement.

I looked at 1588 again, and for E2E TC it states, "All PTP version 2
messages shall be forwarded according to the addressing rules of the
network."  I suppose that includes the STP state.

For P2P TC, there is an exception that the peer delay messages are not
forwarded.  These are generated and consumed by the switch.

The PTP spanning tree still is formed by the Boundary Clocks (BC), and
a Transparent Clock (TC) does not participate in forming the PTP
spanning tree.

What does this mean for Linux DSA switch drivers?

1. All incoming PTP frames should be forwarded to the CPU port, so
   that the software stack may perform its BC or TC functions.

2. When used as a BC, the PTP frames sent from the CPU port should not
   be dropped.

3. When used as a TC, PTP frames sent from the CPU port can be dropped
   on blocked external ports, except for the Peer Delay messages.

Now maybe a particular switch implementation makes it hard to form
rules for #3 that still work for UDP over IPv4/6.

Thanks,
Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ