HID vendor access from user space

HID vendor access from user space

[Nestor Lopez Casado]

Hi,

In today's linux HID subsystem, a HID device can be accessed for
control and configuration via dev/hidraw, via a hid-specific driver,
as well as /dev/input (setting leds on a kbd for instance)

Some HID devices share multiple functionality in the same HID
interface, think of a keyboard with a touchpad and a vendor specific
collection for configuration, special status, etc.

For such device, there will be one hidraw node, and hid-input will
take care of parsing the keyboard/mouse collections into the proper
input objects.

The vendor collection will be ignored.

If a user wants to configure/control the device there are two choices,
either write a hid-specific driver to deal with the vendor specific
collection, or open the corresponding /hidraw node from userspace.

But a hidraw node that carries system input data requires root priviledges.

I'm interested in hearing your opinions on how to add the capability
for a normal user process to control/configure a HID device via
reports exchanged with a vendor collection.

I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
for all top level HID collections which are today ignored by hid-input
and/or other subsystems.

These nodes would not require root priviledge by default and thus,
users could control/reconfigure their devices from a standard
application while keeping the "standard" input functionality intact.

Cheers,
Nestor

Re: HID vendor access from user space

[David Herrmann]

Hi

On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> Hi,
>
> In today's linux HID subsystem, a HID device can be accessed for
> control and configuration via dev/hidraw, via a hid-specific driver,
> as well as /dev/input (setting leds on a kbd for instance)
>
> Some HID devices share multiple functionality in the same HID
> interface, think of a keyboard with a touchpad and a vendor specific
> collection for configuration, special status, etc.
>
> For such device, there will be one hidraw node, and hid-input will
> take care of parsing the keyboard/mouse collections into the proper
> input objects.
>
> The vendor collection will be ignored.
>
> If a user wants to configure/control the device there are two choices,
> either write a hid-specific driver to deal with the vendor specific
> collection, or open the corresponding /hidraw node from userspace.
>
> But a hidraw node that carries system input data requires root priviledges.
>
> I'm interested in hearing your opinions on how to add the capability
> for a normal user process to control/configure a HID device via
> reports exchanged with a vendor collection.
>
> I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
> for all top level HID collections which are today ignored by hid-input
> and/or other subsystems.
>
> These nodes would not require root priviledge by default and thus,
> users could control/reconfigure their devices from a standard
> application while keeping the "standard" input functionality intact.

Why not write a kernel driver? We have a pretty nice infrastructure
for all this.

If it's a license-issue, I recommend using udev rules to change
permissions on the requested devices directly during setup. You can
then use hidraw.
It would also help if you could describe the driver design. Do you run
it as daemon and feed data back into the kernel? Or do you forward it
to the xserver? Or what kind of setup do you have? For instance, a
library design would require dynamic permission setup, while a
daemon-design would allow static file-system permissions.
Furthermore, is it still an input driver? Or do you tunnel non-input
data via HID?

Regards
David

Re: HID vendor access from user space

[Nestor Lopez Casado]

Hi, let me resuscitate this thread as we will have some resources to
work on this within a few weeks. I suggest re-reading the previous
emails  to refresh the context of this discussion.

On Tue, May 21, 2013 at 3:12 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Fri, May 17, 2013 at 1:47 PM, Nestor Lopez Casado
> <nlopezcasad@logitech.com> wrote:
>> Hi,
>>
>> In today's linux HID subsystem, a HID device can be accessed for
>> control and configuration via dev/hidraw, via a hid-specific driver,
>> as well as /dev/input (setting leds on a kbd for instance)
>>
>> Some HID devices share multiple functionality in the same HID
>> interface, think of a keyboard with a touchpad and a vendor specific
>> collection for configuration, special status, etc.
>>
>> For such device, there will be one hidraw node, and hid-input will
>> take care of parsing the keyboard/mouse collections into the proper
>> input objects.
>>
>> The vendor collection will be ignored.
>>
>> If a user wants to configure/control the device there are two choices,
>> either write a hid-specific driver to deal with the vendor specific
>> collection, or open the corresponding /hidraw node from userspace.
>>
>> But a hidraw node that carries system input data requires root priviledges.
>>
>> I'm interested in hearing your opinions on how to add the capability
>> for a normal user process to control/configure a HID device via
>> reports exchanged with a vendor collection.
>>
>> I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
>> for all top level HID collections which are today ignored by hid-input
>> and/or other subsystems.
>>
>> These nodes would not require root priviledge by default and thus,
>> users could control/reconfigure their devices from a standard
>> application while keeping the "standard" input functionality intact.
>
> Why not write a kernel driver? We have a pretty nice infrastructure
> for all this.
Do you mean a "hid-specific" driver for certain vid & pid devices ?

