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

[Andy Lutomirski]

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.

--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