netdev - Re: [PATCH] smsc95xx: Add module parameter to override MAC address

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:	Fri, 25 Jun 2010 09:43:30 +0100
From:	Steve.Glendinning@...c.com
To:	Sebastien Jan <s-jan@...com>
Cc:	Simon Horman <horms@...ge.net.au>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	davem@...emloft.net, Ian.Saturley@...c.com
Subject: Re: [PATCH] smsc95xx: Add module parameter to override MAC address

Hi Sebastien,

> > I'm confused as to why this is desirable when the mac address
> > can already be configured after module insertion via
> > smsc95xx_netdev_ops.eth_mac_addr().
> 
> For example for booting over NFS using a pre-defined MAC address, with 
> a minimal setup (no initrd). Or is there another way to force a MAC
> address for this use-case?

I can't see an existing way of specifying this as a kernel parameter
in Documentation/kernel-parameters.txt. netdev= doesn't have a mac
address parameter.

During development I initially had smsc95xx driver using this logic to
select a MAC address:

1. If net->dev_addr has already been set to a valid mac address (i.e. by
an administrator before bringing the device up) then use that address.

2. If the device is already currently set to a valid mac address then
use that address.  This could have been set by either the device's
EEPROM or by a previously running bootloader.

3. Generate a random mac address.

Unfortunately, this doesn't work so well as the usbnet framework sets
net->dev_addr to the USB node_id before calling our bind function, so
we usually matched at step 1 (and not with the desired outcome).  So
I removed step 1 because, as Simon mentioned, it's possible to change
the mac address after the device is brought up.

I can see you have a different use case, but I don't think this specific
driver is the place for this logic.  I'd rather see it added to either
the usbnet framework or (preferably) the netdev framework so *all*
ethernet drivers can do this the same way.  otherwise we could end up
with slight variations of this code in every single driver!

Steve
--
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