drivers/net/ethernet/intel/e1000e/e1000.h | 1 + drivers/net/ethernet/intel/e1000e/netdev.c | 22 ++++++++-------- drivers/net/ethernet/intel/e1000e/param.c | 30 ++++++++++++++++++++++ 3 files changed, 43 insertions(+), 10 deletions(-)
Many laptops and motherboards including I219-V network card have
invalid NVM checksum. While in most instances checksum is fixed by
e1000e module or by using bootutil, some setups are resistant to NVM
modifications. This result in the network card being completely
unusable.
It seems to be the case on Dell Latitude 5420 where UEFI firmware
corrupts (in this module's sense) checksums on each boot. No set of
BIOS options seems to help.
This commit adds e1000e module option called VerifyNVMChecksum
(defaults to 1) that allows advanced users to skip checkum verification
by setting it to 0.
Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
Cc: stable@vger.kernel.org
---
drivers/net/ethernet/intel/e1000e/e1000.h | 1 +
drivers/net/ethernet/intel/e1000e/netdev.c | 22 ++++++++--------
drivers/net/ethernet/intel/e1000e/param.c | 30 ++++++++++++++++++++++
3 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h b/drivers/net/ethernet/intel/e1000e/e1000.h
index ba9c19e6994c..61dcc88dd2ff 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -461,6 +461,7 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter, u32 *timinca);
#define FLAG2_CHECK_RX_HWTSTAMP BIT(13)
#define FLAG2_CHECK_SYSTIM_OVERFLOW BIT(14)
#define FLAG2_ENABLE_S0IX_FLOWS BIT(15)
+#define FLAG2_VERIFY_NVM_CHECKSUM BIT(16)
#define E1000_RX_DESC_PS(R, i) \
(&(((union e1000_rx_desc_packet_split *)((R).desc))[i]))
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 286155efcedf..b99b22dcaba4 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7567,16 +7567,18 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
adapter->hw.mac.ops.reset_hw(&adapter->hw);
- /* systems with ASPM and others may see the checksum fail on the first
- * attempt. Let's give it a few tries
- */
- for (i = 0;; i++) {
- if (e1000_validate_nvm_checksum(&adapter->hw) >= 0)
- break;
- if (i == 2) {
- dev_err(&pdev->dev, "The NVM Checksum Is Not Valid\n");
- err = -EIO;
- goto err_eeprom;
+ if (adapter->flags2 & FLAG2_VERIFY_NVM_CHECKSUM) {
+ /* systems with ASPM and others may see the checksum fail on the first
+ * attempt. Let's give it a few tries
+ */
+ for (i = 0;; i++) {
+ if (e1000_validate_nvm_checksum(&adapter->hw) >= 0)
+ break;
+ if (i == 2) {
+ dev_err(&pdev->dev, "The NVM Checksum Is Not Valid\n");
+ err = -EIO;
+ goto err_eeprom;
+ }
}
}
diff --git a/drivers/net/ethernet/intel/e1000e/param.c b/drivers/net/ethernet/intel/e1000e/param.c
index 3132d8f2f207..8711eb10dd11 100644
--- a/drivers/net/ethernet/intel/e1000e/param.c
+++ b/drivers/net/ethernet/intel/e1000e/param.c
@@ -127,6 +127,15 @@ E1000_PARAM(KumeranLockLoss, "Enable Kumeran lock loss workaround");
E1000_PARAM(WriteProtectNVM,
"Write-protect NVM [WARNING: disabling this can lead to corrupted NVM]");
+/* Verify NVM Checksum
+ *
+ * Valid Range: 0, 1
+ *
+ * Default Value: 1 (enabled)
+ */
+E1000_PARAM(VerifyNVMChecksum,
+ "Verify NVM checksum [WARNING: disabling can cause invalid behavior]");
+
/* Enable CRC Stripping
*
* Valid Range: 0, 1
@@ -524,4 +533,25 @@ void e1000e_check_options(struct e1000_adapter *adapter)
}
}
}
+ /* Verify NVM checksum */
+ {
+ static const struct e1000_option opt = {
+ .type = enable_option,
+ .name = "Verify NVM checksum",
+ .err = "defaulting to Enabled",
+ .def = OPTION_ENABLED
+ };
+
+ if (num_VerifyNVMChecksum > bd) {
+ unsigned int verify_nvm_checksum =
+ VerifyNVMChecksum[bd];
+ e1000_validate_option(&verify_nvm_checksum, &opt,
+ adapter);
+ if (verify_nvm_checksum)
+ adapter->flags2 |= FLAG2_VERIFY_NVM_CHECKSUM;
+ } else {
+ if (opt.def)
+ adapter->flags2 |= FLAG2_VERIFY_NVM_CHECKSUM;
+ }
+ }
}
--
2.39.5On 3/18/2025 10:46 PM, Jacek Kowalski wrote: > Many laptops and motherboards including I219-V network card have > invalid NVM checksum. While in most instances checksum is fixed by > e1000e module or by using bootutil, some setups are resistant to NVM > modifications. This result in the network card being completely > unusable. > > It seems to be the case on Dell Latitude 5420 where UEFI firmware > corrupts (in this module's sense) checksums on each boot. No set of > BIOS options seems to help. > > This commit adds e1000e module option called VerifyNVMChecksum > (defaults to 1) that allows advanced users to skip checkum verification > by setting it to 0. > > Signed-off-by: Jacek Kowalski <Jacek@jacekk.info> > Cc: stable@vger.kernel.org Hi Jacek, 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? 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. However, since in previous generations this was possible, it was, unfortunately, common practice by vendors to release the NVM without a valid checksum, relying on the e1000e module or on bootutil, as you mentioned, to “fix” it upon first boot. By 12th Gen systems, this practice was discontinued, and all NVMs were shipped with proper checksum. It is possible that some 11th Gen systems such as yours “slipped through the cracks”. 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. 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
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
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.
>> 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.
I finally had a moment to take a look at the issue again.
This change also makes everything work on my system:
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 364378133526..4538059091e6 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -4266,7 +4266,7 @@ static s32 e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
if (!(data & valid_csum_mask)) {
e_dbg("NVM Checksum valid bit not set\n");
- if (hw->mac.type < e1000_pch_tgp) {
+ if (hw->mac.type <= e1000_pch_tgp) {
data |= valid_csum_mask;
ret_val = e1000_write_nvm(hw, word, 1, &data);
if (ret_val)
(the modification is not persisted - it is lost even after rmmod/insmod).
The diff between "before" and "after" NVM rewrite looks like this
(MAC address masked):
< 0x0000: XX XX XX XX XX XX 00 08 ff ff 84 00 01 00 70 00
---
> 0x0000: XX XX XX XX XX XX 01 08 ff ff 84 00 01 00 70 00
10c10
< 0x0070: ff ff ff ff ff ff ff ff ff ff 00 02 ff ff fe 36
---
> 0x0070: ff ff ff ff ff ff ff ff ff ff 00 02 ff ff fd 34
Reading https://bugzilla.kernel.org/show_bug.cgi?id=213667 the issue
started with yet another Dell system, Precision 7760, locking itself
up with such modification.
The "fix" (4051f68318: e1000e: Do not take care about recovery NVM checksum)
fixed some problems (i.e. Precision 7760) and "broke" some configurations
(i.e. mine Latitude 5420).
The condition itself was changed once already (ffd24fa2fc: e1000e: Correct
NVM checksum verification flow).
> 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.
What solution do you have in mind?
The only one I can think of is to ignore the checksum completely if the
valid_csum_mask condition is not met on e1000_pch_tgp.
--
Best regards,
Jacek Kowalski
>> 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.
>
> What solution do you have in mind?
>
> The only one I can think of is to ignore the checksum completely if the
> valid_csum_mask condition is not met on e1000_pch_tgp.
Would you be OK with the following modification:
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 364378133526..df4e7d781cb1 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -4274,6 +4274,8 @@ static s32 e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
ret_val = e1000e_update_nvm_checksum(hw);
if (ret_val)
return ret_val;
+ } else if (hw->mac.type == e1000_pch_tgp) {
+ return 0;
}
}
?
--
Best regards,
Jacek Kowalski
> 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. 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 We have a similar issue with SFP, which contain a checksum. But a few vendors are lazy, they set a serial number and don't recalculate the checksum. We handle this by adding quirks. We know which vendors/products have FUBAR checksums, and allow them to be used when the checksum is FUBAR. You could do something similar here, add a list of vendors with known FUBAR checksums and allow them to be used, but taint the kernel, and print a warming that the device is unsupported because the vendor messed up the CRC. Andrew
>> 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. 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 > > We handle this by adding quirks. We know which vendors/products have > FUBAR checksums, and allow them to be used when the checksum is > FUBAR. You could do something similar here, add a list of vendors with > known FUBAR checksums and allow them to be used, but taint the kernel, > and print a warming that the device is unsupported because the vendor > messed up the CRC. Unfortunately at the device level I don't know what is the motherboard manufacturer and model to be able to determine whether I have the checksum messed up. I could peek up MAC address in NVM, but even then there is no reliable way to know which ranges of MAC addresses are indeed affected. -- Best regards, Jacek Kowalski
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacek Kowalski
> Sent: Tuesday, March 18, 2025 9:47 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Dumazet, Eric
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] e1000e: add option not to verify NVM
> checksum
>
> Many laptops and motherboards including I219-V network card have invalid
> NVM checksum. While in most instances checksum is fixed by e1000e module
> or by using bootutil, some setups are resistant to NVM modifications. This
> result in the network card being completely unusable.
>
> It seems to be the case on Dell Latitude 5420 where UEFI firmware corrupts (in
> this module's sense) checksums on each boot. No set of BIOS options seems
> to help.
>
> This commit adds e1000e module option called VerifyNVMChecksum
> (defaults to 1) that allows advanced users to skip checkum verification by
> setting it to 0.
>
> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
> Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/e1000e/e1000.h | 1 +
> drivers/net/ethernet/intel/e1000e/netdev.c | 22 ++++++++--------
> drivers/net/ethernet/intel/e1000e/param.c | 30
> ++++++++++++++++++++++
> 3 files changed, 43 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h
> b/drivers/net/ethernet/intel/e1000e/e1000.h
> index ba9c19e6994c..61dcc88dd2ff 100644
> --- a/drivers/net/ethernet/intel/e1000e/e1000.h
> +++ b/drivers/net/ethernet/intel/e1000e/e1000.h
> @@ -461,6 +461,7 @@ s32 e1000e_get_base_timinca(struct e1000_adapter
> *adapter, u32 *timinca);
> #define FLAG2_CHECK_RX_HWTSTAMP BIT(13)
> #define FLAG2_CHECK_SYSTIM_OVERFLOW BIT(14)
> #define FLAG2_ENABLE_S0IX_FLOWS BIT(15)
> +#define FLAG2_VERIFY_NVM_CHECKSUM BIT(16)
>
> #define E1000_RX_DESC_PS(R, i) \
> (&(((union e1000_rx_desc_packet_split *)((R).desc))[i])) diff --git
> a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 286155efcedf..b99b22dcaba4 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -7567,16 +7567,18 @@ static int e1000_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> */
> adapter->hw.mac.ops.reset_hw(&adapter->hw);
>
> - /* systems with ASPM and others may see the checksum fail on the
> first
> - * attempt. Let's give it a few tries
> - */
> - for (i = 0;; i++) {
> - if (e1000_validate_nvm_checksum(&adapter->hw) >= 0)
> - break;
> - if (i == 2) {
> - dev_err(&pdev->dev, "The NVM Checksum Is Not
> Valid\n");
> - err = -EIO;
> - goto err_eeprom;
> + if (adapter->flags2 & FLAG2_VERIFY_NVM_CHECKSUM) {
> + /* systems with ASPM and others may see the checksum fail
> on the first
> + * attempt. Let's give it a few tries
> + */
> + for (i = 0;; i++) {
> + if (e1000_validate_nvm_checksum(&adapter->hw) >=
> 0)
> + break;
> + if (i == 2) {
> + dev_err(&pdev->dev, "The NVM Checksum Is
> Not Valid\n");
> + err = -EIO;
> + goto err_eeprom;
> + }
> }
> }
>
> diff --git a/drivers/net/ethernet/intel/e1000e/param.c
> b/drivers/net/ethernet/intel/e1000e/param.c
> index 3132d8f2f207..8711eb10dd11 100644
> --- a/drivers/net/ethernet/intel/e1000e/param.c
> +++ b/drivers/net/ethernet/intel/e1000e/param.c
> @@ -127,6 +127,15 @@ E1000_PARAM(KumeranLockLoss, "Enable
> Kumeran lock loss workaround"); E1000_PARAM(WriteProtectNVM,
> "Write-protect NVM [WARNING: disabling this can lead to corrupted
> NVM]");
>
> +/* Verify NVM Checksum
> + *
> + * Valid Range: 0, 1
> + *
> + * Default Value: 1 (enabled)
> + */
> +E1000_PARAM(VerifyNVMChecksum,
> + "Verify NVM checksum [WARNING: disabling can cause invalid
> +behavior]");
> +
> /* Enable CRC Stripping
> *
> * Valid Range: 0, 1
> @@ -524,4 +533,25 @@ void e1000e_check_options(struct e1000_adapter
> *adapter)
> }
> }
> }
> + /* Verify NVM checksum */
> + {
> + static const struct e1000_option opt = {
> + .type = enable_option,
> + .name = "Verify NVM checksum",
> + .err = "defaulting to Enabled",
> + .def = OPTION_ENABLED
> + };
> +
> + if (num_VerifyNVMChecksum > bd) {
> + unsigned int verify_nvm_checksum =
> + VerifyNVMChecksum[bd];
> + e1000_validate_option(&verify_nvm_checksum,
> &opt,
> + adapter);
> + if (verify_nvm_checksum)
> + adapter->flags2 |=
> FLAG2_VERIFY_NVM_CHECKSUM;
> + } else {
> + if (opt.def)
> + adapter->flags2 |=
> FLAG2_VERIFY_NVM_CHECKSUM;
> + }
> + }
> }
> --
> 2.39.5
© 2016 - 2025 Red Hat, Inc.