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:
 <PH7PR21MB3263EBCF9600EEBD6D962B6ECEAEA@PH7PR21MB3263.namprd21.prod.outlook.com>
Date: Fri, 10 Nov 2023 00:43:55 +0000
From: Long Li <longli@...rosoft.com>
To: Jakub Kicinski <kuba@...nel.org>, "longli@...uxonhyperv.com"
	<longli@...uxonhyperv.com>
CC: 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

> Subject: Re: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing it
> to user-mode
> 
> On Wed,  8 Nov 2023 14:56:52 -0800 longli@...uxonhyperv.com wrote:
> > From: Long Li <longli@...rosoft.com>
> >
> > When a VF is being exposed form the kernel, it should be marked as "slave"
> > before exposing to the user-mode. The VF is not usable without netvsc
> > running as master. The user-mode should never see a VF without the "slave"
> flag.
> >
> > An example of a user-mode program depending on this flag is cloud-init
> > (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fcanonical%2Fcloud-
> init%2Fblob%2F19.3%2Fcloudinit%2Fnet%2F__i
> >
> nit__.py&data=05%7C01%7Clongli%40microsoft.com%7C5fd05bce17d2471c74c
> 00
> >
> 8dbe0c9728b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63835092
> 80435
> >
> 56592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJB
> >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zAL2hc8338ci8Tl5
> ktZjk
> > mWZKCKWMqa%2BGlsE7Ty9g00%3D&reserved=0)
> 
> Quick grep for "flags", "priv" and "slave" doesn't show anything.
> Can you point me to the line of code?

I'm sorry, The URL I put in the commit should be: (I didn't realize the change has not been merged, here is the buggy code)
https://github.com/canonical/cloud-init/blob/3f515387142007fe0992a45486a1e049198a82f2/cloudinit/net/__init__.py#L1094

The code above needs to work with and without netvsc (the possible master device) present. It doesn't work properly with both conditions as of today. The patch series (with Haiyang's patches) fix that.

Because the code is specific to HyperV, we know we could be handling a VF NIC that is possibly a slave device, so checking on "slave" flag is a reliable indication whether the VF should be handled.

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.

> 
> > When scanning interfaces, it checks on if this interface has a master
> > to decide if it should be configured. There are other user-mode
> > programs perform similar checks.
> >
> > This commit moves the code of setting the slave flag to the time
> > before VF is exposed to user-mode.
> 
> > Change since v3:
> > Change target to net-next.
> 
> You don't consider this a fix? It seems like a race condition.

I will work with Haiyang to get patch sent in a series.

Thanks,

Long

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