netdev - RE: [PATCH net-next v2 07/10] net/faraday: Read MAC address from chip

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:	Tue, 19 Jul 2016 10:50:44 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Gavin Shan' <gwshan@...ux.vnet.ibm.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
	"joel@....id.au" <joel@....id.au>,
	"gerlitz.or@...il.com" <gerlitz.or@...il.com>,
	"weixue@...stnetic.com" <weixue@...stnetic.com>,
	"yuvali@...lanox.com" <yuvali@...lanox.com>,
	"alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: RE: [PATCH net-next v2 07/10] net/faraday: Read MAC address from
 chip

From: Gavin Shan
> Sent: 15 July 2016 11:44
> The device is assigned with random MAC address. It isn't reasonable.
> An valid MAC address might have been provided by (uboot) firmware by
> device-tree or in chip. It's reasonable to use it to maintain consistency.
> 
> This uses the MAC address from device-tree or that in the chip if it's
> valid. Otherwise, a random MAC address is given as before.
...
> +	m = ioread32(priv->base + FTGMAC100_OFFSET_MAC_MADR);
> +	l = ioread32(priv->base + FTGMAC100_OFFSET_MAC_LADR);
> +
> +	mac[0] = (m >> 8) & 0xff;
> +	mac[1] = m & 0xff;
> +	mac[2] = (l >> 24) & 0xff;
> +	mac[3] = (l >> 16) & 0xff;
> +	mac[4] = (l >> 8) & 0xff;
> +	mac[5] = l & 0xff;
> +
> +	if (!is_valid_ether_addr(mac)) {
> +		mac[5] = (m >> 8) & 0xff;
> +		mac[4] = m & 0xff;
> +		mac[3] = (l >> 24) & 0xff;
> +		mac[2] = (l >> 16) & 0xff;
> +		mac[1] = (l >>  8) & 0xff;
> +		mac[0] = l & 0xff;
> +	}
...

That is horrid, not all byte reversed addresses will be invalid.

	David