netdev - Re: dsa: mv88e6xxx maps all VLANs to the same FID

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240619093218.155065ef@dellmb>
Date: Wed, 19 Jun 2024 09:32:18 +0200
From: Marek Behún <kabel@...nel.org>
To: Peter Rashleigh <prashleigh@...stertangent.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: dsa: mv88e6xxx maps all VLANs to the same FID

On Tue, 18 Jun 2024 15:24:08 -0700
Peter Rashleigh <prashleigh@...stertangent.com> wrote:

> Hello all,
> 
> I've discovered what suspect to be a bug in the mv88e6xxx driver. I'm curious if anyone else has run into this behavior and might be able to suggest a way forward (or can tell me what I'm doing wrong).
> 
> I'm developing a custom networking product that has three Marvell 88E6361 switches connected via DSA to a Marvell CPU running on a custom buildroot Linux (version 6.1.53) like this:
> [CPU]---[Switch 0]---[Switch 1]---[Switch 2]
> 
> The product uses a mix of bridged and standalone ports, spread across the three switches.
> 
> The problem I'm having is that all VLANs (both for bridged and standalone ports) are using the same FID. I've found that mv88e6xxx_atu_new() always sets FID=0 even if there are already standalone ports or other VLANs using that FID. The problem seems to be with the getNext operation called from mv88e6xxx_vtu_walk().
> 
> The VTU Walk function sets VID=0xfff and then runs mv88e6xxx_g1_vtu_getnext(), but the switch does not respond as expected. Instead of returning the lowest valid VID, the register value (Global 1 reg 0x06) is 0x2fff, suggesting that the switch has reached the end of the second VTU page rather than starting from zero. This seems to conflict with what the Marvell datasheet describes, but I haven't come up with a better explanation so far.
> 
> Any suggestions are greatly appreciated.

This is known limitation of the current version of the driver.

I started working on this FID separation in order to support
multi-CPU DSA on mv88e6xxx.

Marek