Re: [PATCH] staging: line6: fix use-after-free bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 03 June 2013 16:08:21 Greg Kroah-Hartman wrote:
> On Tue, Jun 04, 2013 at 12:49:36AM +0200, Markus Grabner wrote:
> > I'm currently re-investigating this, and I have been informed by users
> > that
> > some newer Line6 devices talk a device-specific protocol over USB which is
> > different from the MIDI standard and should therefore not be mapped to a
> > virtual MIDI device. This raises some additional questions:
> > 
> > *) The easiest way to deal with this would be to use libusb in user space
> > to exchange data with the device. However, as far as I understand, if the
> > device is being used as an ALSA sound card (i.e., the kernel driver has
> > claimed the USB interface to access isochronous endpoints), libusb can't
> > access interrupt endpoints of the same interface at the same time since
> > it can't claim the interface while it is claimed by the kernel. Is this
> > correct?
> 
> Yes, that is correct.
Thanks for the clarification!

> > *) If shared kernel/user space access to the same USB interface is not
> > possible as discussed above, what would be the preferred interface for
> > user
> > space applications to talk to the kernel driver? I think netlink is a good
> > candidate, or do you have any other suggestions?
> 
> What exactly do you need to communicate from user to kernel?  That is
> going to dictate what interface to use.
Line6 devices use USB interrupt messages for the following purposes:
*) device->host: when the user interacts with the device (e.g., turns the 
volume dial), the modified state is reported to the host by an asynchronous 
message (typically 2 to 16 bytes)
*) host->device: the state of the device can be changed by sending similar 
messages from host to device (e.g., a GUI application would do so when the 
user turns the volume dial on screen)
*) some device information can explicitly be queried by sending a message, to 
which the device responds with one or more messages (these can be much longer, 
e.g., the device's NVRAM content)

Moreover, some (few) information is exchanged via USB control messages. All 
messages are encoded in a device-dependent binary format, so far I am aware of 
~200 different message types.

All of this could be done by libusb, if there weren't the restriction that the 
user space can't claim the interface after the kernel has done so. Since the 
Line6 kernel driver has exclusive access to the USB interface, it must provide 
some additional "entry point" to route messages between user space code and 
the Line6 USB device.

With these requirements in mind, I did some search and found the page
"http://people.ee.ethz.ch/~arkeller/linux/kernel_user_space_howto.html";, from 
which I think netlink is best suited. What do you think?

	Kind regards,
		Markus

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux