On Tue, Dec 9, 2014 at 12:46 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina <jkosina@xxxxxxx> wrote:
>>> On Mon, 3 Nov 2014, David Herrmann wrote:
>>>
>>>> > Agreed, mostly. My only real concern is that this could be annoying
>>>> > for the userspace developers who will need to target Linux and HIDAPI
>>>> > separately. Admittedly the Linux support will be trivial.
>>>>
>>>> I see. I'll not stop you from using hidraw, I'd just not recommend it.
>>>> Especially for security stuff I dislike exposing the whole HID device
>>>> writable. But yeah, I guess you got my point.
>>>
>>> Alright, I am basically thinking loudly now, but how about we allow HID
>>> drivers that would override default hidraw interface?
>>>
>>> I am very well aware of the fact that this could be opening a can of
>>> worms, so we'll have to make it very restrictive. How about, let's say, we
>>> allow HID drivers to provide custom hidraw interface (completely
>>> overriding the one that HID core would normally create) only for cases
>>> such as:
>>>
>>> - the intent is to expose only certain parts of a combined device
>>> - the intent is to introduce some level of access control
>>>
>>> I.e. still no interference of kernel with data parsing allowed.
>>
>> Hmm. Would this be like a filter on hidraw actions?
>>
>> How would udev distinguish these special hidraw devices from normal
>> hidraw devices?
>>
>> Also, for U2F, this could be a little awkward. There's some crazy
>> fragmentation stuff to allow a U2F request to be split across HID
>> requests, and I think a kernel driver would much rather get the
>> original unfragmented application request.
>>
>
> I started writing a driver for this. I got enumeration working. I
> assume I should create a "u2f" device class, and then... ?
>
> Where am I supposed to get my character device from? Do I register my
> own chrdev major? Do I use misc? Is there some input thing I'm
> supposed to use?
Another question:
I'm hitting this in hid_input_report:
if (down_trylock(&hid->driver_input_lock)) {
pr_err("HID: trylock failed\n"); // I added this
return -EBUSY;
}
This is a problem for u2f: u2f reports are actual protocol messages,
and there isn't a retransmit mechanism. Losing messages randomly
causes the handshake to fail, and then nothing works.
I *think* that the only way I can hit that failure is during probe (or
if the USB stack somehow completes two transfers at once). This still
makes it quite awkward to start IO from the probe routine.
I could start a work item to take driver_input_lock, release it again,
and then start the handshake, but that sucks.
Ideas?
--Andy
>
> Thanks,
> Andy
>
>> --Andy
>>
>>>
>>>> > I can give the driver a try. It'll actually be simpler than the spec
>>>> > makes it out, since a real kernel driver will have no need to
>>>> > arbitrate with itself.
>>>>
>>>> I'll gladly review any custom HID drivers. Feel free to put me on CC
>>>> when sending to linux-input. There's also a lot of examples in
>>>> drivers/hid/ in case you need a head-start (especially if you need the
>>>> raw_event callback).
>>>
>>> Same here, of course.
>>>
>>> Please always CC me in parallel to sending to linux-input@ to make sure
>>> that the patch doesn't fall in between cracks.
>>>
>>> Thanks,
>>>
>>> --
>>> Jiri Kosina
>>> SUSE Labs
>>
>>
>>
>> --
>> Andy Lutomirski
>> AMA Capital Management, LLC
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
