linux-kernel - Re: [RFC 0/5] hid: Extending the device-driver matching mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120403105554.GA14201@polaris.bitmath.org>
Date:	Tue, 3 Apr 2012 12:55:54 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Benjamin Tissoires <benjamin.tissoires@...il.com>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Stephane Chatty <chatty@...c.fr>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/5] hid: Extending the device-driver matching mechanism

Hi Benjamin,

> So, I made a few tests yesterday, and I have now a clearer idea about
> this solution:
> 
> generally, I like it. Furthermore, it should help us build new classes
> of devices without involving hid-core, which is great.
> However, I have a few minors concerns, and a major one.
> 
> The major one comes with patch 3: introducing the hid_parse function
> in usbhid is great but it interferes with report_fixup mechanism. That
> means that several drivers won't work with this solution.

Yes, as noted in the commit message, that part is a work in
progress. Going through all the drivers using report_fixup, the
majority only uses device information, some use a driver-specific
quirk which again boils down to a specific device. All drivers are
present in the special_driver list in hid-core.

The simplest solution is probably to defer parsing for drivers known
from the device list. Even better would be if there was a mechanism to
avoid that list altogether... considering the USB/BT device as
separate from the HID device, it might even make sense to split the
drivers that way. Most drivers would drive the HID devices,
kickstarted by the generic usbhid driver. Some drivers would need to
intervene on the USB/BT level instead, for instance by fixing up the
reports.

> Now the minors:
> - as mentioned, the patches do not apply on Jiri's tree, which means
> that we are missing the detection of the serial protocol (see comment
> in patch 4).

Ok, thanks. In a couple of weeks I should rebase the patches to 3.4,
and will deal with it then.

> - shouldn't we introduce the same behavior for bluetooth (hidp)
> devices -> to be able to separate the handling of the magicmouse for
> instance)?

Yes, although I have not looked into the details yet.

> - as the hid_parse function is already called, shouldn't we remove the
> calls in the other drivers?

Maybe, maybe not - it depends on if there will be a deferral
mechanism. Hopefully it will become clear as we go along.

Thanks!
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/