linux-kernel - RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks to process hvsock connection

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: <SN1PR0301MB1662D4C6D4EA3F82FAA4C4C7A0740@SN1PR0301MB1662.namprd03.prod.outlook.com>
Date:	Thu, 6 Aug 2015 18:28:18 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Dexuan Cui <decui@...rosoft.com>,
	David Miller <davem@...emloft.net>
CC:	"olaf@...fle.de" <olaf@...fle.de>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"stefanha@...hat.com" <stefanha@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"pebolle@...cali.nl" <pebolle@...cali.nl>,
	"dan.carpenter@...cle.com" <dan.carpenter@...cle.com>
Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks
 to process hvsock connection



> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, August 5, 2015 9:54 PM
> To: David Miller <davem@...emloft.net>; KY Srinivasan
> <kys@...rosoft.com>
> Cc: olaf@...fle.de; gregkh@...uxfoundation.org; jasowang@...hat.com;
> driverdev-devel@...uxdriverproject.org; linux-kernel@...r.kernel.org;
> stephen@...workplumber.org; stefanha@...hat.com;
> netdev@...r.kernel.org; apw@...onical.com; pebolle@...cali.nl;
> dan.carpenter@...cle.com
> Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks
> to process hvsock connection
> 
> > From: devel [mailto:driverdev-devel-bounces@...uxdriverproject.org] On
> Behalf
> > Of Dexuan Cui
> > Sent: Thursday, July 30, 2015 18:20
> > To: David Miller <davem@...emloft.net>; KY Srinivasan
> <kys@...rosoft.com>
> > Cc: olaf@...fle.de; gregkh@...uxfoundation.org; jasowang@...hat.com;
> > driverdev-devel@...uxdriverproject.org; linux-kernel@...r.kernel.org;
> > stephen@...workplumber.org; stefanha@...hat.com;
> netdev@...r.kernel.org;
> > apw@...onical.com; pebolle@...cali.nl; dan.carpenter@...cle.com
> > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register
> callbacks to
> > process hvsock connection
> >
> > > From: David Miller
> > > Sent: Thursday, July 30, 2015 6:27
> > >
> > > From: Dexuan Cui
> > > Date: Tue, 28 Jul 2015 05:35:11 -0700
> > >
> > > > With the 2 APIs supplied by the VMBus driver, the coming net/hvsock
> driver
> > > > can register 2 callbacks and can know when a new hvsock connection is
> > > > offered by the host, and when a hvsock connection is being closed by
> the
> > > > host.
> > > >
> > > This is an extremely terrible interface.
> > >
> > > It's an opaque hook that allows on registry, and it's solve purpose
> > > is to allow a backdoor call into a foreign driver in another module.
> > >
> > > These are exactly the things we try to avoid.
> >
> > Hi David,
> > Thanks a lot for your reviewing and the suggestion!
> >
> > > Why not create a real abstraction where clients register an object,
> > > that can be contained as a sub-member inside of their own driver
> > > private, that provides the callback registry mechanism.
> 
> Hi David,
> Can you please have a look at my below questions?
> 
> I like your idea of a real abstraction. Your answer would definitely
> help me to implement that correctly.
> 
> > Please pardon me for my inexperience.
> > Can you please be a bit more specific?
> > I guess maybe you're referencing a common design pattern in the driver
> > code, so an example in some existing driver would be the best. :-)
> >
> > "clients register an object " --
> > does the "clients" mean the hvsock driver?
> > and the "object" means the 2 callbacks?
> >
> > IMHO, here the vmbus driver has to synchronously pass the 2 events
> > to the hvsock driver, so a "backdoor call into the hvsock driver" is
> > inevitable anyway?
> >
> > e.g., in the path vmbus_process_offer() -> hvsock_process_offer(), the
> > return value of the latter is important to the former, because on error
> > the former needs to clean up some internal states of the vmbus driver
> (that
> > is, the "goto err_deq_chan").
> >
> >
> > > That way you can register multiple clients, do things like allow
> > > AF_PACKET capturing of vmbus traffic, etc.
> >
> > I thought AF_PACKET can only capture IP packetsor Ethernet frames.
> > Can it be used to capture AF_UNIX packet?
> > If yes, I suppose we can consider making it work for AF_HYPERV too,
> > if people ask for that.
> >

Dexuan,

The notion of a channel on Hyper-V has been mapped to a device on Linux and the mechanism we have
had of notifying the driver of the creation of the channel was through registering this device with the kernel
(vmbus_device_create). The first exception to this was when we introduced multi-channel support that broke
the assumption of this one to one mapping between the channel and Linux device. In the case of the sub-channels,
we handled the  driver notification issue via the sub-channel callback that the driver registers at the point of 
opening the channel. Perhaps we could make the sub-channel handling mechanism more generic to handle the case
of VMSOCK as well?

Regards,

K. Y
> > -- Dexuan
> 
> Thanks,
> -- Dexuan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/