On Tue, Dec 9, 2014 at 12:46 PM, Andy Lutomirski [off-list ref] wrote:

On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski [off-list ref] wrote:

quoted

On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina [off-list ref] wrote:

quoted

On Mon, 3 Nov 2014, David Herrmann wrote:

quoted

quoted

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

quoted

--Andy

quoted

quoted

quoted

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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel