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]

Message-ID: <20180927132309.GA12328@hmswarspite.think-freely.org>
Date:   Thu, 27 Sep 2018 09:23:09 -0400
From:   Neil Horman <nhorman@...driver.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Chris Preimesberger <chrisp@...nsition.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 Wed, Sep 26, 2018 at 11:58:12PM +0200, Andrew Lunn wrote:
> > When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> > to determine the length of the eeprom, and that value will be either 256 or 512
> > bytes.
> 
> So it sounds like QSFP modules using 8636 are not supported. You would
> expect a size to be one of 256, 384, 512 or 640.
> 
> > Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> > read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> > from hardware, again, passing in 256 as the size for the first call (theres a
> > loop, but it will only get executed once in this scenario)
> > 
> > mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> > eeprom.  Here it starts to go sideways.  The mailbox buffer allocated for the
> > return data is of type mlx4_mad_ifc, which has some front matter information and
> > a data buffer that is 192 bytes long!
> 
> Which suggests all SFP dumps are broken as well, not just QSFP.
> 
No, not at all.  Each driver that implements a get_eeprom ethtool method, is
capable of doing multiple reads at various offsets, and filling up the user
buffer with real data.  The bug here is that the mellanox data structures are
not sized properly vis a vis the amount of eeprom data that user space might
expect, or more specifically that the driver isn't smart enough to do several
small reads to fill up the full sized request buffer

Neil

> Oh dear.
> 
>    Andrew
>