linux-kernel - Re: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number

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: <20181017144034.GB135013@sasha-vm>
Date:   Wed, 17 Oct 2018 10:40:34 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Haiyang Zhang <haiyangz@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <Alexander.Levin@...rosoft.com>
Subject: Re: [PATCH 4.18 101/135] hv_netvsc: pair VF based on serial number

On Wed, Oct 17, 2018 at 04:26:21PM +0200, Greg Kroah-Hartman wrote:
>On Wed, Oct 17, 2018 at 02:15:30PM +0000, Haiyang Zhang wrote:
>> The VF NIC needs to be paired with synthetic NIC on HyperV  --  to do that we
>> use MAC address matching before the patch #A. But a non VF NIC can also
>> have the same MAC, which shouldn't be paired with synthetic NIC. So a better
>> method is implemented by #A to use VF serial number for matching.
>>
>> But, #A has a bug, which causes matching to fail. Patch #B fixed it by extracting
>> the VF serial number correctly from slot info.
>
>My question is, "what bug is patch #A fixing"?  Somehow things have been
>working just fine for people without this, right?  Remember, new
>features should not be backported to stable kernels if at all possible.

The current mechanism works fine most of the time, the problem is that
once in a while we'd see collisions between the synthetic device MAC
address and a different network device such as a bond device or just a
regular non-VF network device.

So while in most cases assuming that MAC is unique and looking up
devices based on it works, there's no guarantee that it's unique so
this assumption isn't true and things break.

This is why it (usually) works now, but still has a bug that needs
fixing.

If that makes sense, I'll requeue it when the fixes have soaked upstream
for a few weeks.

--
Thanks,
Sasha