linux-kernel - Re: [PATCH] HID: get rid of HID_QUIRK_NO_INIT

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] [day] [month] [year] [list]

Date:   Mon, 6 Mar 2017 14:48:37 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        David Herrmann <dh.herrmann@...glemail.com>,
        Oliver Neukum <oneukum@...e.de>,
        Jason Gerecke <killertofu@...il.com>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH] HID: get rid of HID_QUIRK_NO_INIT_REPORTS

On Mar 06 2017 or thereabouts, Jiri Kosina wrote:
> On Thu, 5 Jan 2017, Benjamin Tissoires wrote:
> 
> > For case 1, the hiddev documentation provides an ioctl to do the
> > init manually. A solution could be to retrieve the requested report
> > when EVIOCGUSAGE is called, in the same way hidraw does. I would be
> > tempted to not change the behavior and hope that we won't break any
> > userspace tool.
> 
> I'd like to be applying the HID_QUIRK_NO_INIT_REPORTS removal as soon as 
> possible so that it gets exposure in linux-next over the whole development 
> cycle.
> 
> I am however too conservative to ignore the potential hiddev breakage, I 
> am afraid. This has a real potential of breaking systems, and 
> administrators having hard time figuring out of happened; essentialy, this 
> is userspace-visible behavior change (regression) for which we haven't 
> done any long-term depreciation (such as printing a warning "please talk 
> to your hiddev driver vendor" in case the driver seems to assume 
> initialized reports) at least for a few years.
> 
> I think that either doing it at a connect time, or during first 
> EVIOCGUSAGE ioctl() call is a must.

Yes, that's what I was thinking to do too. Also, I think we need to keep
around the list of currently "quirked" devices for hiddev to work
properly. I am still wondering whether we should simply keep the list of
quirked devices in hid-core, but disable the effects, or move the full
list of quirked devices in hiddev.

Initially I thought it was better to remove the quirk from core and move
the list in hiddev, but on the other hand, that means that we will
remove the ability to introduce it from the kernel boot command, so
maybe keeping the list in its current state is better, and only have the
effects in hiddev. Am I clear enough?)

> 
> Otherwise, I'd be super-happy to finally get rid of this giant PITA.
> 

Me too!

Cheers,
Benjamin

> Thanks!
> 
> -- 
> Jiri Kosina
> SUSE Labs
>