From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 810BAC432C3 for ; Sat, 16 Nov 2019 08:48:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 540CB20730 for ; Sat, 16 Nov 2019 08:48:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573894139; bh=z5gwqn5EIYEk88tBrqlLKlVtlV83KIQstGhFdBihtQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=LTfIK4IcGhDB0kLrvU0EATDA4AkoJmK7/tw1WD0gCjW9gfL0UzNmPFMSp+G8WKHqP l72oh5k12GsOSYNnBewJBzUQn5Ag97XAGH+ofIOk5HfW3wCwWmUpPQdSae2y5/dwuK k+yE5nEEZRao4NTMDK1UFEQo1QyVDl+yHZl3RCJ8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727331AbfKPIs6 (ORCPT ); Sat, 16 Nov 2019 03:48:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:57014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726166AbfKPIs6 (ORCPT ); Sat, 16 Nov 2019 03:48:58 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0F38E20723; Sat, 16 Nov 2019 08:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573894137; bh=z5gwqn5EIYEk88tBrqlLKlVtlV83KIQstGhFdBihtQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GT4iVHhQuhYTPIXnTkE2QvmTJ3OLoZ4gPWb50cnIGIiz9fe6rmXCKoOHGTym/10dA EC7U9l5JE24wSl1k72l8QKNVYNldyYwIyxYxcL8cEnxVWf9UvEx/YuubMKQ3XGr8JA oLFzBBlTPtpGZuQ90I1Nh3olAnpzQdYG6jTXi6/w= Date: Sat, 16 Nov 2019 16:48:54 +0800 From: Greg Kroah-Hartman To: Andrey Konovalov Cc: Alan Stern , USB list , Dmitry Vyukov Subject: Re: Exporting USB device ids from the kernel Message-ID: <20191116084854.GA384892@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Fri, Nov 15, 2019 at 05:10:26PM +0100, Andrey Konovalov wrote: > On Fri, Nov 15, 2019 at 4:44 PM Alan Stern 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