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,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