On Sat, Dec 13, 2014 at 4:48 PM, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx> wrote: > On Sat, Dec 13, 2014 at 7:41 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Sat, Dec 13, 2014 at 4:39 PM, Benjamin Tissoires >> <benjamin.tissoires@xxxxxxxxx> wrote: >>> On Sat, Dec 13, 2014 at 7:33 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires >>>> <benjamin.tissoires@xxxxxxxxx> wrote: >>>>> >>>>> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@xxxxxxxxxxxxxx> wrote: >>>>>> >>>>>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: >>>>>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote: >>>>>> > >>>>>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard >>>>>> >> is amazingly vague), that means that the application sends a short >>>>>> >> (<64kB) binary request to the device (with a type, two "parameters", >>>>>> >> and a payload), and the device answers with exactly one reply packet >>>>>> >> that has two bytes of status and a payload. These requests and >>>>>> >> replies are fragmented into multiple HID reports. >>>>>> > >>>>>> > Sorry for taking one (or maybe even more) step back, but what makes this >>>>>> > thing even "HID device"? >>>>>> > >>>>>> > Yes, it interacts with human beings, but are the operations it's doing >>>>>> > covered by HID specification (at least in a "does it have HID >>>>>> > descriptor" >>>>>> > sense)? It's not really completely clear to me at this point. >>>>>> >>>>>> It has a HID descriptor, it's recognized by the HID stack, it >>>>>> understands SET_REPORT, and it generates async HID reports. Hidraw is >>>>>> willing to talk to it and, in fact, Chromium talks to it using hidraw >>>>>> (ugh). >>>>>> >>>>>> It's also supposed to be *enumerated* by reading the HID descriptor. >>>>>> There are multiple vendors of these things, and the USB descriptor >>>>>> doesn't seem to have anything in it to identify the device. >>>>>> >>>>>> I think that's the full extent to which it's a HID device. >>>>> >>>>> And the most important, these devices have a button on them :) >>>> >>>> Someone should have told the U2F committee that the device should send >>>> a HID report, then :-/ >>>> >>>> (Also, at least one implementation is missing the button. You "press >>>> the button" by unplugging and replugging the whole device.) >>>> >>> >>> Well, on the Yubico Fido U2F, there is a button, but it only works >>> when the client calls the right SET_REPORT. I guess it is to prevent >>> an attack when there is nobody physically behind the key. So >>> removing/replugging the device gives the same security: a physical >>> interaction is required. >>> >>> Not sending an input report is here to help such button-less devices. >> >> It requires that apps on devices with buttons (e.g. the Yubico device) >> poll to see when the button is pressed, though. > > So this gives one more reason to have a proper kernel interface for > not doing this ugly polling :) > > Out of curiosity, how did you managed to get the unplug/replugged > working? Normally, a hid(raw) device is tighten to its physical > presence, so when you remove the device, you should lose all the > context... The way it works is that you send an authentication request and the device either consumes a button press and accepts the request or it blinks the light and returns an error. Userspace is expected to retry the entire request until it works. So the kernel *can't* avoid polling because the device doesn't give any (documented) asynchronous indication that the button was pressed. On the other hand, if you unplug and replug a device, there's no state lost because there was never any state to begin with. --Andy > > Cheers, > Benjamin > >>> >>> >>>> --Andy >>>> >>>>> >>>>> Cheers, >>>>> Benjamin >>>>> >>>>>> >>>>>> --Andy >>>>>> >>>>>> > >>>>>> > Thanks, >>>>>> > >>>>>> > -- >>>>>> > Jiri Kosina >>>>>> > SUSE Labs >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Andy Lutomirski >>>>>> AMA Capital Management, LLC >>>> >>>> >>>> >>>> -- >>>> 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
