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]

Message-ID: <50EDCACA.9050803@kpanic.de>
Date:	Wed, 09 Jan 2013 20:53:46 +0100
From:	Stefan Assmann <sassmann@...nic.de>
To:	"Williams, Mitch A" <mitch.a.williams@...el.com>
CC:	"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 09.01.2013 19:56, Williams, Mitch A 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.
> 
> Currently, the PF has no way to communicate to the VF whether or not the
> MAC address is random or assigned. The VF cannot check the
> IGB_VF_FLAG_PF_SET_MAC flag because that only exists in the PF driver. To
> propagate this flag down to the VF driver would require changes to the
> PF/VF communication protocol.
> 
> In any case, I'm not sure that's the correct thing to do. From a policy
> viewpoint, we don't want the VF to know what's happening in the PF. It
> should not know how or why the MAC address was assigned, just like it
> should not know whether or not the PF has placed it on a VLAN. VF devices
> are not to be trusted and should not be given more information about the
> state of the PF and host OS than is absolutely necessary to operate.
> 
> What's your use case here, Stefan? Why is this flag important to you?
> As far as I can tell, nothing in the kernel ever looks at this flag.

It's about persistent device names.
You're right nothing in the kernel looks at the flag but udev uses it to
decide if the device should be identified by MAC address or PCI bus
topology.
If NET_ADDR_RANDOM is set udev will use the PCI bus information to
identify the device (instead of a changing MAC address, which would lead
to a new device name every reboot).

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