netdev - Re: [Intel-wired-lan] [PATCH] e1000e: add option not to verify NVM checksum

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: <ca5e7925-1d75-5168-2c54-1f4fa9ef523e@intel.com>
Date: Thu, 10 Apr 2025 15:13:44 +0300
From: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>
To: Jacek Kowalski <jacek@...ekk.info>, 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>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH] e1000e: add option not to verify NVM
 checksum



On 3/31/2025 11:36 PM, Jacek Kowalski wrote:
> Hi,
> 
>> Are you certain that the UEFI FW corrupts the checksum each time, or 
>> is it just that the system left the factory with incorrect checksum?
> 
> I'm quite far from that device at the moment, but from what I remember:
> 
> - when I forced the NVM update path in the driver, the device would work,
> - after the reboot the checksum was invalid again.
> 
> I'll experiment a little more and get back to you. Specifically I'll try 
> to dump the NVM contents before and after running 
> e1000e_update_nvm_checksum and after a reboot.
> 
> Maybe the "shadow RAM" was correctly updated, but the change was 
> (silently?) not persisted due to the security change you mention:
> 
>> From what we know, the Latitude E5420 is 11th Gen Intel CPU (Tiger Lake).
>> Starting from this generation, a security change makes it impossible 
>> for software to write to the I219 NVM.
> 
> 
>> From a technical perspective, your patch looks correct. However, if 
>> the checksum validation is skipped, there is no way to distinguish 
>> between the simple checksum error described above, and actual NVM 
>> corruption, which may result in loss of functionality and undefined 
>> behavior.
> 
> The distinction between checksum error and corruption will be performed 
> by sufficiently privileged user, who must set the properly marked flag 
> in the driver in order to do so. Is it more "insecure" than disabling 
> NVM write protection (flag above)?
> 
> Note that I am not the only one with this issue...
> 
> Precision 7560 (also 11th gen):
> https://www.dell.com/community/en/conversations/precision-mobile-workstations/precision-7560-e1000e-module-error-the-nvm-checksum-is-not-valid/647f9784f4ccf8a8dea83444 
> 
> 
> Latitude 5420 (same as mine):
> https://forums.linuxmint.com/viewtopic.php?t=412046
> https://bbs.archlinux.org/viewtopic.php?id=269606
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2102113
> https://community.tanium.com/s/question/0D5RO00000Chk2S0AR/tanium-provision-dell-latitude-5420-onboard-nic 
> 
> 
> EVGA Z590 mainboard:
> https://www.linux.org/threads/getting-intel-i219-v-to-work-in-debian-12.45761/ 
> 
> 
> I am quite sure that Dell nor other manufacturers won't do anything with 
> it...
> 
> I'm also interested in how the Windows driver works around such an issue.
> 
> 
>  > This means, that if there is any functional issue with the network
>  > adapter on a given system, while checksum validation was suspended by
>  > the user, we will not be able to offer support
> 
> Is completely non functional adapter (as mine) covered by this support 
> promise?
> 
> 
> Wrapping up: if nothing else works, what would you see as a possible way 
> forward?
> 
> 1. This flag.
> 
> 2. Option to override the checksum value (compare with a given value 
> rather than ignoring it completely).
> 
> 3. Option to force NVM update (provided that my tests will show that it 
> works - even if only until a reboot).
> 

As we are aware, Tigerlake systems, like the one you have, were the 
first to implement NVM locking for write operations. Some manufacturers 
have encountered issues with this NVM generation. To address these 
challenges, I propose providing a workaround applicable to all affected 
systems. This solution will ensure that anyone experiencing similar 
issues can implement a fix without requiring a technical background to 
enable private flags.

If this approach is acceptable to you, I will prepare a patch with the 
proposed fix and send it to you next week for testing on your system.