[systemd-devel] Supporting U2F over HID on Linux?
luto at amacapital.net
Tue Dec 9 12:46:56 PST 2014
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?
>>> > 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.
>> Jiri Kosina
>> SUSE Labs
> Andy Lutomirski
> AMA Capital Management, LLC
AMA Capital Management, LLC
More information about the systemd-devel