linux-kernel - Re: forcedeth net driver: reverse mac address after pxe boot

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: <200610051628.40247.vda.linux@googlemail.com>
Date:	Thu, 5 Oct 2006 16:28:40 +0200
From:	Denis Vlasenko <vda.linux@...glemail.com>
To:	"Alex Owen" <r.alex.owen@...il.com>
Cc:	linux-kernel@...r.kernel.org, c-d.hailfinger.kernel.2004@....net,
	aabdulla@...dia.com
Subject: Re: forcedeth net driver: reverse mac address after pxe boot

On Wednesday 04 October 2006 18:19, Alex Owen wrote:
> I an issue with the forcedeth driver when used after the BIOS PXE routines.
> When booting directly from disk the ethernet MAC address is normal.
> eg: 00:16:17:xx:yy:zz
> But is the BIOS PXE boot stack loads pxelinux which then boots the
> local disk, or if pxelinux loads a kernel/initrd, then the MAC address
> detected by the forcedeth linux driver is reversed.
> eg zz:yy:xx:17:16:00
> 
> This is obviously causes me a problem with automated installs started
> via PXE boot as the installed cannot DHCP as the MAC address is wrong.
> 
> I have read some of the bug reports and LKML threads on WOL and
> forcedeth and I have looked at the code of the driver... most closely
> forcedeth v57 as per comment #22 of
> http://bugzilla.kernel.org/show_bug.cgi?id=6604
> 
> My understanding of the code is that the driver determines the cards
> MAC address by reading from registers in the ethernet controller, but
> that for reasons best known to nvidia this  address backwards and so
> the driver "fixes" this by itself reversing the read values and
> writing them back to the controller.
> 
> This normally works ok and there has been some work to put the old
> "wrong" MAC address back at close down to get WOL to work to.
> 
> Enter PXE... Booting from PXE (in BIOS) seems to "fixup" the "wrong"
> MAC address so when the driver determines the cards MAC address by
> reading from registers in the ethernet controller then MAC address
> there is now CORRECT. The driver however assumes it is reversed and in
> trying to "fix" the MAC address is infact writes back the
> revesed/broken MAC back to the controller.
> 
> 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?
> 
> The other solution would be unconditionally reset the controler to
> it's power on state then use the current logic? can we reset the
> controller via software?
> There does seem to be an nv_mac_reset function... and this does seem
> to be called if the card has a capability DEV_HAS_POWER_CONTROL but it
> is called in nv_open() while the MAC is read in nv_probe().
> 
> Perhaps we need to unconditionally run nv_mac_reset just before
> reading the MAC in nv_probe() ?
> 
> Anyway I hope that someone who knows kernel internals and this driver
> inparticular feels the urge to look at this!

Also MAC addresses cannot be arbitrary. If nothing else would work,
we can add OUI numbers (3 most significant bytes of MAC)
of known suppliers of nvidia eth and check whether they are
in lower bytes or in higher ones.
--
vda
-
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/