netdev - Re: [PATCH 1/2] net: phy: improve phylib correctness for non-autoneg settings

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]

Date:   Mon, 17 Apr 2017 13:25:29 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     rmk+kernel@...linux.org.uk
Cc:     f.fainelli@...il.com, andrew@...n.ch, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] net: phy: improve phylib correctness for
 non-autoneg settings

From: Russell King <rmk+kernel@...linux.org.uk>
Date: Thu, 13 Apr 2017 16:49:15 +0100

> phylib has some undesirable behaviour when forcing a link mode through
> ethtool.  phylib uses this code:
> 
> 	idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex),
> 			features);
> 
> to find an index in the settings table.  phy_find_setting() starts at
> index 0, and scans upwards looking for an exact speed and duplex match.
> When it doesn't find it, it returns MAX_NUM_SETTINGS - 1, which is
> 10baseT-Half duplex.
> 
> phy_find_valid() then scans from the point (and effectively only checks
> one entry) before bailing out, returning MAX_NUM_SETTINGS - 1.
> 
> phy_sanitize_settings() then sets ->speed to SPEED_10 and ->duplex to
> DUPLEX_HALF whether or not 10baseT-Half is supported or not.  This goes
> against all the comments against these functions, and 10baseT-Half may
> not even be supported by the hardware.
> 
> Rework these functions, introducing a new method of scanning the table.
> There are two modes of lookup that phylib wants: exact, and inexact.
> 
> - in exact mode, we return either an exact match or failure
> - in inexact mode, we return an exact match if it exists, a match at
>   the highest speed that is not greater than the requested speed
>   (ignoring duplex), or failing that, the lowest supported speed, or
>   failure.
> 
> The biggest difference is that we always check whether the entry is
> supported before further consideration, so all unsupported entries are
> not considered as candidates.
> 
> This results in arguably saner behaviour, better matches the comments,
> and is probably what users would expect.
> 
> This becomes important as ethernet speeds increase, PHYs exist which do
> not support the 10Mbit speeds, and half-duplex is likely to become
> obsolete - it's already not even an option on 10Gbit and faster links.
> 
> Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>

Applied to net-next