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: <e04d3835-6870-4b82-a9a5-cb2e0b8342f5@intel.com>
Date: Thu, 31 Jul 2025 10:00:44 +0300
From: "Ruinskiy, Dima" <dima.ruinskiy@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Jacob Keller <jacob.e.keller@...el.com>
CC: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>, Simon Horman
	<horms@...nel.org>, "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 31/07/2025 3:06, Jakub Kicinski wrote:
> On Wed, 30 Jul 2025 15:10:45 -0700 Jacob Keller wrote:
>>> 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...
> 
> I haven't played with udev in a while but it used to have the ability
> to run a command / script when device appears. So that'd be my first
> choice if how to hook the setting in when device is probed.

My concern here is not as much as how to set the private flag 
automatically at each boot (I leave this to the system administrator).

The concern is whether it can be set early enough during probe() to be 
effective. There is a good deal of HW access that happens during 
probe(). If it takes place before the flag is set, the HW can enter a 
bad state and changing K1 behavior later on does not always recover it.

With the module parameter, adapter->flags2 |= FLAG2_DISABLE_K1 gets set 
inside e1000e_check_options(), which is before any HW access takes 
place. If the private flag method can give similar guarantees, then it 
would be sufficient.

--Dima