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]
Message-Id: <1239722789.3357.39.camel@mulgrave.int.hansenpartnership.com>
Date:	Tue, 14 Apr 2009 15:26:29 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Michael Chan <mchan@...adcom.com>
Cc:	Matthew Carlson <mcarlson@...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 21:11 -0700, Michael Chan wrote:
> James Bottomley wrote:
> 
> > 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:
> > > >
> > > > 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.
> >
> 
> Matt was referring to MIPS code that runs inside the MIPS core inside
> the TG3 chip.  The code is loaded from NVRAM and will start running
> after chip reset.  But I don't agree with Matt that the swapped NVRAM
> values were caused by bad MIPS code programmed in the NVRAM.

Um, yes, me too ... if the boot process doesn't involve the platform,
there's no reason the values would get swapped (unless we're accessing
them wrongly).

> I agree with DaveM that this appears to be a driver big-endian problem
> when reading the NVRAM.  Can you run the same ethtool -e on 2.6.29 to
> confirm?  Thanks.

Sure (just had to rebuild a 2.6.29 kernel):

ion:~# ethtool -e eth0 length 0x90
Address         Data
----------      ----
0x00000000      0x66
0x00000001      0x99
0x00000002      0x55
0x00000003      0xaa
0x00000004      0x08
0x00000005      0x00
0x00000006      0x00
0x00000007      0x00
0x00000008      0x00
0x00000009      0x00
0x0000000a      0x02
0x0000000b      0x29
0x0000000c      0x00
0x0000000d      0x00
0x0000000e      0x02
0x0000000f      0x00
0x00000010      0x9b
0x00000011      0x82
0x00000012      0x3c
0x00000013      0xc5
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      0x43
0x00000075      0x00
0x00000076      0x00
0x00000077      0x8c
0x00000078      0x00
0x00000079      0x20
0x0000007a      0x61
0x0000007b      0x10
0x0000007c      0x00
0x0000007d      0x00
0x0000007e      0x00
0x0000007f      0x30
0x00000080      0x6e
0x00000081      0x4b
0x00000082      0x15
0x00000083      0x59
0x00000084      0x42
0x00000085      0x43
0x00000086      0x4d
0x00000087      0x39
0x00000088      0x35
0x00000089      0x37
0x0000008a      0x30
0x0000008b      0x30
0x0000008c      0x41
0x0000008d      0x36
0x0000008e      0x00
0x0000008f      0x00

So that's byteswapped from the 2.6.30 output ... confirming your theory,
I think.

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