>
> If it's a license-issue, I recommend using udev rules to change
> permissions on the requested devices directly during setup. You can
> then use hidraw.
It is not a license issue, it is a security issue.

Every hid class interface, (either usb, bluetooth, i2c, etc) has an
associated hidraw node, and that node aggregates all reports sent from
the device.

Say that for example, the device has a keyboard collection and a
vendor collection, then changing permissions on the associated hidraw
node (so as to give any desktop user unrestricted access to the vendor
collection) would open the door to malicious code that could log the
keyboard activity (as both the vendor reports and input reports are
seen on the same hidraw node)

What we really want, is that vendor reports which come from hid vendor
collections not claimed by hid-input,  are made available in separate
device nodes.


> It would also help if you could describe the driver design. Do you run
> it as daemon and feed data back into the kernel? Or do you forward it
> to the xserver? Or what kind of setup do you have? For instance, a
> library design would require dynamic permission setup, while a
> daemon-design would allow static file-system permissions.
> Furthermore, is it still an input driver? Or do you tunnel non-input
> data via HID?

I see this proposal as an extension to hidraw.c.
The functionality offered would be similar to that proposed by hidraw,
but instead of providing access to all device reports, only those
tagged as being "vendor usage" would be exposed.

Let's take a concrete device example based on the following hid
interface descriptor:
0x05 , 0x01,                    // USAGE_PAGE (Generic Desktop)
0x09 , 0x06,                    // USAGE (Keyboard)
0xA1 , 0x01,                    // COLLECTION (Application)
0x85 , 0x01,                    //    REPORT_ID (1)
0x75 , 0x01,                    //    REPORT_SIZE (1)
0x95 , 0x08,                    //    REPORT_COUNT (8)
0x05 , 0x07,                    //    USAGE_PAGE (Keyboard)

[snip]

0x19 , 0x00,                    //    USAGE_MINIMUM (Reserved (no
event indicated))
0x29 , 0xFF,                    //    USAGE_MAXIMUM (Reserved (no
event indicated))
0x81 , 0x00,                    //    INPUT (Data,Ary,Abs)
0xC0,                           // END_COLLECTION
0x06, 0x00, 0xFF,               // Usage Page (Vendor Defined Page 1)
0x09, 0x02,                     //    Usage (Vendor Usage 2)
0xA1, 0x01,                     //    Collection (Application)
0x85, 0x11,                     //      REPORT_ID (17)
0x75, 0x08,                     //      REPORT_SIZE (8)
0x95, 0x13,                     //      REPORT_COUNT (19)
0x15, 0x00,                     //      LOGICAL_MINIMUM (0)
0x26, 0xFF, 0x00,               //      LOGICAL_MAXIMUM (255)
0x09, 0x02,                     //      USAGE (Vendor Usage 2)
0x81, 0x00,                     //      INPUT (data,Ary,Abs)
0x09, 0x02,                     //      USAGE (Vendor Usage 2)
0x91, 0x00,                     //     OUTPUT (data,Ary,Abs)
0xC0,                           // End Collection

In today's context, this would create one device node:
/dev/hidrawX

After the proposal has been implemented, it would create:
/dev/hidrawX   (access to the full hid interface including reports IDs
1 and 17, no change compared to today)
/dev/hidvendorX   (access to reportID 17 only)

Full user rights can be granted to all desktop users for
/dev/hidvendorX while keeping the input reports (report ID 1) secure.

>
> Regards
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cheers,
-nestor

Re: HID vendor access from user space

[Jiri Kosina]

On Wed, 2 Apr 2014, Nestor Lopez Casado wrote:

