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: <063D6719AE5E284EB5DD2968C1650D6D5F4FC97F@AcuExch.aculab.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