[systemd-devel] Supporting U2F over HID on Linux?

[Andy Lutomirski]

On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina <jkosina at suse.cz> 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?

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