Message-ID: <a6d71bdc-3c40-49a1-94e5-369029693d06@jacekk.info>
Date: Mon, 31 Mar 2025 22:36:02 +0200
From: Jacek Kowalski <jacek@...ekk.info>
To: "Lifshits, Vitaly" <vitaly.lifshits@...el.com>,
 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

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).

-- 
Best regards,
   Jacek Kowalski

Powered by blists - more mailing lists