Re: Supporting U2F over HID on Linux?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2 Nov 2014, Andy Lutomirski wrote:

> > Hmmm ... please keep in mind that report_descriptor is actually in 
> > debugfs, so it's a bit questionable whether you can rely on it being 
> > present on well-defined location on all systems.
> 
> Huh?  I have 
> /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor 
> on my system.

Brainfart on my side. We have 'rdesc' and 'events' in debugfs sice a long 
time, but then 'report_descriptor' has been added as a proper sysfs 
attribute some time around 3.0.

> >> - HID core code in the kernel to add
> >> HID_USAGES=f1d00001:lots:of:other:things to the uevent (or udev code
> >> to do the same).  This might end up producing a rather long string or
> >> some devices.
> >
> > We have been thinking about this quite a lot in the past, and decided to
> > postpone this until there is a very good reason for it to happen.
> 
> I'm not sure that U2F counts as a very good reason.

It might well be the justifying reason. I'd first like to see what other 
options we have though.

> >>  - An actual kernel driver for U2F devices using the hid group
> >> mechanism for enumeration.  This seems overcomplicated.
> >
> > Hmmm ... why do you think so? I believe it actually should be really
> > super-trivial.
> 
> The HID group part is trivial, but what interface would the driver
> expose?  I don't think that a udev rule for hidraw matching the
> modalias makes any sense, and, if it were a real driver, what
> interface would it expose?  Most cross-platform userspace code for U2F
> is likely to use HIDAPI.
> 
> Admittedly, a U2F driver in the kernel would be slightly nicer from a
> multiplexing standpoint than hidraw.

Alternatively, you can just write udev rule which triggers on HID devices, 
issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides 
afterwards whether node permissions need to be altered ... right?

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux