linux-kernel - Re: forcedeth: MAC-address reversed on resume from suspend

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: <20080102214843.GA19224@rhlx01.hs-esslingen.de>
Date:	Wed, 2 Jan 2008 22:48:43 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Richard Jonsson <richie@...erworld.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: forcedeth: MAC-address reversed on resume from suspend

Hi,

On Wed, Jan 02, 2008 at 10:04:49PM +0100, Richard Jonsson wrote:
> Bugreport regarding forcedeth driver.
>
> When returning from suspend-to-RAM the MAC-address byteorder is reversed. 
> After another suspend-resume cycle the MAC-address is again correct. This 
> brings a great deal of pain since the NIC is assigned a random MAC-address 
> when it is detected as invalid.
>
> I cannot say if this issue appeared recently or if it's been in the kernel 
> for a while, as I've been using wireless until recently.
>
> I read somewhere on lkml that the mac is read from the device, then 
> reversed and finally written back to the device. Can it be that it is read 
> again on resume and reversed, and then again written to the device? This 
> would explain why it's ok every other resume cycle.

Uh, Use The Source, Luke?

But no, I think it's simply driver dainbreadness, not a matter of
complicated writing and reading back in reversed order.

drivers/net/forcedeth.c has a nice DEV_HAS_CORRECT_MACADDR flag which is
being enabled for certain cards (those which need this) and disabled for others.

The nv_probe() function then nicely obeys this flag by reversing the
address if needed, _however_ there's another function, nv_copy_mac_to_hw(),
which does _NOT_ obey it and simply copies the _raw_ netdev dev_addr
to the card register (NvRegMacAddrA etc.).

I don't know, this all looks a bit dirty to me, MAC reading/writing
should have been implemented in a more central way, then those people
wouldn't have confused heaven and hell with MAC address fiddling.

And yeah, this certainly looks like a bug that should be fixed ASAP,
unless my short analysis somehow happened to be wrong.
(I could probably fix it, but then the forcedeth people
most likely know better how they would like to see it implemented)

Thank you for your report!

Now the only thing remaining would be: is there a specific way to
contact forcedeth-related people? I didn't find anything within a short
search.

Andreas Mohr
--
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/