netdev - Re: [PATCH net-next 01/10] bnxt_en: Improve bnxt_vf_update

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 12:09:21 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	michael.chan@...adcom.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 01/10] bnxt_en: Improve bnxt_vf_update_mac().

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?

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

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.