netdev - Re: [PATCH] tg3: fix big endian MAC address collection failure

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]

Date:	Tue, 14 Apr 2009 03:51:25 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Matt Carlson <mcarlson@...adcom.com>
Cc:	Michael Chan <mchan@...adcom.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>
Subject: Re: [PATCH] tg3: fix big endian MAC address collection failure

On Mon, 2009-04-13 at 18:25 -0700, Matt Carlson wrote:
> On Mon, Apr 13, 2009 at 03:32:14PM -0700, James Bottomley wrote:
> > On Mon, 2009-04-13 at 15:17 -0700, Michael Chan wrote:
> > > 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.
> > 
> > Sure, ion's is
> > 
> > ion:~# ethtool -e eth0 length 0x90
> > Address         Data
> > ----------      ----
> > 0x00000000      0xaa
> > 0x00000001      0x55
> > 0x00000002      0x99
> > 0x00000003      0x66
> 
> Michael noticed that your NVRAM signature is byteswapped in NVRAM. (!)
> That also explains why the driver is trying to obtain the MAC address
> through NVRAM, rather than getting it from shared memory.  The device's
> bootcode is not working correctly.

Um, well, this is a parisc:  the device's boot code won't be working at
all (parisc doesn't have open firmware boot).  The values might be laid
down by the platform IODC, but usually for add in cards, they're the
default initialise values the card comes up with.

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