linux-kernel - RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

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: <DM5PR03MB249012322F220688723A1F1AA09C0@DM5PR03MB2490.namprd03.prod.outlook.com>
Date:   Fri, 16 Dec 2016 18:39:42 +0000
From:   KY Srinivasan <kys@...rosoft.com>
To:     Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Greg KH <gregkh@...uxfoundation.org>
CC:     "olaf@...fle.de" <olaf@...fle.de>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bjorn.helgaas@...il.com" <bjorn.helgaas@...il.com>,
        "apw@...onical.com" <apw@...onical.com>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
        "leann.ogasawara@...onical.com" <leann.ogasawara@...onical.com>
Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial
 numbers



> -----Original Message-----
> From: Haiyang Zhang
> Sent: Friday, December 16, 2016 7:21 AM
> To: KY Srinivasan <kys@...rosoft.com>; Stephen Hemminger
> <stephen@...workplumber.org>; Greg KH <gregkh@...uxfoundation.org>
> Cc: olaf@...fle.de; jasowang@...hat.com; linux-kernel@...r.kernel.org;
> bjorn.helgaas@...il.com; apw@...onical.com;
> devel@...uxdriverproject.org; leann.ogasawara@...onical.com
> Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial
> numbers
> 
> 
> 
> > -----Original Message-----
> > From: KY Srinivasan
> > Sent: Thursday, December 15, 2016 8:11 PM
> > To: Stephen Hemminger <stephen@...workplumber.org>; Greg KH
> > <gregkh@...uxfoundation.org>
> > Cc: olaf@...fle.de; jasowang@...hat.com; linux-kernel@...r.kernel.org;
> > bjorn.helgaas@...il.com; apw@...onical.com;
> devel@...uxdriverproject.org;
> > leann.ogasawara@...onical.com; Haiyang Zhang
> <haiyangz@...rosoft.com>
> > Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > serial numbers
> >
> >
> >
> > > -----Original Message-----
> > > From: devel [mailto:driverdev-devel-bounces@...uxdriverproject.org]
> On
> > > Behalf Of Stephen Hemminger
> > > Sent: Wednesday, December 14, 2016 3:52 PM
> > > To: Greg KH <gregkh@...uxfoundation.org>
> > > Cc: olaf@...fle.de; jasowang@...hat.com; linux-
> kernel@...r.kernel.org;
> > > bjorn.helgaas@...il.com; apw@...onical.com;
> > > devel@...uxdriverproject.org; leann.ogasawara@...onical.com; Haiyang
> > > Zhang <haiyangz@...rosoft.com>
> > > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > serial
> > > numbers
> > >
> > > Normally, that would work but in this case we have one driver (netvsc)
> > > which is managing another driver which is unaware of Hyper-V or netvsc
> > > drivers existence.  The callback is happening in netvsc driver and it
> > > needs to say "hey I know that SR-IOV device, it is associated with my
> > > network device". This problem is how to know that N is associated with
> > > V? The V device has to be a network device, that is easy. But then it
> > > also has to be a PCI device, not to bad. But then the netvsc code
> > > is matching based on hyper-V only PCI bus metadata (the serial #).
> > >
> > > The Microsoft developers made the rational decision not to go
> > modifying
> > > all the possible SR-IOV network devices from Intel and Mellanox to add
> > > the functionality there. That would have been much worse.
> > >
> > > Maybe, rather than trying to do the management in the kernel it
> > > could have been done better in user space. Unfortunately, this would
> > > only move the problem.  The PCI-hyperv host driver could expose serial
> > > value through sysfs (with some pain). But the problem would be how
> > > to make a new API to  join the two V and N device.  Doing a private
> > > ioctl is worse than the notifier.
> >
> > All this has been discussed earlier in the thread. I think I have a
> > solution
> > to the problem:
> > The only PCI (non-VF) NIC that may be present in the VM is the emulated
> > NIC and
> > we know exactly the device ID and vendor ID of this NIC. Furthermore,
> > as a platform we are not going to be emulating additional NICs. So,
> > if the PCI NIC is not the emulated NIC, it must be a VF and we can
> > extract the
> > serial number.
> 
> How about direct pass-through NIC devices. Do they have vPCI serial
> number?
> And, the numbers should be different from VF NIC?

This may not have a valid serial number; but is still a descendent of vmbus.

K. Y  
> 
> Thanks,
> - Haiyang