netdev - Re: Choose a default DSA 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <91c90cc5-7971-8a95-fe64-b6e5f53a8246@arinc9.com>
Date: Tue, 16 May 2023 22:29:27 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Vladimir Oltean <olteanv@...il.com>,
 Frank Wunderlich <frank-w@...lic-files.de>
Cc: Felix Fietkau <nbd@....name>, netdev <netdev@...r.kernel.org>,
 erkin.bozoglu@...ont.com, Andrew Lunn <andrew@...n.ch>,
 Florian Fainelli <f.fainelli@...il.com>, John Crispin <john@...ozen.org>,
 Mark Lee <Mark-MC.Lee@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 Matthias Brugger <matthias.bgg@...il.com>,
 Landen Chao <Landen.Chao@...iatek.com>, Sean Wang <sean.wang@...iatek.com>,
 DENG Qingfang <dqfext@...il.com>
Subject: Re: Choose a default DSA CPU port

On 28.02.2023 14:58, Vladimir Oltean wrote:
> On Sun, Feb 26, 2023 at 01:12:04PM +0100, Frank Wunderlich wrote:
>> but back to topic...we have a patch from vladuimir which allows
>> setting the preferred cpu-port...how do we handle mt7531 here
>> correctly (which still sets port5 if defined and then break)?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n2383
>>
>> 	/* BPDU to CPU port */
>> 	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
>> 		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
>> 			   BIT(cpu_dp->index));
>> 		break; //<<< should we drop this break only to set all "cpu-bits"? what happens then (flooding both ports with packets?)
>> 	}
>>
>> as dsa only handles only 1 cpu-port we want the real cpu-port
>> (preferred | first). is this bit set also if the master is changed
>> with your follow-up patch?
> 
> Could you please make a best-effort attempt at describing what does the
> MT7531_CFC[MT7531_CPU_PMAP_MASK] register affect? From the comment, if
> affects the trapping of control packets. Does the MT7530 not have this
> register? Do they behave differently? Does the register affect anything
> else? If that logic is commented out, does DSA-tagged traffic still work
> on MT7531? How about a bridge created with stp_state 1? I don't
> understand at the moment why the hardware allows specifying a port mask
> rather than a single port. Intuitively I'd say that if this field
> contains more than one bit set, then control packets would be delivered
> to all CPU ports that are up, effectively resulting in double processing
> in Linux. So that doesn't seem to be useful. But I don't have enough data.

I have thoroughly tested BPDU trapping using mausezahn on MT7530, and 
now MT7531.

First of all, the MT7530_MFC register exists on MT7530 and MT7531 but 
they're not the same. CPU_EN and CPU_PORT bits are specific to MT7530. 
The MT7531_CFC register and therefore the CPU_PMAP bits are specific to 
MT7531.

All these bits are used only for trapping frames. They don't affect 
anything else. DSA tagged traffic still works without setting anything 
on CPU_EN and CPU_PORT on MT7530. DSA tagged traffic still works without 
setting anything on CPU_PMAP on MT7531.

For MT7530, the port to trap the frames to is fixed since CPU_PORT is 
only of 3 bits so only one CPU port can be defined. This means that, in 
case of multiple ports used as CPU ports, any frames set for trapping to 
CPU port will be trapped to the numerically greatest CPU port.

For MT7531, after properly setting the CPU port bitmap [0], the switch 
traps the frame to the CPU port the user port is connected to. So 
there's no double processing!

I confirmed this by adding support for changing DSA conduit [1], then 
doing a BPDU test using mausezahn.

Here's the test from my computer. One port is connected to an MT7531 
port connected to eth0, the other is connected to an MT7531 port 
connected to eth1.

BPDUs only appear on eth0:
sudo mausezahn enp9s0 -c 0 -d 1s -t bpdu

BPDUs only appear on eth1:
sudo mausezahn eno1 -c 0 -d 1s -t bpdu

[0] 
https://github.com/arinc9/linux/commit/6dfa74e6383249bd017092eada0c41f178fa3d25
[1] 
https://github.com/arinc9/linux/commit/5ed8f08bd750ab5db521bf97584ddc1d43d23b2c

Arınç