linux-kernel - RE: [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for KSZ956x

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: <BYAPR11MB355857CFE8E9DA29BDAA900AECF50@BYAPR11MB3558.namprd11.prod.outlook.com>
Date:   Mon, 30 Nov 2020 21:01:25 +0000
From:   <Tristram.Ha@...rochip.com>
To:     <ceggers@...i.de>
CC:     <olteanv@...il.com>, <kuba@...nel.org>, <andrew@...n.ch>,
        <richardcochran@...il.com>, <robh+dt@...nel.org>,
        <vivien.didelot@...il.com>, <davem@...emloft.net>,
        <kurt.kanzenbach@...utronix.de>, <george.mccollister@...il.com>,
        <marex@...x.de>, <helmut.grohne@...enta.de>,
        <pbarker@...sulko.com>, <Codrin.Ciubotariu@...rochip.com>,
        <Woojung.Huh@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for
 KSZ956x

> Hi Microchip,
> 
> as ACL based blocking of PTP traffic seems not to work, I tried to install MAC
> based static lookup rules on the switch I successfully managed to block other
> non-PTP traffic, but for PTP the lookup table entry (see below) seems not to
> work. Incoming SYNC messages on port are still forwarded to port 2.
> 
> The table entry is based on the multicast MAC used for PTP. With PTP
> domains!=0
> there could be 128 possible MAC addresses that needs to blocked (but the
> switch
> has only 16 entries in the static table). Is there any way to block the whole
> PTP multicast address range (01:00:5E:00:01:81-01:00:5E:00:01:ff)? The data
> sheet
> mentions that the static address table can be used for multicast addresses,
> so there should be a way.
> 
> Alternatively, is there a hidden "disable TC" setting which disables the
> transparent clock entirely?

The 1588 PTP engine in the KSZ switches was designed to be controlled closely by
a PTP stack, so it is a little difficult to use when there is a layer of kernel support
between the application and the driver.

The default mode to use should be 1-step E2E where the switch acts as an E2E
Transparent Clock.

The 16-bit register 0x514 specifies the basic operation mode of the switch.

Bit 0 is for 1-step clock mode.
Bit 1 is for master mode, which should be off when the clock is acting as a master.
Bit 2 is for P2P mode.
Bit 7 stops the automatic forwarding and every PTP message goes to the host port.
This is the mode to use when the switch acts as a Boundary Clock or 2-step Clock.

When master mode is on Delay_Resp will not be forwarded to the host port.
When master mode is off Delay_Req will not be forwarded to the host port.

When P2P mode is off Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up will not
be forwarded to the host port.
When P2P mode is on those messages can be sent and received even though the port
Is closed for normal communication.

Bit 5 recognizes L2 PTP messages and the switch acts accordingly.
Bit 4 is for UDPv4 while bit 3 is for UDPv6.

It is rather pointless to actively filter certain PTP messages through other means.
It is better to leave the kernel PTP receive filter as coarse as possible.

When using P2P in 1-step clock mode the port id in the PTP header is automatically
changed by hardware to be the same as the real port, so it is useless to arbitrarily
use a different port id.  The original intent is to send 1 Pdelay_Req and receive
several Pdelay_Resp in each port.

The calculated peer delay from the port needs to be programmed to the port
register so that the Sync message can be compensated correctly while it travels
through the switches.  This poses a problem as the driver normally does not do the
calculation.

The 2-step clock mode avoids some of the mentioned issues.  However there are some
hardware bugs associated with this operation mode and it is not recommended to use.

For some profiles that require 2-step operation like gPTP there are ways to workaround.

For Sync it is quite simple to send Follow_Up after it even though the Sync contains the
transmit timestamp.  The Follow_Up just repeats that information.

For 2-step Pdelay_Resp it is harder as the hardware puts the turnaround time in
the correction field.  The driver workaround is to report the transmit timestamp
differently such that it is the same as Pdelay_Req receive timestamp so that the net
calculation of the peer delay is just the same as receiving 1-step Pdelay_Resp.

I will try my own implementation to see how these steps can be done.