netdev - Re: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign

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:	Wed, 9 Jan 2013 13:37:45 -0800
From:	Greg Rose <gregory.v.rose@...el.com>
To:	"Williams, Mitch A" <mitch.a.williams@...el.com>
CC:	Stefan Assmann <sassmann@...nic.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: [E1000-devel] [PATCH net-next] igbvf: fix setting
 addr_assign_type if PF is up

On Wed, 9 Jan 2013 18:56:36 +0000
"Williams, Mitch A" <mitch.a.williams@...el.com> wrote:

> > >> When the PF is up and igbvf is loaded the MAC address is not
> > >> generated using eth_hw_addr_random(). This results in
> > >> addr_assign_type not to be set.
> > >> Make sure it gets set.
> > >>
> > >
> > > NAK - In this case, the address may or may not be random. The
> > > user may have (and should have!) explicitly set this address from
> > > the host to ensure that the VF device receives the same address
> > > each time it
> > boots.
> > 
> > Maybe you can give me some advice on this then. Why is there
> > different behaviour depending on the PF being up or down? The
> > problem I'm facing is that if the user did not set a MAC address
> > for the VF manually and the PF is up during igbvf_probe it will not
> > be labelled as random although it is.
> > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > NET_ADDR_RANDOM if the flag is cleared?
> > 
> 
> The difference in behavior is because we cannot get any MAC address
> at all if the PF is down. The interface won't operate at all in this
> case, but if the PF comes up sometime later, we can start working.
> The other alternative is to leave the MAC address as all zeros and
> forcing the user to assign an address manually. We chose to use a
> random address to at least give it a chance of working once the PF
> woke up.

Having been around at the inception of SR-IOV in Linux I recall that
the primary reason we used a random ethernet address was so
that the VF could at least work because there was no infrastructure
to allow the host administrator to set the MAC address of the VF.  This
hobbled testing and validation because the user would have to go to
each VM and use a command local to the VM to set the VF MAC address to
some LAA via ifconfig or ip.  When testing large numbers of VFs this was
a definite pain.

Now that has changed and I wonder if maybe we shouldn't back out the
random ethernet address assignment and go ahead with all zeros, leaving
the device non-functional until the user has intentionally set either
an LAA through the VF itself, or an administratively assigned MAC
through the ip tool via the PF.

Use of the random MAC address is not recommended by Intel's own best
known methods literature, it was used mostly so that we could get the
technology working and it should probably be at least considered for
deprecation or out right elimination.

My two cents...

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