netdev - Re: [PATCH net] net: phy: ensure PHY is powered up when reading ID registers

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: <20190105220412.GC30438@lunn.ch>
Date:   Sat, 5 Jan 2019 23:04:12 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: phy: ensure PHY is powered up when reading ID
 registers

> Quite a few of the latest net commits don't meet the strict criteria
> for a fix (as documented). Means: The risk that a problem could
> occur isn't sufficient, at least one user has to actually face a
> problem. So it seems net vs. net-next criteria is somewhat flexible.
> Therefore I wasn't sure in this case.

Hi Heiner

I tend to be more paranoid after listening to recent discussions about
this. At LPC and online, there have been comments that patches to
stable are more likely to break something than patches going via the
normal merge window. Normal patches get a lot more testing, are in -rc
kernels for 6 or more weeks, etc, where as stable patches go live
after a week or less of testing.

> > Is this potentially slowing the scan down to 100ms * 32, if the read
> > of MII_BMCR always returns 0xffff?
> > 
> Indeed, in a worst case scenario this could happen, provided that:
> - there's no mask of MDIO addresses to probe

Which is pretty normal

> - the MDIO bus read operation returns 0xffff in case of an error instead
>   of a proper errno.

The bus driver cannot easily return an proper errno. The MDIO protocol
mostly has no way to indicate if there is a device on the bus. There
is the TA bit, but many PHYs are broken, so most bus drivers just
ignore it. And the bus is wired with a pull-up. So a read on an
address with no device will return 0xffff.

	Andrew