netdev - Re: [RFC net-next v1 1/1] e1000e: Introduce private flag and module param to disable K1

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: <55570ac6-8cd7-4a00-804e-7164f374f8ae@intel.com>
Date: Wed, 30 Jul 2025 15:10:45 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, "Lifshits, Vitaly"
	<vitaly.lifshits@...el.com>
CC: Simon Horman <horms@...nel.org>, "Ruinskiy, Dima"
	<dima.ruinskiy@...el.com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>
Subject: Re: [RFC net-next v1 1/1] e1000e: Introduce private flag and module
 param to disable K1

On 7/30/2025 1:42 PM, Jakub Kicinski wrote:
> On Wed, 30 Jul 2025 16:28:48 +0100 Simon Horman wrote:
>> My opinion is that devlink is the correct way to solve this problem.
>> However, I do understand from the responses above (3) that this is somewhat
>> non-trivial to implement and thus comes with some risks. And I do accept
>> your argument that for old drivers, which already use module parameters,
>> some pragmatism seems appropriate.
>>
>> IOW, I drop my objection to using a module parameter in this case.
>>
>> What I would suggest is that some consideration is given to adding devlink
>> support to this driver. And thus modernising it in that respect. Doing so
>> may provide better options for users in future.
> 
> FWIW I will still object. The ethtool priv flag is fine, personally 
> I don't have a strong preference on devlink vs ethtool priv flags.
> But if you a module param you'd need a very strong justification..

I think just the ethtool private flag is sufficient. The primary
downside appears to be the "inability" to easily set the flag at boot,
but...

At a minimum you can create a systemd service file set as a one shot
script which executes at boot, and issues the command. Alternatively it
may be possible to get NetworkManager or systemd-networkd to issue the
command automatically.

Being targeted at the device is a lot better semantics than being
targeted at every device owned by e1000e.

I also have no objection to setting it as a devlink parameter. If the
device had permanent NVM storage for the setting, that would be even
better.

I understand the motivation for not wanting to enable devlink due to the
extra development cost to integrate it into the e1000e driver. I'll
leave that decision up to Vitaly and team.

Thanks,
Jake

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)