> >> If a user wants to configure/control the device there are two choices,
> >> either write a hid-specific driver to deal with the vendor specific
> >> collection, or open the corresponding /hidraw node from userspace.
> >>
> >> But a hidraw node that carries system input data requires root priviledges.
> >>
> >> I'm interested in hearing your opinions on how to add the capability
> >> for a normal user process to control/configure a HID device via
> >> reports exchanged with a vendor collection.
> >>
> >> I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
> >> for all top level HID collections which are today ignored by hid-input
> >> and/or other subsystems.
> >>
> >> These nodes would not require root priviledge by default and thus,
> >> users could control/reconfigure their devices from a standard
> >> application while keeping the "standard" input functionality intact.
> >
> > Why not write a kernel driver? We have a pretty nice infrastructure
> > for all this.
>
> Do you mean a "hid-specific" driver for certain vid & pid devices ?

I indeed believe that it's what David was proposing. Writing in-kernel 
drivers that handle just specific collections/usages, and let the rest 
be handled by the core infrastructure, is super-easy these days.

Also, if you need users to be able to trigger particular actions being 
perfomed by the driver, sysfs knobs should be a reasonable way to doing 
this.

As an example of such interface -- creating a sysfs trigger for 
hid-logitech-dj that will send the pairing command to the unified 
receiver, has been on my TODO list for quite some time already (and was 
even suggested by Linus).

> > If it's a license-issue, I recommend using udev rules to change
> > permissions on the requested devices directly during setup. You can
> > then use hidraw.
> It is not a license issue, it is a security issue.
> 
> Every hid class interface, (either usb, bluetooth, i2c, etc) has an
> associated hidraw node, and that node aggregates all reports sent from
> the device.
> 
> Say that for example, the device has a keyboard collection and a
> vendor collection, then changing permissions on the associated hidraw
> node (so as to give any desktop user unrestricted access to the vendor
> collection) would open the door to malicious code that could log the
> keyboard activity (as both the vendor reports and input reports are
> seen on the same hidraw node)

I think I am missing the point here. If you own the credentials of the 
session owner, you can log keystrokes anyway even now, just use

	xinput list
	xinput test <id>

and see the result :) Admittedly, this is a little bit more difficult when 
you are outside X11 session, but I am not sure how much concerned you are 
about such scenario anyway.

-- 
Jiri Kosina
SUSE Labs

Re: HID vendor access from user space

[Nestor Lopez Casado]

On Thu, Apr 3, 2014 at 3:57 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 2 Apr 2014, Nestor Lopez Casado wrote:
>
>> >> If a user wants to configure/control the device there are two choices,
>> >> either write a hid-specific driver to deal with the vendor specific
>> >> collection, or open the corresponding /hidraw node from userspace.
>> >>
>> >> But a hidraw node that carries system input data requires root priviledges.
>> >>
>> >> I'm interested in hearing your opinions on how to add the capability
>> >> for a normal user process to control/configure a HID device via
>> >> reports exchanged with a vendor collection.
>> >>
>> >> I have one proposal, which is to create, say  "/dev/hidvendorX", nodes
>> >> for all top level HID collections which are today ignored by hid-input
>> >> and/or other subsystems.
>> >>
>> >> These nodes would not require root priviledge by default and thus,
>> >> users could control/reconfigure their devices from a standard
>> >> application while keeping the "standard" input functionality intact.
>> >
>> > Why not write a kernel driver? We have a pretty nice infrastructure
>> > for all this.
>>
>> Do you mean a "hid-specific" driver for certain vid & pid devices ?
>
> I indeed believe that it's what David was proposing. Writing in-kernel
> drivers that handle just specific collections/usages, and let the rest
> be handled by the core infrastructure, is super-easy these days.

I don't think that the burden of hid input device status and
configuration should belong to the kernel 'for all devices in all
situations', as it would mandate the proliferation of many hid
specific code and too much kernel bloating that would be best handled
at a higher level. If we take for example the Logitech devices, we
have many features which are accessible via vendor collections, and
the easiest way to use them is via a user space application or
library.

>
> Also, if you need users to be able to trigger particular actions being
> perfomed by the driver, sysfs knobs should be a reasonable way to doing
> this.
>
> As an example of such interface -- creating a sysfs trigger for
> hid-logitech-dj that will send the pairing command to the unified
> receiver, has been on my TODO list for quite some time already (and was
> even suggested by Linus).
>
This is fine, but this solves a very particular case, the
pairing/unpairing of devices with the Unifying receiver. There is much
more to device configuration that just pairing/unpairing, it does not
even need to be Unifying devices, or Logitech devices, for that
matter.
(See also previous comment)


