linux-kernel - Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

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: <0530ea8e-eb81-74cd-5056-4ee6db8feb9e@intel.com>
Date: Sun, 27 Apr 2025 16:26:42 +0300
From: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>
To: Jacek Kowalski <jacek@...ekk.info>, Simon Horman <horms@...nel.org>
CC: Tony Nguyen <anthony.l.nguyen@...el.com>, Przemek Kitszel
	<przemyslaw.kitszel@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Jakub
 Kicinski" <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	<intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp
 when valid checksum mask is not set



On 4/24/2025 8:29 PM, Jacek Kowalski wrote:
> Hi,
> 
>>>> Because it is impossible to determine whether the NVM write would 
>>>> finish
>>>> correctly or hang (see 
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=213667)
>>>> it makes sense to skip the validation completely under these 
>>>> conditions.
> 
>> It is not completely accurate. All the NVMs starting from Tiger Lake 
>> are locked for writes, so NVM writes will always result in a failure.
> 
> Check my message in a thread of an earlier patch:
> 
> Message-ID: <1c4b00b6-f6e3-4b04-a129-24452df60903@...ekk.info>
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250407/047551.html 
> 
> 
> On my laptop NVM write operation *does not fail* (nor hangs), driver 
> loads and ethtool shows corrected checksum.
> 
> This lasts only until module reload (rmmod/insmod) or reboot.
> 
> I guess only shadow RAM is updated (or something like that) and not the 
> non-volatile memory, but the operation itself does not error out.

Yeah, probably this is what happens.

> 
> It might also be because I've disabled Secure Boot...
> 

Anyway, I think that the commit message should be precise.
How about this?

Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the 
driver cannot perform checksum validation and correction. This means 
that all NVM images must leave the factory with correct checksum and 
checksum valid bit set. Since Tiger Lake devices were the first to have 
this lock, some systems in the field did not meet this requirement. 
Therefore, for these transitional devices we skip checksum update and 
verification, if the valid bit is not set.