| 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
| ||
|
Message-ID: <DBFABB80F7FD3143A911F9E6CFD477B0189CAB06@hqemmail02.nvidia.com> Date: Thu, 5 Oct 2006 12:45:09 -0700 From: "Ayaz Abdulla" <AAbdulla@...dia.com> To: "John W. Linville" <linville@...driver.com>, "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006@....net> Cc: "Alex Owen" <r.alex.owen@...il.com>, <linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>, "Alan Cox" <alan@...rguk.ukuu.org.uk> Subject: RE: forcedeth net driver: reverse mac address after pxe boot The BIOS will write to the mac address register. The address will be written in reverse order. This bug has already been fixed in the PXE code. Can you let me know what version of PXE you are running (it should display the version on the screen during boot up)? Thanks, Ayaz -----Original Message----- From: John W. Linville [mailto:linville@...driver.com] Sent: Thursday, October 05, 2006 12:31 PM To: Carl-Daniel Hailfinger Cc: Alex Owen; linux-kernel@...r.kernel.org; Ayaz Abdulla; H. Peter Anvin; Alan Cox Subject: Re: forcedeth net driver: reverse mac address after pxe boot On Thu, Oct 05, 2006 at 08:35:05PM +0200, Carl-Daniel Hailfinger wrote: > John W. Linville wrote: > > On Wed, Oct 04, 2006 at 05:19:20PM +0100, Alex Owen wrote: > > > >> The obvious fix for this is to try and read the MAC address from the > >> canonical location... ie where is the source of the address writen > >> into the controlers registers at power on? But do we know where that > >> may be? > > > > This seems like The Right Thing (TM) to me, but we need someone from > > NVidia(?) to provide that information. Ayaz? > > The canonical location of the "original" MAC address is where we write > back the reversed MAC address. So that won't work. I think you misunderstand the suggestion (which is admittedly based on supposition). On most devices, the MAC address is programmed into a register at runtime. It is not "burned-in" to the device itself. Instead it is usually stored in some sort of eeprom/nvram/flash/whatever. The driver retrieves it at runtime from the nvram and programs it into the device. In this case, the forcedeth driver is retrieving the MAC address from a register, reversing it, and writing it back to the _same_ register. Experience suggests that this register is unlikely to have "magically" received that information. The supposition is that instead some firmware has pre-loaded the register, perhaps at IPL? It is possible that the device itself is loading the MAC address from e.g. a serial eeprom tied to the device and inaccessible to the CPU. If that is the case, there may be no other solution than the current silliness. Since the driver is reversed engineered, the current silliness (and a prayer for fixed PXE firmware) is the only good alternative we have. John -- John W. Linville linville@...driver.com ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- - 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