netdev - Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

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:   Thu, 27 Sep 2018 18:38:05 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Chris Preimesberger <chrisp@...nsition.com>
Cc:     Eran Ben Elisha <eranbe@...lanox.com>,
        Neil Horman <nhorman@...driver.com>,
        "linville@...driver.com" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold
 values for QSFP28 transceivers

On Thu, Sep 27, 2018 at 04:08:24PM +0000, Chris Preimesberger wrote:
> Please correct me if I'm wrong, but...
> It looks like Eran's proposed fix would remove all warning and
> alarm indications from ethtool's output. It's worth mentioning
> that for me, the following fields always reported correctly
> as Off while no alarm condition was present
> and On while alarm condition(s) were present
> *per the QSFP's true/programmed threshold values*
> *not per the incorrectly reported threshold values*

These alarm values are in the first page. So the information the
driver returns does contain this information. What is missing is the
thresholds, which are not provided by the driver.

But there is a comment in the code:

        /*
         * There is no clear identifier to signify the existence of
         * optical diagnostics similar to SFF-8472. So checking existence
         * of page 3, will provide the gurantee for existence of alarms
         * and thresholds
         * If pagging support exists, then supports_alarms is marked as 1
         */

These alarm values are optional. The spec says so. So in order to
decide if they are implemented, ethtool looks to see if the thresholds
are available. If there are thresholds, it makes sense the alarms are
implemented.

Unfortunately, the driver never returns the thresholds. So ethtool has
no real choice and won't display the alarms since it cannot determine
if they are valid.

In order to get alarms, the driver needs to be extended to return all
the pages.

    Andrew