linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	USB list <linux-usb@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Exporting USB device ids from the kernel
Date: Sat, 16 Nov 2019 16:48:54 +0800	[thread overview]
Message-ID: <20191116084854.GA384892@kroah.com> (raw)
In-Reply-To: <CAAeHK+z6m8mXEH-L+W+8FxjasrMX6BGMEdTq_hgUYerp+_0kjA@mail.gmail.com>

On Fri, Nov 15, 2019 at 05:10:26PM +0100, Andrey Konovalov wrote:
> On Fri, Nov 15, 2019 at 4:44 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Fri, 15 Nov 2019, Andrey Konovalov wrote:
> >
> > > Hi Greg and Alan,
> > >
> > > For USB fuzzing it would be nice to be able to export usb_device_id
> > > structs from the kernel to facilitate the fuzzer with generating USB
> > > descriptors that match to actual drivers. The same is required for
> > > hid_device_id structs, since those are matched separately by the
> > > usbhid driver (are there other cases like this?).
> > >
> > > Currently I have a hacky patch [1] that walks all drivers for USB and
> > > HID buses and then prints all device ids for those drivers into the
> > > kernel log. Those are manually parsed and built into the fuzzer [2]
> > > and then used to generate USB descriptors [3].
> >
> > There are so many different flags for those id structures, parsing and
> > understanding them must be quite difficult.
> >
> > > I'm thinking of making a proper patch that will add a debugfs entry
> > > like usb/drivers (and usb/hid_drivers?), that can be read to get
> > > USB/HID device ids for all loaded drivers. Would that be acceptable?
> > > Or should I use some other interface to do that?
> >
> > I can't think of a better way to get the information from a running
> > kernel.
> >
> > There is another possibility, though.  If the drivers are built as
> > modules, the information is already available to userspace tools via
> > depmod.  You could get it from the modules.dep.bin file.  This has the
> > advantage that it will work even for drivers that aren't currently
> > loaded.
> 
> This is the same thing Greg mentions above, right?

Yes.

> Would this work for drivers that are built into the kernel (as =y)?

No, sorry.  There has not been any need to export that information to
userspace as nothing has ever needed that.

The only reason we exported that at all was to allow modules to
auto-load to handle the device.

thanks,

greg k-h

  reply	other threads:[~2019-11-16  8:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15 14:25 Exporting USB device ids from the kernel Andrey Konovalov
2019-11-15 15:06 ` Greg Kroah-Hartman
2019-11-15 15:13   ` Andrey Konovalov
2019-11-15 15:30     ` Greg Kroah-Hartman
2019-11-15 15:44 ` Alan Stern
2019-11-15 16:10   ` Andrey Konovalov
2019-11-16  8:48     ` Greg Kroah-Hartman [this message]
2019-11-18 16:12       ` Andrey Konovalov
2019-11-18 16:39         ` Greg Kroah-Hartman
2019-11-18 17:42           ` Andrey Konovalov
2019-11-18 17:57             ` Greg Kroah-Hartman
2019-12-02 16:19               ` Andrey Konovalov
2019-12-02 16:49                 ` Greg Kroah-Hartman
2019-12-03 13:47                   ` Andrey Konovalov
2020-01-13 14:48               ` Andrey Konovalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191116084854.GA384892@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).