netdev - 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: <12878838.xADNQ6XqJ4@n95hx1g2>
Date:   Thu, 26 Nov 2020 17:53:07 +0100
From:   Christian Eggers <ceggers@...i.de>
To:     <Tristram.Ha@...rochip.com>
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?

regards
Christian

        Look-up Tables
        ALU_STAT_CTL 00000001  TABLE_INDEX       0       START_FINISH   idle             TABLE_SELECT Static Address
                               ACTION     read

        Static Address Table
        ALU_VAL_A    80000000  VALID      valid            SRC_FILTER     disabled       DST_FILTER   disabled
                               PRIORITY             0      MSTP                     0
        ALU_VAL_B    80000000  OVERRIDE   enabled          USE_FID        disabled
                               PRT3_FWD   disabled         PRT2_FWD       disabled       PRT1_FWD     disabled
        ALU_VAL_C    00000100  FID                  0      MAC_0_1              01:00
        ALU_VAL_D    5E000181  MAC_2_5    5E:00:01:81


On Wednesday, 25 November 2020, 22:08:39 CET, Christian Eggers wrote:
> I need some help from Microchip, please read below.
> 
> On Thursday, 19 November 2020, 19:51:15 CET, Tristram.Ha@...rochip.com wrote:
> > There is one more requirement that is a little difficult to do.  The calculated peer delay
> > needs to be programmed in hardware register, but the regular PTP stack has no way to
> > send that command.  I think the driver has to do its own calculation by snooping on the
> > Pdelay_Req/Pdelay_Resp/Pdelay_Resp_Follow_Up messages.
> 
> In an (offline) discussion with Vladimir we discovered, that the KSZ switch
> behaves different as ptp4l expects: 
> 
> The KSZ switch forwards PTP (e.g. SYNC) messages in hardware (with updating
> the correction field). For this, the peer delays need be configured for each
> port.
> 
> ptp4l in turn expects to do the forwarding in software (for the P2P_TC clock
> configuration). For this, no hardware configuration of the peer delay is
> necessary. But due to limitations of currently available hardware, this TC
> forwarding is currently only supported for 2 step clocks, as a one-step clock
> would probably fully replace the originTimestamp field (similar as a BC, but
> not as a TC).
> 
> Vladimir suggested to configure an ACL in the KSZ switch to block forwarding
> of PTP messages between the user ports and to run ptp4l as BC. My idea is to
> simply block forwarding of UDP messages with destination ports 319+320 and
> L2 messages with the PTP Ether-Type.
> 
> I installed the following ACL (for UDP) in the Port ACL Access registers 0-F:
> |_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F
> | 00 39 01 40 01 3F 42 22 00 00 00 60 00 00 00 01
> ACL index: 0
> 
> Match: 
> - MD=11 (L4)
> - ENB=10 (UDP ports)
> - S/D=0 (dst)
> - EQ=1 (equal)
> - MAX_PORT=320
> - MIN_PORT=319
> - PC=01 (min or max)
> - PRO=17 (UDP, don't care?)
> - FME=0 (disabled)
> 
> Action:
> - PM=0 (disabled)
> - P=0 (don't care)
> - RPE=0 (disabled)
> - RP=0 (don't care)
> - MM=11 (replace)
> - PORT_FWD_MAP: all ports to 0
> 
> Processing entry:
> - Ruleset=0x0001
> - FRN=0
> 
> Unfortunately, with this configuration PTP messages are still forwarded from
> port 1 to port 2. Although I was successful in blocking other communication
> (e.g. by MAC address), the matching rules above seem not to work. Is there an
> error in the ACL, or is forwarding of PTP traffic independent of configured
> ACLs?
> 
> regards
> Christian
>