netdev - Re: ethtool's eeprom_parse fails to determine plug type due to short read

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] [day] [month] [year] [list]

Message-ID: <Y+GtLXDTJj3tUMty@lunn.ch>
Date:   Tue, 7 Feb 2023 02:45:17 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Christian Svensson <christian@....nu>
Cc:     mkubecek@...e.cz, netdev@...r.kernel.org,
        Viktor Ekmark <viktor@...ark.se>
Subject: Re: ethtool's eeprom_parse fails to determine plug type due to short
 read

On Mon, Feb 06, 2023 at 08:06:31PM +0100, Christian Svensson wrote:
> Hi,
> 
> I am currently running a system with an Intel E810 ("ice") card as
> well as 2x QSFP28 transceivers made by ColorChip.
> The behavior I am observing for these modules is that they return
> zeroed data unless the read length is greater than 8.
> 
> $ sudo ethtool -m ens1f1 hex on length 8
> Offset          Values
> ------          ------
> 0x0000:         00 00 00 00 00 00 00 00
> $ sudo ethtool -m ens1f1 hex on length 9
> Offset          Values
> ------          ------
> 0x0000:         11 07 02 00 00 00 00 00 00
> 
> eeprom_parse uses a 1-byte read to determine the type of module. This
> obviously fails in this case and the function resorts to printing an
> hex dump - which ironically contains the correct EEPROM data.
> 
> I can see three options to handle this case:
> 1) Continue using 1-byte read, let ethtool be broken for these types
> of modules (the current state)
> 2) Switch to using e.g. a 16 byte read. Might break other modules?
> 3) Use a 1-byte read, and if it returns zero as the type byte, retry
> with e.g. a 16 byte read to see if that works better.

4) Throw the modules away since they probably don't fulfil the standard.

The problem with 4) is, most modules are broken in one way or
another. There are some modules which cannot do anything but 1-byte
reads. Which then means all the statistics you get from them are
broken because that requires 2-byte atomic reads....

The generic SFP code in drivers/net/phy/sfp.c starts out reading using
16 byte blocks. But there are some SFPs which are broken, return one
valid byte followed by 0s. So during probe of the SFP it looks for
this, and changes the block size to 1, etc.

Since the ICE driver does not use this generic code, you need to talk
with Intel about what workaround they are prepared to support.

     Andrew