netdev - Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to transceiver module EEPROMs

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]

Date:   Tue, 29 Jun 2021 22:12:07 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org, jiri@...dia.com,
        vladyslavt@...dia.com, moshe@...dia.com, vadimp@...dia.com,
        mkubecek@...e.cz, mlxsw@...dia.com,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to
 transceiver module EEPROMs

On Sunday 27 June 2021 13:33:13 Ido Schimmel wrote:
> On Thu, Jun 24, 2021 at 10:27:13PM +0200, Andrew Lunn wrote:
> > We have the choice here. We can add a write method to the kAPI, add
> > open source code to Ethtool using that API, and just accept people are
> > going to abuse the API for all sorts of horrible things in user space.
> > Or we can add more restrictive kAPIs, put more code in the kernel, and
> > probably limit user space doing horrible things. Maybe as a side
> > effect, SFP vendors contribute some open source code, rather than
> > binary blobs?
> 
> I didn't see any code or binary blobs from SFP vendors and I'm not sure
> how they can provide these either. Their goal is - I believe - to sell
> as much modules as possible to what the standard calls "systems
> manufactures" / "system integrators". Therefore, they cannot make any
> assumptions about the I2C connectivity (whether to the ASIC or the CPU),
> the operating system running on the host and the user interface (ioctl /
> netlink etc).

Hello! This is really happening in GPON world. Most GPON SFP modules are
working only in few devices with SFP cages. And it is either because
GPON SFP module vendor provided to vendor of device with SFP cage how to
"hack", initialize and use that GPON module properly or because we have
figured out how particular GPON modules violate SFF standards and added
special quirks per SFP module or per chipset in SFP module.

And the other thing which is happening. If vendor of GPON SFP module is
the same as vendor of device with SFP cage then it is doing everything
to ensure that only its GPON SFP modules would work in its devices. Or
to ensure that its OLT station (opposite end of GPON client SFP module)
would link only with its branded GPON SFP modules.

Classic vendor lockin. If ISP is using OLT station from vendor A then A
wants that you cannot use GPON SFP modules from vendor B on that
network.

You said that vendor goal is to sell as much modules as possible. Seem
that this is truth and vendors are doing it by above vendor lockin
strategy only.

So at the end I really do not like raw RW access to SFP EEPROM. This
just opens a new door for vendor lockin and vendor blob strategy.

And the last thing is that rewriting EEPROM on arbitrary SFP module may
lead to total damage of SFP. Specially on SFPs with "computer inside"
where parts of (critical) memory is shadowed in SFP EEPROM space.