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: <6da69e2c-2090-a598-c601-6ce926f69872@gmail.com>
Date:   Sat, 5 Jan 2019 22:07:50 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
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

On 05.01.2019 18:33, Andrew Lunn wrote:
> On Sat, Jan 05, 2019 at 02:21:03PM +0100, Heiner Kallweit wrote:
>> During a bug analysis we came across the fact that there's no guarantee
>> that reading from the ID registers returns a valid value if PHY is
>> powered down. When reading invalid values we may load no or the wrong
>> PHY driver. Therefore let's play safe and power up the PHY before
>> reading the ID registers in case PHY is powered down.
>>
>> Suggested-by: Florian Fainelli <f.fainelli@...il.com>
>> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
>> ---
>>  drivers/net/phy/phy_device.c | 23 +++++++++++++----------
>>  1 file changed, 13 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 9560a2b84..d4702313d 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -754,19 +754,22 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id,
>>  	if (is_c45)
>>  		return get_phy_c45_ids(bus, addr, phy_id, c45_ids);
> 
> Hi Heiner
> 
>>  
>> +	phy_reg = mdiobus_read(bus, addr, MII_BMCR);
>> +	if (phy_reg < 0)
>> +		/* returning -ENODEV allows to continue bus-scanning */
>> +		return (phy_reg == -EIO || phy_reg == -ENODEV) ? -ENODEV : -EIO;
> 
> It would be better to copy the code verbatim. I know we have had
> issues with scanning depending on the return value. So changing the
> return value should be in a separate patch. I would also not make it a
> fix, but something for net-next, so it gets more testing.
> 
The only caller of get_phy_id() is get_phy_device() which translates
a PHY ID of 0xffffffff back to -ENODEV. So this should be safe and
it avoids some overhead. But right, this is more net-next stuff.

Regarding net vs. net-next:
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.

>> +
>> +	/* PHY may be powered down and ID registers invalid */
>> +	if (phy_reg & BMCR_PDOWN) {
>> +		mdiobus_write(bus, addr, MII_BMCR, phy_reg & ~BMCR_PDOWN);
>> +		/* give the PHY some time to resume */
>> +		msleep(100);
>> +	}
>> +
> 
> 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
- the MDIO bus read operation returns 0xffff in case of an error instead
  of a proper errno. To mitigate this we could treat 0xffff as failure
  because normally BMCR can never have this value.

> Thanks
> 	Andrew
> 
Heiner