netdev - RE: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing it to user-mode

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]

Message-ID:
 <PH7PR21MB326308608D52C45BFE16B05BCEBBA@PH7PR21MB3263.namprd21.prod.outlook.com>
Date: Tue, 21 Nov 2023 00:23:40 +0000
From: Long Li <longli@...rosoft.com>
To: Jakub Kicinski <kuba@...nel.org>, stephen <stephen@...workplumber.org>
CC: "longli@...uxonhyperv.com" <longli@...uxonhyperv.com>, KY Srinivasan
	<kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu
	<wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
	<pabeni@...hat.com>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing
 it to user-mode

> On Wed, 15 Nov 2023 08:14:06 -0800 Stephen Hemminger wrote:
> > Jakub is right that in an ideal world, this could all be managed by
> > userspace. But the management of network devices in Linux is a
> > dumpster fire! Every distro invents there own solution, last time I
> > counted there were six different tools claiming to be the "one network
> > device manager to rule them all". And that doesn't include all the
> > custom scripts and vendor appliances.
> 
> To be clear, I thought Long Li was saying that the goal is work around cases where
> VF is probed before netvsc. That seems like something that can be prevented by
> the hypervisor.

Hi Jakub,

I think you misunderstood my response, here is the response again.

(quote)

The current workflow in the kernel looks like this:
1. VF net device is created and expose to user-mode 2. VF is bonded to NETVSC (if NETVSC exists on the system)

With the current kernel behavior, the user-mode can possibly see the VF after 1, and before 2 when VF is bonded. When this happens, the user-mode doesn't know if the VF will be bonded in the future (it may never happen on systems without NETVSC). In this case, it doesn't know if it should configure the VF or not.

(end quote)

The problem is not that VF could be probed before netvsc. The problem is that it's possible that VF is probed, exposed to user-mode earlier than netvsc has a chance to bond it.

Thanks,

Long