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] [day] [month] [year] [list]

Message-ID: <a9794885-5801-401b-b892-f1fed4157a4f@intel.com>
Date: Sun, 3 Aug 2025 15:38:48 +0300
From: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>
To: Jacob Keller <jacob.e.keller@...el.com>, Jakub Kicinski <kuba@...nel.org>,
	"Ruinskiy, Dima" <dima.ruinskiy@...el.com>
CC: 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 7/31/2025 6:51 PM, Jacob Keller wrote:
> 
> 
> On 7/31/2025 7:19 AM, Jakub Kicinski wrote:
>> On Thu, 31 Jul 2025 10:00:44 +0300 Ruinskiy, Dima wrote:
>>> 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.

This was precisely the intention behind introducing the module parameter 
initially. The private flag isn't a comprehensive solution—it's more of 
a mechanism to allow configuration changes without unloading the e1000e 
module.

>>
>> Presumably you are going to detect all the bad SKUs in the driver to
>> the best of your ability. So we're talking about a workaround that lets
>> the user tweak things until a relevant patch reaches stable..

Regarding the SKUs: the issues we've encountered aren't tied to specific 
SKUs. Instead, they stem from broader environmental configurations that 
the driver cannot address directly. For instance, misconfigurations in 
the BIOS can only be resolved by the BIOS vendor, assuming they choose 
to do so. Until such fixes are available to end users, the module 
parameter provides a practical workaround for these system firmware issues.
>>
> 
> I think you could just default to K1 disabled, and have the parameter
> for turning it on/off available. Ideally you'd default to disabled only
> on known SKUs that are problematic?

As mentioned earlier, defaulting to K1 disabled isn't ideal. While it 
might help avoid certain issues on specific units, it would negatively 
impact the device's power consumption across all systems, the 
overwhelming majority of which would never experience any problem. 
Therefore, it's preferable to keep K1 enabled by default and allow users 
to disable it only when necessary.