Restricting CDC-ACM devices

Restricting CDC-ACM devices

[Nate]

I would like to use the cdc-acm driver in the Linux kernel (2.6.22-rc1),
but restrict the access to only my VID/PID devices.  Is there an easy way
to do with without modifying cdc-acm.c?

In a past prototype I made a simple wrapper driver for usb serial by
adding my VID/PID numbers to the wrapper driver's id_table.  Then when
that usb driver was accessed on connection, the driver just pointed to the
usb_serial_* functions (probe, disconnect, etc).  I tried to do the same
with the cdc-acm driver, but the cdc-acm driver's probe function was
called before my driver's probe.  I noticed that the cdc-amc driver will
attach when it detects the two CDC-ACM interfaces, so I removed the
cdc-acm driver with "make menuconfig".  This didn't work because the
cdc-acm functions I was attempting to call from my driver do not exist.

Thanks for the help,
-Nate

Re: Restricting CDC-ACM devices

[Greg KH]

On Tue, Aug 21, 2007 at 05:03:54PM -0500, Nate wrote:
> I would like to use the cdc-acm driver in the Linux kernel (2.6.22-rc1),
> but restrict the access to only my VID/PID devices.  Is there an easy way
> to do with without modifying cdc-acm.c?

Why do you not want to modify the driver?

> In a past prototype I made a simple wrapper driver for usb serial by
> adding my VID/PID numbers to the wrapper driver's id_table.  Then when
> that usb driver was accessed on connection, the driver just pointed to the
> usb_serial_* functions (probe, disconnect, etc).  I tried to do the same
> with the cdc-acm driver, but the cdc-acm driver's probe function was
> called before my driver's probe.  I noticed that the cdc-amc driver will
> attach when it detects the two CDC-ACM interfaces, so I removed the
> cdc-acm driver with "make menuconfig".  This didn't work because the
> cdc-acm functions I was attempting to call from my driver do not exist.

You can disconnect the device from the driver from userspace for any
device you just don't want to have connected by using the sysfs
bind/unbind files.  That doesn't require any kernel changes at all.

Why do you want to do this, what are you expecting to achieve with such
a change?

thanks,

greg k-h

Re: Restricting CDC-ACM devices

[Nate]

> Why do you not want to modify the driver?

Modifying the cdc-acm driver is an alternative; however, I would like to
avoid that when I'm adding my vendor specific restrictions.  My hope is
that when patches are made to that file, I don't need to worry about
someone merging them over the my previous ones.  Is this a bad goal?


> You can disconnect the device from the driver from userspace for any
> device you just don't want to have connected by using the sysfs
> bind/unbind files.  That doesn't require any kernel changes at all.

I don't fully follow you here.  Are you saying that I can disconnect the
CDC-ACM driver from my USB device and allow my driver to get a call probe?


> Why do you want to do this, what are you expecting to achieve with such
> a change?

The main application accesses data from USB devices over the /dev/ttyACMx
files, so using the CDC-ACM driver makes it easy for me to get the USB
device data.  There will be multiple USB devices that will be
communicating using CDC-ACM protocol, and I would like to restrict access
to only devices with the correct product IDs.  I was thinking if my driver
checked the VID/PID before allowing the CDC-ACM driver to process the
probe call, then I can restrict the devices.  The approved devices would
then be connected to ttyACMx by the standard cdc-acm driver code.

I'm still pretty green with regards to USB driver development, so there
might be a better way to achieve this.  If there is please tell me. :)

Thanks,
-Nate

Re: Restricting CDC-ACM devices

[Greg KH]

On Wed, Aug 22, 2007 at 09:41:33AM -0500, Nate wrote:
> 
> > Why do you not want to modify the driver?
> 
> Modifying the cdc-acm driver is an alternative; however, I would like to
> avoid that when I'm adding my vendor specific restrictions.  My hope is
> that when patches are made to that file, I don't need to worry about
> someone merging them over the my previous ones.  Is this a bad goal?

