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: <CAMqyJG2Kv90bzJNu10mPrmHQrfi5FL1eQPCufD3n=CNcDNMYkA@mail.gmail.com>
Date: Thu, 28 Aug 2025 15:15:52 +0800
From: En-Wei WU <en-wei.wu@...onical.com>
To: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>
Cc: Jacob Keller <jacob.e.keller@...el.com>, Jakub Kicinski <kuba@...nel.org>, 
	"Ruinskiy, Dima" <dima.ruinskiy@...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

> Regarding the SKUs: the issues we've encountered aren't tied to specific SKUs

>From our side, the issue is only specific to an SKU. If that's also
the case from other sides, I'm wondering if it's possible to add a
quirk table for enabling/disabling K1 configuration.
The upside would be:
1. There is no need for a user to bother giving the module parameter
2. Let the kernel problem leave in the kernel

Thanks for your time. Please let me know your concern.

On Sun, 3 Aug 2025 at 20:39, Lifshits, Vitaly <vitaly.lifshits@...el.com> wrote:
>
>
>
> 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.
>