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:	Mon, 14 Jan 2013 17:25:42 -0500
From:	Andy Gospodarek <andy@...yhouse.net>
To:	Greg Rose <gregory.v.rose@...el.com>
Cc:	"Williams, Mitch A" <mitch.a.williams@...el.com>,
	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, Jan 09, 2013 at 01:37:45PM -0800, Greg Rose wrote:
> 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.
> 

It would be great to remove the bits that created random MAC addresses
for VFs, but wouldn't that break Linus' rule to "not break userspace" if
it was removed?

There are 2 options that immediately come to mind when looking to
resolve this: 

1.  Use some of the left-over bits in the mailbox messages to pass along
a flag with the E1000_VF_RESET messages to indicate whether the MAC was
randomly generated.  This would be pretty easy, but there could be
compatibility issues for a while.

2.  Default to a MAC address of all zeros, and as a device with
all-zeros for a MAC is brought up, randomly create one with
eth_hw_addr_random.  This may not immediately help cases where device
assignment are a problem, but it would ensure that any device with a
random MAC as assigned by the kernel, would have NET_ADDR_RANDOM set in
addr_assign_type.

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