>> > If it's a license-issue, I recommend using udev rules to change
>> > permissions on the requested devices directly during setup. You can
>> > then use hidraw.
>> It is not a license issue, it is a security issue.
>>
>> Every hid class interface, (either usb, bluetooth, i2c, etc) has an
>> associated hidraw node, and that node aggregates all reports sent from
>> the device.
>>
>> Say that for example, the device has a keyboard collection and a
>> vendor collection, then changing permissions on the associated hidraw
>> node (so as to give any desktop user unrestricted access to the vendor
>> collection) would open the door to malicious code that could log the
>> keyboard activity (as both the vendor reports and input reports are
>> seen on the same hidraw node)
>
> I think I am missing the point here. If you own the credentials of the
> session owner, you can log keystrokes anyway even now, just use
>
>         xinput list
>         xinput test <id>
>
> and see the result :) Admittedly, this is a little bit more difficult when
> you are outside X11 session, but I am not sure how much concerned you are
> about such scenario anyway.

Oh, this I did not know!

Let me try to sketch the scenario we are concerned with:

We want user processes to be able to communicate with hid input
devices, via vendor specific commands. This vendor specific data flows
thru hid vendor reports.
Today, user processes can only access these reports via hidraw. Hidraw
aggregates user input (keyboard, mouse, etc) with vendor reports.

Hidraw nodes are owned by root by default. This means that an
unprivileged user would not be able to send vendor commands to a hid
device.
On the other hand, if an unprivileged user (or group) is given access
to hidraw, then she will also be able to spy the input, even if she is
remotely logged to a computer.

We consider this a potential security problem and we are looking into
a solution that would enable the currently logged local user to access
the vendor collections of a hid device without requiring any special
permissions.

Maybe the solution is not within the kernel itself, but rather on
using a user mode component, maybe the X server or even udev. Do you
get my point now ?

>
> --
> Jiri Kosina
> SUSE Labs

-nestor.

Re: HID vendor access from user space

[David Herrmann]

Hi

On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> We consider this a potential security problem and we are looking into
> a solution that would enable the currently logged local user to access
> the vendor collections of a hid device without requiring any special
> permissions.
>
> Maybe the solution is not within the kernel itself, but rather on
> using a user mode component, maybe the X server or even udev. Do you
> get my point now ?

There is a lot of work going on to make Xorg (and also Wayland
compositors) run as non-root. Many people, however, seem to ignore
that this means the compositor runs with the _same_ privileges as the
applications. At least that is the security model we are going for.
Therefore, if a compositor can access input devices, all applications
can do so, too. Of course, you can introduce new privilege-levels and
or run applications with less privileges than normal user processes.
But I guess you get the point.

Therefore, I really doubt there is much need to split the
access-rights here. What you wanna do is to provide this
privilege-separation on the kernel level. However, I think this is the
wrong way to do it. Imagine an HID device that has several
vendor-commands, some of them rather trivial and un-privileged, others
not. Do you expect the kernel to provide one device-node for each? How
do you expect the kernel to know which vender-extensions are _safe_ to
be grouped together?

Yes, the kernel should provide different interfaces for different
hw-features so user-space can apply fine-grained access-modes.
However, if we don't know what hardware feature a specific command
represents, I don't think we should apply some kind of random
interface separation. This is why Jiri and I recommend writing an
in-kernel driver. That driver can be small and all it does it provide
a separate interface for your vendor-extensions. This can be as easy
as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent
HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it
would be nicer if the kernel provides a proper interface-abstraction,
but I'd be fine with such a quirk, too.

Maybe you can describe one specific example? Otherwise, it's hard to
imagine hid devices that provide two totally separate interfaces that
we had the need to split them. All examples I know already provide
different virtual HID devices and thus don't suffer from this problem.
Furthermore, did you do some research how other platforms deal with
it?

Thanks
David

Re: HID vendor access from user space

[Nestor Lopez Casado]

