Feature request: Blacklist/Whitelist USB Devices from certain modules

Thomas Dettbarn <[email protected]>
Newsgroups gmane.os.openbsd.misc
Message-ID <[email protected]>
Hello!


The way I understand the uftdi module is that it checks the ID of any new
USB devices and attaches itself to it. When it does not know the ID, there
is the fallback ugen module.

Currently, I have a very specific problem, involving the uftdi(4) module
inside the kernel. For my project, I have two uftdi devices: Their IDs
are 0403:6001 and 0403:6010.

I had some issues, and, as it turns out, the :6001 device needs to be
attached by the uftdi(4) module, whereas the :6010 device is attached to
ugen(4).

To achieve this, I patched the kernel, removing the device from the
uftdi_devs[] inside uftdi.c. ThisWorksOnMyMachine(tm).


However, I would like to promote the use of said devices on OpenBSD. So
for users who come after me, I would like to request a feature, where
this automatic attachment can be overwritten slightly more easy. IN
OTHER WORDS: So that it is possible to attach ANY usb device as ugen(4),
in a way so that a user-space driver can take over.


I am thinking not only about uftdi, but also uaudio, urwtwn, uhidev, ubub
basically anything involving a USB device.


 From a user's perspective, I could think of three possibilities for an
implementation:

1. Some sort of /etc/usb_attachment.conf, with contents such as

      0403:6001  uftdi* allow
      0403:6010  uftdi* deny,ugen* allow

2. Using sysctl

      sysctl usb.move_to_ugen0 0403:6010

3. By making it configurable at compile time

      uftdi.option=no_0403:6010



Ideally, this could also act as a new safety feature, where a system can be
configured in a way that it only accepts known USB devices, and rejects the
ones it does not recognize.

What do you think?
Would that be something for the OpenBSD kernel, or would be require
way to much effort for the implementation?



Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.