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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 13 Apr 2009 15:17:39 -0700
From:	"Michael Chan" <mchan@...adcom.com>
To:	"James Bottomley" <James.Bottomley@...senPartnership.com>
cc:	"David Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
	"Matthew Carlson" <mcarlson@...adcom.com>
Subject: Re: [PATCH] tg3: fix big endian MAC address collection failure


On Mon, 2009-04-13 at 14:42 -0700, James Bottomley wrote:

> ---
> On Mon, 2009-04-13 at 11:37 -0700, Matt Carlson wrote:
> > But that is exactly what the code is doing.  tg3_nvram_read_be32() will
> > return the data in bytestream format.  A memcpy() should be all that is
> > needed to transport the data to a different memory location.
> 
> But not the one you've done.  cpu_to_be32 is a nop pass through on our
> architecture, so tg3_nvram_read_be32 is equivalent to tg3_nvram_read on
> our architecture (i.e. identical to the code that was doing the read in
> 2.6.29).  However, the memcpy is the wrong way around for us.  If you
> look at an example, the original code said

The old tg3_nvram_read() had a swab32() after the readl().  The new
tg3_nvram_read() no longer has the swab32().  There were too many layers
of swapping in the old code and that's why Matt wanted to clean it up.

James, can do dump out the nvram content on the parisc?

ethtool -e eth0 length 0x90

Thanks.

> 
> dev_addr[0] = hi >> 16;
> dev_addr[1] = hi >> 24
> 
> So MSB-1 and MSB.  However, on a BE machine these are at offset one and
> zero from the start of the word.  The replacement memcopy is:
> 
> memcpy(&dev->dev_addr[0], ((char *)&hi) + 2, 2)
> 
> i.e. offset 3 and 4, which actually copies LSB-1 and LSB into there.
> You can follow similar logic to show that the lo copy is wrong too.
> 
> Perhaps the fix is just to put the tg3_nvram_read() back as well as the
> original by loads?
> ---
> 
> James
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists