netdev - Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

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: <2013fa64-06a1-4b61-90dc-c5bd68d8efed@lunn.ch>
Date: Tue, 2 Jan 2024 16:50:22 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: ezra@...ergy-village.org, Russell King <linux@...linux.org.uk>,
	Tristram Ha <Tristram.Ha@...rochip.com>,
	Michael Walle <michael@...le.cc>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

> Excluding all PHY's from a vendor for me is a quite big hammer.

Maybe it serves them right for getting this wrong?

Micrel is now part of Microchip, so in effect, this is the same broken
IP just with a different name and OUI. We have not seen any other
vendor get this wrong.

I do however disagree with this statement in the original patch:

> AFAICT all SMSC/Microchip PHYs are Clause 22 devices.

drivers/net/phy/smsc.c has a number of phy_write_mmd()/phy_read_mmd()
in it. But that device has a different OUI.

> I think we should make this more granular.
> And mdio-bus.c including micrel_phy.h also isn't too nice.
> Maybe we should move all OUI definitions in drivers to a
> core header. Because the OUI seems to be all we need from
> these headers.

That does seem a big change to make for 'one' broken PHY IP.

However, the commit message says:

> Running a Clause 45 scan on an SMSC/Microchip LAN8720A PHY will (at
> least with our setup) considerably slow down kernel startup and
> ultimately result in a board reset.

So we need to clarify the real issue here. Does the C45 scan work
correctly, but the board watchdog timer is too short and fires? We
should not be extended this workaround when its a bad watchdog
configuration issue...

       Andrew