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]

Message-ID: <20210629102705.6685704b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 29 Jun 2021 10:27:05 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        davem@...emloft.net, 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, 24 Jun 2021 22:38:27 +0300 Ido Schimmel wrote:
> > I also wonder if it is safe to perform firmware upgrade from user
> > space?  
> 
> I have yet to write the relevant code in ethtool(8), but it should be
> safe. See more below.

What's unclear to me is what difference does it make whether the code is
in kernel or in ethtool.git. If modules follow the standard the code
churn will be low. And we have to type the code up anyway it seems it
doesn't matter where it lies.

Where it does matter is if one wants to reuse existing user space built
on top of raw read/write interfaces.

IOW it shouldn't matter if we put the code in the kernel or user space
from effort perspective, but the latter is more risky.

You mention some limited sensor resources, isn't this exactly the
resource management the kernel is supposed to perform?