linux-kernel - Re: [PATCH v3 net-next 06/17] net: dsa: sja1105: Limit use of incl

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: <069734c5-9f0f-12d7-b514-1e5ba495fc5c@gmail.com>
Date:   Tue, 4 Jun 2019 13:35:01 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, vivien.didelot@...il.com,
        andrew@...n.ch, davem@...emloft.net, richardcochran@...il.com,
        john.stultz@...aro.org, tglx@...utronix.de, sboyd@...nel.org
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 06/17] net: dsa: sja1105: Limit use of
 incl_srcpt to bridge+vlan mode



On 6/4/2019 10:07 AM, Vladimir Oltean wrote:
> The incl_srcpt setting makes the switch mangle the destination MACs of
> multicast frames trapped to the CPU - a primitive tagging mechanism that
> works even when we cannot use the 802.1Q software features.
> 
> The downside is that the two multicast MAC addresses that the switch
> traps for L2 PTP (01-80-C2-00-00-0E and 01-1B-19-00-00-00) quickly turn
> into a lot more, as the switch encodes the source port and switch id
> into bytes 3 and 4 of the MAC. The resulting range of MAC addresses
> would need to be installed manually into the DSA master port's multicast
> MAC filter, and even then, most devices might not have a large enough
> MAC filtering table.
> 
> As a result, only limit use of incl_srcpt to when it's strictly
> necessary: when under a VLAN filtering bridge.  This fixes PTP in
> non-bridged mode (standalone ports). Otherwise, PTP frames, as well as
> metadata follow-up frames holding RX timestamps won't be received
> because they will be blocked by the master port's MAC filter.
> Linuxptp doesn't help, because it only requests the addition of the
> unmodified PTP MACs to the multicast filter.
> This issue is not seen in bridged mode because the master port is put in
> promiscuous mode when the slave ports are enslaved to a bridge.
> Therefore, there is no downside to having the incl_srcpt mechanism
> active there.
> 
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian