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:	Thu, 25 Feb 2016 09:15:39 -0800
From:	Michael Chan <michael.chan@...adcom.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 01/10] bnxt_en: Improve bnxt_vf_update_mac().

On Thu, Feb 25, 2016 at 9:09 AM, David Miller <davem@...emloft.net> wrote:
> From: Michael Chan <michael.chan@...adcom.com>
> Date: Thu, 25 Feb 2016 08:57:01 -0800
>
>> We are not registering an invalid MAC address.  We are just storing it in the
>> driver's VF data structure.  There are 2 cases:
>>
>> 1. VF comes up and the MAC address from firmware is 0.  The VF will
>> generate random MAC.  The stored MAC address in the VF datastructure is
>> 0 so that ip set link eth0 address is allowed on the VF.
>
> Who looks at this 0 MAC address in the "VF datastructure", the driver?

the VF driver.

>
> Why does there need to be a 0 MAC address there to allow
> ->ndo_set_mac_address() to succeed on the VF at all?

0 means that the PF has not set it.  If the PF had set it, the datastructure
would contain the MAC address set by the PF.  The idea is that if the
PF has administered a MAC address, we won't allow the VF to change
it using ndo.

>
> This MAC address management between VFs and PFs looks unnecessarily
> convoluted and complicated.  I'd hate to have to actually be a user
> configuring this stuff.
>

I agree it is complicated.  The default, if nobody does anything, is random
MAC.  But random MAC has disadvantages, so we allow some options
for the PF or VF users to change it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