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:   Mon, 28 Jun 2021 10:33:54 +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 Sun, Jun 27, 2021 at 05:12:26PM +0200, Andrew Lunn wrote:
> This API is not just about CMIS, it covers any I2C connected SFP
> device. I'm more involved in the lower end, 1G, 2.5G and 10G. Devices
> in this category seem to be very bad a following the standards. GPON
> is especially bad, and GPON manufactures don't seem to care their
> devices don't follow the standard, they assume the Customer Premises
> Equipment is going to run software to work around whatever issues
> their specific GPON has, maybe they provide driver code? The API you
> are adding would be ideal for putting that driver in user space, as a
> binary blob. That is going to make it harder for us to open up the
> many millions of CPE used in FTTH. And there are people attempting to
> do that.
> 
> If devices following CMIS really are closely following the standard
> that is great. We should provide tooling to do firmware upgrade. But
> at the same time, we don't want to aid those who go against the
> standards and do their own thing. And it sounds like in the CMIS
> world, we might have the power to encourage vendors to follow CMIS,
> "Look, firmware upgrade just works for the competitors devices, why
> should i use your device when it does not work?"
> 
> I just want to make sure we are considering the full range of devices
> this new API will cover. From little ARM systems with 1G copper and
> FTTH fibre ports through to big TOR systems with large number of 100G
> ports.  If CMIS is well support by vendors, putting the code into the
> kernel, as a loadable module, might be the better solution for the
> whole range of devices the kernel needs to support.

If the goal is to limit what user space can do, then putting all the
code in the kernel and adding an ever-growing number of restrictive user
APIs is not the only way.

Even with the proposed approach, the kernel sits in the middle between
the module and user space. As such, it can maintain an "allow list" that
only allows access to modules with a specific memory map (CMIS and
SFF-8636 for now) and only to a subset of the pages which are
standardized by the specifications.