netdev - Re: [PATCH net] net: dsa: qca8k: forbid management frames access to internal PHYs if another device is on the MDIO bus

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: <116381bd-9a71-4924-83e5-7839bdb7147c@lunn.ch>
Date: Fri, 25 Apr 2025 21:11:01 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marek Behún <kabel@...nel.org>
Cc: netdev@...r.kernel.org, Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	"Rob Herring (Arm)" <robh@...nel.org>,
	Javier Carrasco <javier.carrasco.cruz@...il.com>,
	Wojciech Drewek <wojciech.drewek@...el.com>,
	Matthias Schiffer <mschiffer@...verse-factory.net>,
	Christian Marangi <ansuelsmth@...il.com>,
	Marek Mojík <marek.mojik@....cz>
Subject: Re: [PATCH net] net: dsa: qca8k: forbid management frames access to
 internal PHYs if another device is on the MDIO bus

On Fri, Apr 25, 2025 at 07:25:04PM +0200, Marek Behún wrote:
> On Fri, Apr 25, 2025 at 06:53:21PM +0200, Andrew Lunn wrote:
> > > >From the ASCII art in commit 526c8ee04bdbd4d8 you can clearly see that
> > > I just assumed there is just one MDIO bus, because I saw activity on
> > > an oscilloscope. I didn't test it the way you now suggested. I also
> > > didn't think of the consequences for the driver design and
> > > device-trees. If we prove that there is just one MDIO bus with two
> > > masters instead of two separate buses that leak some noise in some
> > > situations, the situation will become more complicated...
> > 
> > It is not really that more complex. Some of the mv88e6xxx devices have
> > a similar architecture.
> > 
> > You need to throw away MDIO over Ethernet and stop using the switches
> > master. Because it is async, it cannot be used. The switch MDIO bus
> > driver then just issues bus transactions on the host MDIO bus, using
> > mdiobus_read_nested().
> 
> But this is just in case when there is a separate device on the external
> bus besides the switch, right?
> 
> The access over ethernet frames needs to stay because it speeds up
> DSA operations. The problem is only on Turris 1.x because it breaks
> WAN PHY.

You can keep access to other registers, and statistics etc via
Ethernet frames, but MDIO other Ethernet is going to be an issue.

I suppose you could take the Linux MDIO bus lock, transmit the MDIO
over Ethernet command to the switch, wait for the reply, and then
unlock the MDIO bus. That will prevent Linux accessing the PHY or
switch while there is an outstanding MDIO over Ethernet requests. But
it seems simpler to just do all MDIO over the host MDIO bus. So long
as you are not bit banging, it won't be much slower.

	Andrew