Thanks for your links.
I checked the latest driver code 5.3.3.5, it handle the VF MAC address change request the same as the driver 2.0.2:
if the VF's MAC address has been set by the PF from HOST, will not allow VM to set it again.
The related code in igb_main.c:
6852 case E1000_VF_SET_MAC_ADDR:
6853 retval = -EINVAL;
6854 #ifndef IGB_DISABLE_VF_MAC_SET
6855 if (!(vf_data->flags & IGB_VF_FLAG_PF_SET_MAC))
6856 retval = igb_set_vf_mac_addr(adapter, msgbuf, vf);
6857 else
6858 DPRINTK(DRV, INFO,
6859 "VF %d attempted to override administratively set MAC address\nReload the VF driver to resume operations\n",
6860 vf);
6861 #endif
6862 break;
Also I checked the ixgb driver code, also do the same thing for the change VF MAC address request:
if (adapter->vfinfo[vf].pf_set_mac &&
!ether_addr_equal(adapter->vfinfo[vf].vf_mac_addresses, new_mac)) {
e_warn(drv,
"VF %d attempted to override administratively set MAC address\n"
"Reload the VF driver to resume operations\n",
vf);
return -1;
}
I've tried to modify the code to delete the check, allow change the VF's MAC address, and after load the new driver module,
all bonding modes work fine.
But as Patrick said, allow VM to modify the VF's MAC address, is a security issue.
Do you know whether there any other potential issue except mac spoofing?