linux-kernel - The usage of hid_have_special_driver() in hid_add_device() of hid-core.c makes the usage of /dev/hidraw cumbersome from user space.

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

Date:   Sat, 24 Feb 2018 20:24:06 +0200
From:   Michael Menegakis <arxeio@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: The usage of hid_have_special_driver() in hid_add_device() of
 hid-core.c makes the usage of /dev/hidraw cumbersome from user space.

A recent patch of Wine allows to have proper access to raw HID for
bluetooth devices expressed at /dev/hidraw* and via libudev. This
generally opens the door to a wide array of windows software that
relies on raw HID access to be used on Linux.

However, the relevant code at hid_add_device() doesn't create a
/dev/hidraw at all if one wants to blacklist a kernel driver from
being loaded for that device! That renders userspace incapable to use
raw HID unless they recompile the kernel for each device.

Let me know if I miss something or if a recent patch I'm not aware of
alters that behavior. If not, I suggest to provide away to retain the
existence of /dev/hidraw# if a corresponding module is not loaded,
without requiring user space to recompile.

PS. In case that part wasn't clear: We can't use both a special driver
+ another user space driver access /dev/hidraw in several cases
because they may conflict. Therefore one has to recompile the kernel
currently in order to avoid conflicts.

PPS. I noticed the existence of ignore_special_drivers parm of hid
while I was finishing this message but that appears a catch-all. I
generally don't get why /dev/hidraw# isn't retained if a special
driver is unloaded (or not loaded) by default.