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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20ab7355-fc72-4dba-b3ea-db2244909bab@lunn.ch>
Date: Thu, 25 Jan 2024 21:45:36 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Danielle Ratson <danieller@...dia.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, corbet@....net,
	linux@...linux.org.uk, sdf@...gle.com, kory.maincent@...tlin.com,
	maxime.chevallier@...tlin.com, vladimir.oltean@....com,
	przemyslaw.kitszel@...el.com, ahmed.zaki@...el.com,
	richardcochran@...il.com, shayagr@...zon.com,
	paul.greenwalt@...el.com, jiri@...nulli.us,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	mlxsw@...dia.com, petrm@...dia.com, idosch@...dia.com
Subject: Re: [RFC PATCH net-next 1/9] ethtool: Add ethtool operation to write
 to a transceiver module EEPROM

On Thu, Jan 25, 2024 at 09:26:16PM +0100, Andrew Lunn wrote:
> On Mon, Jan 22, 2024 at 10:45:22AM +0200, Danielle Ratson wrote:
> > From: Ido Schimmel <idosch@...dia.com>
> > 
> > Ethtool can already retrieve information from a transceiver module
> > EEPROM by invoking the ethtool_ops::get_module_eeprom_by_page operation.
> > Add a corresponding operation that allows ethtool to write to a
> > transceiver module EEPROM.
> > 
> > The purpose of this operation is not to enable arbitrary read / write
> > access, but to allow the kernel to write to specific addresses as part
> > of transceiver module firmware flashing. In the future, more
> > functionality can be implemented on top of these read / write
> > operations.
> 
> My memory is dim, but i thought we decided that since the algorithm to
> program these modules is defined in the standard, all we need to do is
> pass the firmware blob, and have an in kernel implementation of the
> algorithm. There is no need to have an arbitrary write blob to module,
> which might, or might not be abused in the future.

O.K, back after reading more of the patches.

If i'm understanding the code correctly, this is never exposed to
userspace? Its purely an in kernel API? It would be good to make that
clear in the commit message, and document that in the ethtool ops
structure.

Thanks
      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