On Mon, Apr 7, 2014 at 6:27 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado
> <nlopezcasad@logitech.com> wrote:
>> We consider this a potential security problem and we are looking into
>> a solution that would enable the currently logged local user to access
>> the vendor collections of a hid device without requiring any special
>> permissions.
>>
>> Maybe the solution is not within the kernel itself, but rather on
>> using a user mode component, maybe the X server or even udev. Do you
>> get my point now ?
>
> There is a lot of work going on to make Xorg (and also Wayland
> compositors) run as non-root. Many people, however, seem to ignore
> that this means the compositor runs with the _same_ privileges as the
> applications. At least that is the security model we are going for.
> Therefore, if a compositor can access input devices, all applications
> can do so, too. Of course, you can introduce new privilege-levels and
> or run applications with less privileges than normal user processes.
> But I guess you get the point.
>
> Therefore, I really doubt there is much need to split the
> access-rights here. What you wanna do is to provide this
> privilege-separation on the kernel level. However, I think this is the
> wrong way to do it. Imagine an HID device that has several
> vendor-commands, some of them rather trivial and un-privileged, others
> not. Do you expect the kernel to provide one device-node for each? How
> do you expect the kernel to know which vender-extensions are _safe_ to
> be grouped together?

I do not expect the kernel to know whether vendor extensions are safe
to be grouped together, I would simply provide them as a separate
-user accessible- interface whose access rights can be assigned
separately from the classic input collections.

Assignment of access rights would then be up to udev rules. Which each
manufacturer/user can define for each of its devices. By default
access rights would stay for root only.

>
> Yes, the kernel should provide different interfaces for different
> hw-features so user-space can apply fine-grained access-modes.
> However, if we don't know what hardware feature a specific command
> represents, I don't think we should apply some kind of random
> interface separation. This is why Jiri and I recommend writing an
> in-kernel driver. That driver can be small and all it does it provide
> a separate interface for your vendor-extensions. This can be as easy
> as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent
> HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it
> would be nicer if the kernel provides a proper interface-abstraction,
> but I'd be fine with such a quirk, too.

The problem I see with a specific kernel driver for a specific vendor
extension is two fold:
1) It creates some potential for code bloat/duplication in the kernel
across multiple drivers for different manufacturers, while the only
purpose of this driver would be to expose some raw vendor
functionality to user programs.

