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
