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

Date:   Sun, 27 Jun 2021 13:33:13 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     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 Thu, Jun 24, 2021 at 10:27:13PM +0200, Andrew Lunn wrote:
> > I fail to understand this logic. I would understand pushing
> > functionality into the kernel in order to create an abstraction for user
> > space over different hardware interfaces from different vendors. This is
> > not the case here. Nothing is vendor specific. Not to the host vendor
> > nor to the module vendor.
> 
> Hi Ido

Hi Andrew,

> 
> My worry is, we are opening up an ideal vector for user space drivers
> for SFPs. And worse still, closed source user space drivers. We have
> had great success with switchdev, over a hundred supported switches,
> partially because we have always pushed back against kAPIs which allow
> user space driver, closed binary blobs etc.

I don't think it's a correct comparison. Switch ASICs don't have a
standardized interface towards the host. It is therefore essential that
the kernel will abstract these differences to user space.

> 
> 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).

Given all these moving parts, I don't see how they can provide any
tooling. It is in their best interest to simply follow the standard and
make the tooling a problem of the "systems manufactures" / "system
integrators". In fact, the user who requested this functionality claims:
"the cable vendors don't develop the tools to burn the FW since the
vendors claim that the CMIS is supported". The user also confirmed that
another provider "is able to burn the FW for the cables from different
vendors".

> 
> I tend to disagree about adding kAPIs which allow write. But i would
> like to hear other peoples opinions on this.
> 
>      Andrew
>