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: <20180926215812.GD1251@lunn.ch>
Date:   Wed, 26 Sep 2018 23:58:12 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Neil Horman <nhorman@...driver.com>
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

> 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.

Oh dear.

   Andrew