netdev - Re: [PATCH v2] igbvf: Regard vf reset nack as success

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] [day] [month] [year] [list]

Date:   Mon, 28 Nov 2022 14:07:47 -0800
From:   Tony Nguyen <anthony.l.nguyen@...el.com>
To:     Akihiko Odaki <akihiko.odaki@...nix.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>
CC:     <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <intel-wired-lan@...ts.osuosl.org>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Yan Vugenfirer <yan@...nix.com>,
        Yuri Benditovich <yuri.benditovich@...nix.com>
Subject: Re: [PATCH v2] igbvf: Regard vf reset nack as success

On 11/22/2022 5:04 PM, Akihiko Odaki wrote:
> Hi,
> 
> On 2022/11/23 1:22, Maciej Fijalkowski wrote:
>> On Wed, Nov 23, 2022 at 12:26:30AM +0900, Akihiko Odaki wrote:
>>> vf reset nack actually represents the reset operation itself is
>>> performed but no address is assigned. Therefore, e1000_reset_hw_vf
>>> should fill the "perm_addr" with the zero address and return success on
>>> such an occasion. This prevents its callers in netdev.c from saying PF
>>> still resetting, and instead allows them to correctly report that no
>>> address is assigned.
>>
>> What's the v1->v2 diff?
> 
> Sorry, I mistakenly added you to CC (and didn't tell you the context). 
> The diff is only in the message. For details, please look at:
> https://patchew.org/linux/20221122092707.30981-1-akihiko.odaki@daynix.com/#647a4053-bae0-6c06-3049-274d389c2bdd@daynix.com
> 
>> Probably route to net and add fixes tag?
> It is hard to determine the cause of the bug because it is about 
> undocumented ABI. Linux introduced E1000_VF_RESET | 
> E1000_VT_MSGTYPE_NACK response with commit 6ddbc4cf1f4d ("igb: Indicate 
> failure on vf reset for empty mac address") so one can say it is the 
> cause of the bug.
 >
> However, the PF may be driven by someone else Linux (Windows in 
> particular), and if such system have already had E1000_VF_RESET | 
> E1000_VT_MSGTYPE_NACK response defined, it can be said the bug existed 
> even before Linux changes how the PF responds to E1000_VF_RESET request.

As best as you can find is ok; the one you point to seems reasonable. We 
can only control this OS so we should point to the responsible patch 
within the kernel. It's better to go with a best-effort Fixes and get 
applied to some stable kernels then go without one and not (and would 
require later effort).

Thanks,
Tony