linux-kernel - Re: [PATCH] HID: Sony: Add support for Gasia controllers

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]

Date:   Mon, 3 Feb 2020 11:02:19 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Roderick Colenbrander <thunderbird2k@...il.com>
cc:     Martyn Welch <martyn@...chs.me.uk>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-input <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Conn O'Griofa <connogriofa@...il.com>,
        "Colenbrander, Roelof" <roderick.colenbrander@...y.com>
Subject: Re: [PATCH] HID: Sony: Add support for Gasia controllers

On Tue, 28 Jan 2020, Roderick Colenbrander wrote:

> Let me explain the situation a little bit better from our angle. These 
> devices exist and from the Linux community perspective of course they 
> should see some level of support. And as I said since this is PS3 
> generation I don't have much of a concern.
> 
> Where it becomes tricky for any company in our situation is the support 
> side. We don't know these devices and don't have access to datasheets or 
> anything, but when such code is in our "official driver" it means we 
> have to involve them in our QA process and support them in some manner 
> (kind of legitimizing their existence as well). We now support this 
> driver in a large capacity (pretty much all mobile devices will start 
> shipping it) it puts challenges on our partners (not a big issue since 
> just PS3 right now).
> 
> As you can see this creates an awkward situation. I'm sure there other 
> such devices as well e.g. counterfeit Logitech keyboards, USB serial 
> adapters and other periperhals with similar challenges. In an ideal 
> world the support would live in another driver, but since in case of 
> this "fake" PS3 controller it "share" our product / vendor ids it is 
> tricky. At this point there is not a strong enough case yet to augment 
> the "hid-quirks" to do so, but perhaps if it became a serious issue 
> (e.g. for newer controllers) maybe we need to think of something.

If this is a big issue for you, one possible way around it would be 
creating a module parameter which would tell the driver whether it should 
those "fake" devices, and you can then turn it off in your products (or we 
can of course start the "what should the default setting me" bikeshedding 
:) ).

Thanks,

-- 
Jiri Kosina
SUSE Labs