Well, just messing with the device ids is not that tough of a patch to
keep up to date over time, so you might just try that if necessary.

> > You can disconnect the device from the driver from userspace for any
> > device you just don't want to have connected by using the sysfs
> > bind/unbind files.  That doesn't require any kernel changes at all.
> 
> I don't fully follow you here.  Are you saying that I can disconnect the
> CDC-ACM driver from my USB device and allow my driver to get a call probe?

Yes.  You can manually bind and unbind all PCI and USB devices from
their drivers from userspace.  So you do have full control over this
already, no kernel changes needed.

thanks,

greg k-h

Re: Restricting CDC-ACM devices

[Nate]

Thank you for your responses.  Please don't take my repeated questioning
of your answers as me being difficult, I'm just trying to get a better
understanding.


> Well, just messing with the device ids is not that tough of a patch to
> keep up to date over time, so you might just try that if necessary.

That is a good point.  I may also be adding some extra logic to check
other fields to confirm compatibility before allowing a usb device to be
bound to the CDC-ACM driver.  That is still probably pretty small piece of
code in the probe function, but I'm just concerned that over time more
logic would be added and other developers will be maintaining the code.


> Yes.  You can manually bind and unbind all PCI and USB devices from
> their drivers from userspace.  So you do have full control over this
> already, no kernel changes needed.

Does this require my userspace applications to poll the USB devices
(/proc/bus/usb/devices) and then disconnect/connect my driver every time a
USB device using CDC-ACM is connected?  Is this what is normally done? 
Does this cause a noticeable performance hit when the driver is cycled
like this?  If I don't enable CDC-ACM in make menuconfig, can I still bind
it to a USB device from userspace?


I don't know if this matters, but I wanted to add some use case details:
This driver will be running on a <200 MHz processor and there can be a
number of connects/disconnect of the device in a short time from the
users.

Thanks,
-Nate

Re: Restricting CDC-ACM devices

[Greg KH]

On Wed, Aug 22, 2007 at 04:52:06PM -0500, Nate wrote:
> Thank you for your responses.  Please don't take my repeated questioning
> of your answers as me being difficult, I'm just trying to get a better
> understanding.
> 
> 
> > Well, just messing with the device ids is not that tough of a patch to
> > keep up to date over time, so you might just try that if necessary.
> 
> That is a good point.  I may also be adding some extra logic to check
> other fields to confirm compatibility before allowing a usb device to be
> bound to the CDC-ACM driver.  That is still probably pretty small piece of
> code in the probe function, but I'm just concerned that over time more
> logic would be added and other developers will be maintaining the code.

Well, this is of course the easiest way to achive what you are wanting
to do.  Only you can answer the "how I'm going to maintain this in the
future" question :)

> > Yes.  You can manually bind and unbind all PCI and USB devices from
> > their drivers from userspace.  So you do have full control over this
> > already, no kernel changes needed.
> 
> Does this require my userspace applications to poll the USB devices
> (/proc/bus/usb/devices) and then disconnect/connect my driver every time a
> USB device using CDC-ACM is connected?  Is this what is normally done? 
> Does this cause a noticeable performance hit when the driver is cycled
> like this?  If I don't enable CDC-ACM in make menuconfig, can I still bind
> it to a USB device from userspace?

No, you still need the driver to be around :)

Anyway, you can get a notification from udev whenever a device is bound
to the cdc-acm driver, and then trigger your "disconnect/connect" script
on that.

> I don't know if this matters, but I wanted to add some use case details:
> This driver will be running on a <200 MHz processor and there can be a
> number of connects/disconnect of the device in a short time from the
> users.

I don't know how fast the above will all work out, you are going to have
to test it yourself, sorry.

hope this helps,

greg k-h

Re: Restricting CDC-ACM devices

[Nate]

>
> I don't know how fast the above will all work out, you are going to have
> to test it yourself, sorry.
>
> hope this helps,

It has.  Thank you for answering all of my questions.

-Nate