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

Date: Fri, 05 May 2023 23:30:12 +0200
From: Lorenz Brun <lorenz@...n.one>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: Quirks for exotic SFP module




Am Fr, 5. Mai 2023 um 20:53:43 +02:00:00 schrieb Andrew Lunn 
<andrew@...n.ch>:
> On Fri, May 05, 2023 at 07:39:12PM +0200, Lorenz Brun wrote:
>>  Hi netdev members,
> 
> For SFP matters, please Cc: SFP maintainer, and the PHY
> maintainers. See the MAINTAINERS file.
Thanks, I'll check that next time.

> 
>>  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.
> 
> It is amazing how many SFP manufactures cannot get the simple things
> like CRC right.
> 
>>  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.
> 
> Sounds sensible. Probably pointless, because SFP manufactures don't
> seem to care about quality, but please do print an warning that the
> bad checksum is being ignored.
I'm doing that in my WIP patch already.

> 
>>  There is also the issue of the module advertising 1000BASE-T:
> 
> Probably something for Russell, but what should be advertised?
> 1000Base-X?
I'd have gone for 1000Base-X as well, but I'll let others weigh in. 
1000BASE-T is definitely wrong IMO as there is no twisted pair Ethernet 
layer anywhere (there is twisted pair, but it's G.fast). AFAIK 
1000Base-X should stop Linux from messing with anything as it does not 
have any non-EEPROM-based management, right?

> 
>>  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.
> 
> Is there anything useful to be gained by talking to the PHY? Since it
> appears to be just a media converter, i guess the PHY having link is
> not useful. Does the LOS GPIO tell you about the G.Fast modem status?
AFAIK you cannot talk to the PHY as there isn't really an Ethernet PHY. 
The RGMII doesn't go to a PHY, it goes to the host interface which is a 
MAC of the modem SoC. Think of the modem SoC more of a computer then a 
plain modem.
While the SFP in its entirety behaves similar to a media converter the 
G.fast link is L2-agnostic and, even though it does in most cases carry 
Ethernet frames, any Ethernet managment interfaces (autoneg, ...) can't 
and shouldn't be extended to it.

I actually haven't checked the LOS GPIO. This thing runs ~1MiB of 
firmware and two different proprietary management protocols which I've 
reverse-engineered over which you can get tons of data about the 
current modem and link status. You need those to boot the SoC anyways. 
The TX disable GPIO puts the modem SoC into reset state and is used in 
case you use a host-based watchdog for the module.

Regards,
Lorenz