netdev - Re: [PATCH net 0/3] Fixes for sja1105 best-effort VLAN filtering

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: <20210407204641.ly6hnjgi4kjbn4co@skbuf>
Date:   Wed, 7 Apr 2021 23:46:41 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net 0/3] Fixes for sja1105 best-effort VLAN filtering

On Wed, Apr 07, 2021 at 11:14:49PM +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
> 
> This series addresses some user complaints regarding best-effort VLAN
> filtering support on sja1105:
> - switch not pushing VLAN tag on egress when it should
> - switch not dropping traffic with unknown VLAN when it should
> - switch not overwriting VLAN flags when it should
> 
> Those bugs are not the reason why it's called best-effort, so we should
> fix them :)
> 
> Vladimir Oltean (3):
>   net: dsa: sja1105: use the bridge pvid in best_effort_vlan_filtering
>     mode
>   net: dsa: sja1105: use 4095 as the private VLAN for untagged traffic
>   net: dsa: sja1105: update existing VLANs from the bridge VLAN list
> 
>  drivers/net/dsa/sja1105/sja1105.h      |  1 +
>  drivers/net/dsa/sja1105/sja1105_main.c | 61 ++++++++++++++++++--------
>  2 files changed, 43 insertions(+), 19 deletions(-)
> 
> -- 
> 2.25.1
> 

Please don't apply these patches yet. I finished regression testing and
it looks like patch 1 breaks PTP for some reason I'm afraid to even think
of now - the RX timestamps are still collected but synchronization looks
flat by around 1 ms.

If my suspicion is right and the VLAN retagging affects PTP traffic too
(which should hit a trap-to-host rule before that even takes place),
then the MAC timestamp might be replaced with a timestamp taken on the
internal loopback port, which would be pretty nasty. Or the strict
delivery order guarantees towards the DSA master (first comes the PTP
frame, then the meta frame holding the RX timestamp) might no longer be
true if the original PTP frame is dropped in hardware because its
VLAN-retagged replacement is sent to the CPU instead? I don't know. I'll
do some more debugging tomorrow.