netdev - Re: Question regarding MAC address configuraton with VLAN devices

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: <5523FB49.9010107@redhat.com>
Date:	Tue, 07 Apr 2015 08:44:09 -0700
From:	Alexander Duyck <alexander.h.duyck@...hat.com>
To:	Manish Chopra <manish.chopra@...gic.com>,
	Patrick McHardy <kaber@...sh.net>
CC:	netdev <netdev@...r.kernel.org>,
	Yuval Mintz <Yuval.Mintz@...gic.com>
Subject: Re: Question regarding MAC address configuraton with VLAN devices


On 04/01/2015 12:15 PM, Manish Chopra wrote:
> Hello Patrick,
>
> I have a question regarding MAC address configuration of network devices specially
> when VLANs are configured on that. Can you please help to address?
>
> When user changes MAC address of a base network device [e.g., via ifconfig]
> why existing VLAN device on top of that would add it's previous MAC address to
> unicast list of base device instead of adapting the new MAC address
> in it's own net device?
>
> What we are trying to achieve here is that -
>
> For a VF, if Hypervisor/Administrator has forced a MAC [e.g., via iproute2] then as a part of
> "learning process [of the new hypervisor forced mac] done by VF driver", it will simply call
> "call_netdevice_notifiers(NETDEV_CHANGEADDR, dev)", which would notify the address change
> to VLAN interfaces configured on top of VF device and they will adapt the hypervisor forced MAC too.
> But that's not seems to be the behavior here, instead VLAN device on top of the VF device seems to be adding
> It's previous MAC address to unicast list of base VF device. This configuration will not take effect
> [since PF is blocking the VF's additional unicast MACs, if once a MAC has been forced to the VF], thus
> effectively the VLAN interface will never receive traffic with it's configured MAC.
>
>
> Regards,
> Manish

What you are proposing would likely require significant changes to more 
than just VLANs.  It would have an impact on all stacked devices since 
normally the assumption is that we push addresses down, not up.  That is 
why the vlan_sync_address is simply checking to see if its current 
address is supported before pushing the address down.

Maybe we should look into adding some sort of flag to indicate that the 
address table is locked, like a IFF_L2_ADDR_LOCKED in order to indicate 
that the device only supports one L2 address and cannot be changed.  
Then you could probably pass that up to higher levels to force things 
like the address change you want in VLAN, and things like MACVLAN would 
simply fail if that flag is set.

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