2) The interface provided by this driver to user programs would
probably diverge from driver to driver, making it impossible to have a
generic user component (think signal11's HidApi lib for instance) to
provide a consistent hid access library across operating systems.

>
> Maybe you can describe one specific example? Otherwise, it's hard to
> imagine hid devices that provide two totally separate interfaces that
> we had the need to split them. All examples I know already provide
> different virtual HID devices and thus don't suffer from this problem.

You can look at the hid device descriptor that I posted in a previous
message of this thread. This device descriptor actually comes from one
of our devices: The Logitech BT Illuminated kbd K810. Most of our
input devices follow this pattern:

- Top level "classic" collection types (mouse, keyboard, etc)
- Top level vendor collections.

The vendor collections are the method we use to access extended
functionality of the device, (button reprogrammability, dpi settings,
extended battery status, firmware update and many others)

> Furthermore, did you do some research how other platforms deal with
> it?

Neither Microsoft Windows nor Apple Mac OS provide a posix-style
filesystem based device access model for HID devices. Nevertheless,
Windows does provide "physical device objects" for each top level
collection found in a hid device. From msdn:

"A report descriptor can include more than one top-level collection.
The HID class driver enumerates the top-level collections of an input
device and creates a physical device object (PDO) for each top-level
collection. User-mode applications or kernel-mode drivers can access a
top-level collection by opening its PDO and using the HIDClass support
routines and the HID class driver IOCTLs"

Access rights to vendor collection PDOs is granted to any logged on user.

Apple's Mac OS HidManager client API, provides a mechanism to select
the parent device of any top level hid collection, then Set/Get
report-style APIs to address each of the vendor collections.

Access rights seem to be given to any logged on user.

>
> Thanks
> David

Re: HID vendor access from user space

[Nestor Lopez Casado]

David, Jiri,

After considering our discussion here, which is your position on
extending the hidraw nodes to include separate nodes for top level
vendor collections ?

Cheers,
-nestor

On Tue, Apr 8, 2014 at 5:53 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> On Mon, Apr 7, 2014 at 6:27 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Hi
>>
>> On Mon, Apr 7, 2014 at 6:15 PM, Nestor Lopez Casado
>> <nlopezcasad@logitech.com> wrote:
>>> We consider this a potential security problem and we are looking into
>>> a solution that would enable the currently logged local user to access
>>> the vendor collections of a hid device without requiring any special
>>> permissions.
>>>
>>> Maybe the solution is not within the kernel itself, but rather on
>>> using a user mode component, maybe the X server or even udev. Do you
>>> get my point now ?
>>
>> There is a lot of work going on to make Xorg (and also Wayland
>> compositors) run as non-root. Many people, however, seem to ignore
>> that this means the compositor runs with the _same_ privileges as the
>> applications. At least that is the security model we are going for.
>> Therefore, if a compositor can access input devices, all applications
>> can do so, too. Of course, you can introduce new privilege-levels and
>> or run applications with less privileges than normal user processes.
>> But I guess you get the point.
>>
>> Therefore, I really doubt there is much need to split the
>> access-rights here. What you wanna do is to provide this
>> privilege-separation on the kernel level. However, I think this is the
>> wrong way to do it. Imagine an HID device that has several
>> vendor-commands, some of them rather trivial and un-privileged, others
>> not. Do you expect the kernel to provide one device-node for each? How
>> do you expect the kernel to know which vender-extensions are _safe_ to
>> be grouped together?
>
> I do not expect the kernel to know whether vendor extensions are safe
> to be grouped together, I would simply provide them as a separate
> -user accessible- interface whose access rights can be assigned
> separately from the classic input collections.
>
> Assignment of access rights would then be up to udev rules. Which each
> manufacturer/user can define for each of its devices. By default
> access rights would stay for root only.
>
>>
>> Yes, the kernel should provide different interfaces for different
>> hw-features so user-space can apply fine-grained access-modes.
>> However, if we don't know what hardware feature a specific command
>> represents, I don't think we should apply some kind of random
>> interface separation. This is why Jiri and I recommend writing an
>> in-kernel driver. That driver can be small and all it does it provide
>> a separate interface for your vendor-extensions. This can be as easy
>> as setting HID_QUIRK_MULTI_INPUT for given devices (or an equivalent
>> HID_QUIRK_MULTI_HIDRAW, which doesn't exist, yet). I still think it
>> would be nicer if the kernel provides a proper interface-abstraction,
>> but I'd be fine with such a quirk, too.
>
> The problem I see with a specific kernel driver for a specific vendor
> extension is two fold:
> 1) It creates some potential for code bloat/duplication in the kernel
> across multiple drivers for different manufacturers, while the only
> purpose of this driver would be to expose some raw vendor
> functionality to user programs.
>
> 2) The interface provided by this driver to user programs would
> probably diverge from driver to driver, making it impossible to have a
> generic user component (think signal11's HidApi lib for instance) to
> provide a consistent hid access library across operating systems.
>
>>
>> Maybe you can describe one specific example? Otherwise, it's hard to
>> imagine hid devices that provide two totally separate interfaces that
>> we had the need to split them. All examples I know already provide
>> different virtual HID devices and thus don't suffer from this problem.
>
> You can look at the hid device descriptor that I posted in a previous
> message of this thread. This device descriptor actually comes from one
> of our devices: The Logitech BT Illuminated kbd K810. Most of our
> input devices follow this pattern:
>
> - Top level "classic" collection types (mouse, keyboard, etc)
> - Top level vendor collections.
>
> The vendor collections are the method we use to access extended
> functionality of the device, (button reprogrammability, dpi settings,
> extended battery status, firmware update and many others)
>
>> Furthermore, did you do some research how other platforms deal with
>> it?
>
> Neither Microsoft Windows nor Apple Mac OS provide a posix-style
> filesystem based device access model for HID devices. Nevertheless,
> Windows does provide "physical device objects" for each top level
> collection found in a hid device. From msdn:
>
> "A report descriptor can include more than one top-level collection.
> The HID class driver enumerates the top-level collections of an input
> device and creates a physical device object (PDO) for each top-level
> collection. User-mode applications or kernel-mode drivers can access a
> top-level collection by opening its PDO and using the HIDClass support
> routines and the HID class driver IOCTLs"
>
> Access rights to vendor collection PDOs is granted to any logged on user.
>
> Apple's Mac OS HidManager client API, provides a mechanism to select
> the parent device of any top level hid collection, then Set/Get
> report-style APIs to address each of the vendor collections.
>
> Access rights seem to be given to any logged on user.
>
>>
>> Thanks
>> David

Re: HID vendor access from user space

[David Herrmann]

Hi

On Mon, Apr 14, 2014 at 12:00 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> David, Jiri,
>
> After considering our discussion here, which is your position on
> extending the hidraw nodes to include separate nodes for top level
> vendor collections ?

Patches, patches, patches!

I am currently on the road, but it's always easier to see real code
than just the theory. I have no real objections to provide multiple
hidraw interfaces. However, I think that doesn't solve your problem.
For instance, you still need to set proper access-rights on the hidraw
node. However, some other devices might export unsafe interfaces via
vendor-extensions, and you don't wanna make those hidraw nodes
user-accessible. Therefore, you still need a udev-rule to match on
Logitech-stuff. You could do that as a small Logitech-driver in the
kernel. But ok, I'm fine with moving those whitelists to user-space.

Thanks
David

Re: HID vendor access from user space

[Nestor Lopez Casado]

Ok, thanks David.

-nestor

On Tue, Apr 15, 2014 at 4:16 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Mon, Apr 14, 2014 at 12:00 PM, Nestor Lopez Casado
> <nlopezcasad@logitech.com> wrote:
>> David, Jiri,
>>
>> After considering our discussion here, which is your position on
>> extending the hidraw nodes to include separate nodes for top level
>> vendor collections ?
>
> Patches, patches, patches!
>
> I am currently on the road, but it's always easier to see real code
> than just the theory. I have no real objections to provide multiple
> hidraw interfaces. However, I think that doesn't solve your problem.
> For instance, you still need to set proper access-rights on the hidraw
> node. However, some other devices might export unsafe interfaces via
> vendor-extensions, and you don't wanna make those hidraw nodes
> user-accessible. Therefore, you still need a udev-rule to match on
> Logitech-stuff. You could do that as a small Logitech-driver in the
> kernel. But ok, I'm fine with moving those whitelists to user-space.
>
> Thanks
> David

Re: HID vendor access from user space

[Jiri Kosina]

On Mon, 14 Apr 2014, Nestor Lopez Casado wrote:

> After considering our discussion here, which is your position on
> extending the hidraw nodes to include separate nodes for top level
> vendor collections ?

The exact usecase is still a bit unclear to me. Has there been any 
explanation how you are going to deal with the fact that X protocol 
exposes all the events to X session owner anyway? (sorry if it was and I 
missed it).

Frankly, I'd really like to avoid any parsing (deciding about collections) 
whatsoever around hidraw, as that was the whole point of creating it in 
parallel to hiddev was simply 'no parsing, raw access'.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: HID vendor access from user space

[Nestor Lopez Casado]

On Tue, Apr 15, 2014 at 9:39 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 14 Apr 2014, Nestor Lopez Casado wrote:
>
>> After considering our discussion here, which is your position on
>> extending the hidraw nodes to include separate nodes for top level
>> vendor collections ?
>
> The exact usecase is still a bit unclear to me. Has there been any
> explanation how you are going to deal with the fact that X protocol
> exposes all the events to X session owner anyway? (sorry if it was and I
> missed it).

The X session owner can spy its own keystrokes. This seems acceptable.

Hidraw nodes are the only way a user can talk "vendor hid" with
plugged devices. Once you are less restrictive with hidraw nodes (i.e.
grant access to more users that root) to allow hid vendor interaction,
then any of those users can log anything happening on the concerned
hidraw node, even remotely. This is not the case in X.

Having more granularity at the hidraw level enables assigning
different user rights to the different nodes belonging to the same
parent hid device, so that sensitive user input can remain protected
while access to the vendor interface can be left open. As David said,
this clearly does not solve "all problems", as  some vendor features
in some devices might not be safe to be exposed, but then it will be
up to the users/vendors to grant/block access to those collections via
udev rules. Moreover, this feature will keep a very similar interface
to current hidraw ioctl/open/close and the code will most likely
remained contained to a single module or even can simply become part
of hidraw.c

As David mentions, the same kind of functionality could also be
achieved via hid specific drivers for vendor collections in each of
the products, but it has the drawback that we will be proliferating
more hid-specific drivers whose only purpose will be to expose a
vendor interface to user applications, creating the potential for
kernel code duplication and disparate user interfaces.

>
> Frankly, I'd really like to avoid any parsing (deciding about collections)
> whatsoever around hidraw, as that was the whole point of creating it in
> parallel to hiddev was simply 'no parsing, raw access'.

We should avoid naming the new nodes "hidrawX" they could be
"hidvendorX" for instance, or it could also be "hidcolX" where col
stands for collection. We will be moving the "raw" one level down.

It can be thought of as a multiple interface usb device that already
creates multiple hidraw devices, but taken one step further.

>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs

Cheers,
-nestor

Re: HID vendor access from user space

[Jiri Kosina]

On Tue, 15 Apr 2014, Nestor Lopez Casado wrote:

> > Frankly, I'd really like to avoid any parsing (deciding about collections)
> > whatsoever around hidraw, as that was the whole point of creating it in
> > parallel to hiddev was simply 'no parsing, raw access'.
> 
> We should avoid naming the new nodes "hidrawX" they could be
> "hidvendorX" for instance, or it could also be "hidcolX" where col
> stands for collection. We will be moving the "raw" one level down.

I am still having trouble seeing how this would work together with current 
hidraw.

In your proposal, there will be both hidrawX and hidcolX existing in 
parallel, right? Who will be deciding what goes to hidcolX instead of 
hidrawX? One of the pain points would be -- /dev/hidrawX will have to stay 
anyway for compatibility reasons, so we can't just divide it to multiple 
/dev/hidcolX all of a sudden and never look back.

-- 
Jiri Kosina
SUSE Labs

Re: HID vendor access from user space

[Nestor Lopez Casado]

On Wed, Apr 16, 2014 at 4:53 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 15 Apr 2014, Nestor Lopez Casado wrote:
>
>> > Frankly, I'd really like to avoid any parsing (deciding about collections)
>> > whatsoever around hidraw, as that was the whole point of creating it in
>> > parallel to hiddev was simply 'no parsing, raw access'.
>>
>> We should avoid naming the new nodes "hidrawX" they could be
>> "hidvendorX" for instance, or it could also be "hidcolX" where col
>> stands for collection. We will be moving the "raw" one level down.
>
> I am still having trouble seeing how this would work together with current
> hidraw.
>
> In your proposal, there will be both hidrawX and hidcolX existing in
> parallel, right?
Yes.

> Who will be deciding what goes to hidcolX instead of
> hidrawX?
The additional code that we will put in place.
Having said that, hidrawX will still get the same reports as before,
nothing will change for those nodes.

> One of the pain points would be -- /dev/hidrawX will have to stay
> anyway for compatibility reasons, so we can't just divide it to multiple
> /dev/hidcolX all of a sudden and never look back.
That's true.

A device with one mouse collection and one vendor collection would
give something like this:
/dev/input/eventX  (no change) this comes via hid-input
/dev/mouse           (no change)
/dev/hidrawX         (no change) (all reports still show up here)
/dev/hidcolX          (reports from corresponding colX will show up here)

So only top level vendor collections which are not parsed (claimed) by
any hid-xx module today would appear under hidcolX.

Unless you have a major blocker, as David said, I think the best would
be to come up with some code and post a proposal patch for
consideration.

>
> --
> Jiri Kosina
> SUSE Labs

Cheers,
-nestor

Re: HID vendor access from user space

[David Herrmann]

Hi

On Wed, Apr 23, 2014 at 11:14 AM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> A device with one mouse collection and one vendor collection would
> give something like this:
> /dev/input/eventX  (no change) this comes via hid-input
> /dev/mouse           (no change)
> /dev/hidrawX         (no change) (all reports still show up here)
> /dev/hidcolX          (reports from corresponding colX will show up here)
>
> So only top level vendor collections which are not parsed (claimed) by
> any hid-xx module today would appear under hidcolX.

I still think you should do that in user-space. That is, whatever
daemon opens the input-device should provide this abstraction (like
via XInput2 etc.). Otherwise, someone else pops up and tells us a
specific non-vendor extension is also unprivileged and wants them as
separate interface. There is no clear split how fine-grained the
access-control should be. Yes, you might have a specific example, but
we don't want to make that a generic interface.

Thanks
David