netdev - Quirks for exotic SFP module

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]

Date: Fri, 05 May 2023 19:39:12 +0200
From: Lorenz Brun <lorenz@...n.one>
To: netdev@...r.kernel.org
Subject: Quirks for exotic SFP module

Hi netdev members,

I have some SFP modules which contain a G.fast modem (Metanoia MT5321). 
In my case I have ones without built-in flash, which means that they 
come up in bootloader mode. Their EEPROM is emulated by the onboard 
CPU/DSP and is pretty much completely incorrect, the claimed checksum 
is 0x00. Luckily there seems to be valid vendor and part number 
information to quirk off of.

I've implemented a detection mechanism analogous to the Cotsworks one, 
which catches my modules. Since the bootloader is in ROM, we sadly 
cannot overwrite the bad data, so I just made it skip the CRC check if 
this is an affected device and the expected CRC is zero.

There is also the issue of the module advertising 1000BASE-T:

 Identifier : 0x03 (SFP)
 Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 Connector : 0x22 (RJ45)
 Transceiver codes : 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x00
 Transceiver type : Ethernet: 1000BASE-T
 Encoding : 0x01 (8B/10B)
 BR, Nominal : 0MBd
 Rate identifier : 0x00 (unspecified)
 Length (SMF,km) : 0km
 Length (SMF) : 0m
 Length (50um) : 0m
 Length (62.5um) : 0m
 Length (Copper) : 0m
 Length (OM3) : 0m
 Laser wavelength : 0nm
 Vendor name : METANOIA
 Vendor OUI : 00:00:00
 Vendor PN : MT5321
 Vendor rev : 0001
 Option values : 0x08 0x00
 Option : Retimer or CDR implemented
 BR margin, max : 0%
 BR margin, min : 0%
 Vendor SN :
 Date code : ________

But the module internally has an AR8033 1000BASE-X to RGMII converter 
which is then connected to the modem SoC, so as far as I am aware this 
is incorrect and could cause Linux to do things like autonegotiation 
which definitely does not work here. So this probably needs to be 
quirked away. Anything else I have missed which needs to be changed?

Also, should the quirks and the workaround for the missing checksum be 
separate?

Thanks for your help!
Regards,
Lorenz