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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090414012548.GB11615@xw6200.broadcom.net>
Date:	Mon, 13 Apr 2009 18:25:48 -0700
From:	"Matt Carlson" <mcarlson@...adcom.com>
To:	"James Bottomley" <James.Bottomley@...senPartnership.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>,
	"Matthew Carlson" <mcarlson@...adcom.com>
Subject: Re: [PATCH] tg3: fix big endian MAC address collection failure

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.

> 0x00000004      0x00
> 0x00000005      0x00
> 0x00000006      0x00
> 0x00000007      0x08
> 0x00000008      0x29
> 0x00000009      0x02
> 0x0000000a      0x00
> 0x0000000b      0x00
> 0x0000000c      0x00
> 0x0000000d      0x02
> 0x0000000e      0x00
> 0x0000000f      0x00
> 0x00000010      0xc5
> 0x00000011      0x3c
> 0x00000012      0x82
> 0x00000013      0x9b
> 0x00000014      0x00
> 0x00000015      0x00
> 0x00000016      0x00
> 0x00000017      0x00
> 0x00000018      0x00
> 0x00000019      0x00
> 0x0000001a      0x00
> 0x0000001b      0x00
> 0x0000001c      0x00
> 0x0000001d      0x00
> 0x0000001e      0x00
> 0x0000001f      0x00
> 0x00000020      0x00
> 0x00000021      0x00
> 0x00000022      0x00
> 0x00000023      0x00
> 0x00000024      0x00
> 0x00000025      0x00
> 0x00000026      0x00
> 0x00000027      0x00
> 0x00000028      0x00
> 0x00000029      0x00
> 0x0000002a      0x00
> 0x0000002b      0x00
> 0x0000002c      0x00
> 0x0000002d      0x00
> 0x0000002e      0x00
> 0x0000002f      0x00
> 0x00000030      0x00
> 0x00000031      0x00
> 0x00000032      0x00
> 0x00000033      0x00
> 0x00000034      0x00
> 0x00000035      0x00
> 0x00000036      0x00
> 0x00000037      0x00
> 0x00000038      0x00
> 0x00000039      0x00
> 0x0000003a      0x00
> 0x0000003b      0x00
> 0x0000003c      0x00
> 0x0000003d      0x00
> 0x0000003e      0x00
> 0x0000003f      0x00
> 0x00000040      0x00
> 0x00000041      0x00
> 0x00000042      0x00
> 0x00000043      0x00
> 0x00000044      0x00
> 0x00000045      0x00
> 0x00000046      0x00
> 0x00000047      0x00
> 0x00000048      0x00
> 0x00000049      0x00
> 0x0000004a      0x00
> 0x0000004b      0x00
> 0x0000004c      0x00
> 0x0000004d      0x00
> 0x0000004e      0x00
> 0x0000004f      0x00
> 0x00000050      0x00
> 0x00000051      0x00
> 0x00000052      0x00
> 0x00000053      0x00
> 0x00000054      0x00
> 0x00000055      0x00
> 0x00000056      0x00
> 0x00000057      0x00
> 0x00000058      0x00
> 0x00000059      0x00
> 0x0000005a      0x00
> 0x0000005b      0x00
> 0x0000005c      0x00
> 0x0000005d      0x00
> 0x0000005e      0x00
> 0x0000005f      0x00
> 0x00000060      0x00
> 0x00000061      0x00
> 0x00000062      0x00
> 0x00000063      0x00
> 0x00000064      0x00
> 0x00000065      0x00
> 0x00000066      0x00
> 0x00000067      0x00
> 0x00000068      0x00
> 0x00000069      0x00
> 0x0000006a      0x00
> 0x0000006b      0x00
> 0x0000006c      0x00
> 0x0000006d      0x00
> 0x0000006e      0x00
> 0x0000006f      0x00
> 0x00000070      0x00
> 0x00000071      0x00
> 0x00000072      0x00
> 0x00000073      0x00
> 0x00000074      0x8c
> 0x00000075      0x00
> 0x00000076      0x00
> 0x00000077      0x43
> 0x00000078      0x10
> 0x00000079      0x61
> 0x0000007a      0x20
> 0x0000007b      0x00
> 0x0000007c      0x30
> 0x0000007d      0x00
> 0x0000007e      0x00
> 0x0000007f      0x00
> 0x00000080      0x59
> 0x00000081      0x15
> 0x00000082      0x4b
> 0x00000083      0x6e

Yes.  And your MAC address in NVRAM is 00:00:59:15:4b:6e.  And again, HP
MAC addresses start with 00:30:6e, so the data is byteswapped in NVRAM.
(00:00:59 MAC addresses belong to "hellige gmbh").

> 0x00000084      0x39
> 0x00000085      0x4d
> 0x00000086      0x43
> 0x00000087      0x42
> 0x00000088      0x30
> 0x00000089      0x30
> 0x0000008a      0x37
> 0x0000008b      0x35
> 0x0000008c      0x00
> 0x0000008d      0x00
> 0x0000008e      0x36
> 0x0000008f      0x41
> 
> 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