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

Message-ID: <CADiuDATAsP7cvxmV9d8=P0j=75XRxvX3jm32d6PQ_Wqv8NR_6Q@mail.gmail.com>
Date:   Mon, 6 Feb 2023 20:06:31 +0100
From:   Christian Svensson <christian@....nu>
To:     mkubecek@...e.cz
Cc:     netdev@...r.kernel.org, Viktor Ekmark <viktor@...ark.se>
Subject: ethtool's eeprom_parse fails to determine plug type due to short read

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.

Thoughts?

Regards,