netdev - MT7530 bug, forward broadcast and unknown frames to the correct CPU port

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-next>] [day] [month] [year] [list]

Message-ID: <8a955c34-5724-af9d-d828-a8786bcc08b0@arinc9.com>
Date:   Sun, 23 Apr 2023 18:22:41 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     Vladimir Oltean <olteanv@...il.com>,
        DENG Qingfang <dqfext@...il.com>,
        Greg Ungerer <gerg@...nel.org>
Cc:     Daniel Golle <daniel@...rotopia.org>,
        Richard van Schagen <richard@...terhints.com>,
        Richard van Schagen <vschagen@...com>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        erkin.bozoglu@...ont.com, bartel.eerdekens@...stell8.be,
        netdev <netdev@...r.kernel.org>
Subject: MT7530 bug, forward broadcast and unknown frames to the correct CPU
 port

Hey there folks,

On mt753x_cpu_port_enable() there's code [0] that sets which port to 
forward the broadcast, unknown multicast, and unknown unicast frames to. 
Since mt753x_cpu_port_enable() runs twice when both CPU ports are 
enabled, port 6 becomes the port to forward the frames to. But port 5 is 
the active port, so no broadcast frames received from the user ports 
will be forwarded to port 5. This breaks network connectivity when 
multiple ports are being used as CPU ports.

My testing shows that only after receiving a broadcast ARP frame from 
port 5 then forwarding it to the user port, the unicast frames received 
from that user port will be forwarded to port 5. I tested this with ping.

Forwarding broadcast and unknown unicast frames to the CPU port was done 
with commit 5a30833b9a16 ("net: dsa: mt7530: support MDB and bridge flag 
operations"). I suppose forwarding the broadcast frames only to the CPU 
port is what "disable flooding" here means.

It’s a mystery to me how the switch classifies multicast and unicast 
frames as unknown. Bartel's testing showed LLDP frames fall under this 
category.

Until the driver supports changing the DSA conduit, unknown frames 
should be forwarded to the active CPU port, not the numerically greater 
one. Any ideas how to address this and the "disable flooding" case?

There's also this "set the CPU number" code that runs only for MT7621. 
I'm not sure why this is needed or why it's only needed for MT7621. 
Greg, could you shed some light on this since you added this code with 
commit ddda1ac116c8 ("net: dsa: mt7530: support the 7530 switch on the 
Mediatek MT7621 SoC")?

There're more things to discuss after supporting changing the DSA 
conduit, such as which CPU port to forward the unknown frames to, when 
user ports under different conduits receive unknown frames. What makes 
sense to me is, if there are multiple CPU ports being used, forward the 
unknown frames to port 6. This is already the case except the code runs 
twice. If not, set it to whatever 'int port' is, which is the default 
behaviour already.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n1005

Arınç