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: <44BFBE9F.7070600@intel.com>
Date:	Thu, 20 Jul 2006 10:34:23 -0700
From:	Auke Kok <auke-jan.h.kok@...el.com>
To:	Pavel Machek <pavel@....cz>
CC:	Auke Kok <auke-jan.h.kok@...el.com>, cramerj@...el.com,
	john.ronciak@...el.com, jesse.brandeburg@...el.com,
	jeffrey.t.kirsher@...el.com,
	kernel list <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>
Subject: Re: e1000: "fix" it on thinkpad x60 / eeprom checksum read fails

Pavel Machek wrote:
> Hi!
> 
>>> e1000 in thinkpad x60 fails without this dirty hack. What to do with
>>> it?
>>>
>>> Signed-off-by: Pavel Machek <pavel@...e.cz>
>> NAK, certainly this should never be merged in any tree...
>>
>> this is a known issue that we're tracking here:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1474679&group_id=42302&atid=447449
>>
>> Summary of the issue:
>>
>> Lenovo has used certain BIOS versions where ASPD/DSPD was turned on which 
>> turns the PHY off when no cable is inserted to save power. The e1000 driver 
>> already turns off this feature but can't do this until the driver is 
>> loaded. It seems that turning this feature on causes the MAC to give read 
>> errors.
>>
>> Lenovo seems to have the feature turned off in their latest BIOS versions, 
>> we encourage all people to upgrade their BIOS with the latest version from 
>> Lenovo (available from their website). It seems that for at least 2 people, 
>> this has fixed the problem.
>>
>> Inserting a cable obviously might also work :)
> 
> Hehe.
> 
>> We did reproduce the problem initially with the old BIOS (1.01-1.03) on a 
>> T60 system, but unfortunately the bug disappeared into nothingness.
>>
>> Bypassing the checksum leaves the NIC in an uncertain state and is not 
>> recommended.
> 
> Okay, perhaps this should be inserted as a comment into the driver,
> and printk should be fixed to point at this explanation?
> 
> Can't we enable the driver with the bad checksum, then read the _real_
> data?

no.

We're working on a solution where we make sure that the PHY is physically 
turned on properly before we read the EEPROM, which would be the proper fix. 
It's completely not acceptable to run when the EEPROM checksum fails - you 
might even be running with the wrong MAC address, or worse. Lets fix this the 
right way instead.

Auke

PS: adding netdev to the CC...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