search

Nitrokey / nitrokey-start-firmware

A mirror of Gnuk's 1.0.x and 1.2.x branches.
56 stars 15 forks source link

Slow boot time #45

Closed szszszsz closed 4 years ago

szszszsz commented 4 years ago

With HID interface enabled (see #40) the boot time has increased significantly to 5+ seconds.

System log excerpt:

[  +1.664057] usb 3-6: new full-speed USB device number 19 using xhci_hcd
[  +0.127473] usb 3-6: New USB device found, idVendor=20a0, idProduct=4211, bcdDevice= 2.00
[  +0.000004] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000003] usb 3-6: Product: Nitrokey Start
[  +0.000002] usb 3-6: Manufacturer: Nitrokey
[  +0.000003] usb 3-6: SerialNumber: FSIJ-1.2.15-87042524
[  +5.340379] input: Nitrokey Nitrokey Start as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.1/0003:20A0:4211.000F/input/input27
[  +0.053454] hid-generic 0003:20A0:4211.000F: input,hidraw5: USB HID v1.10 Keypad [Nitrokey Nitrokey Start] on usb-0000:00:14.0-6/input1
szszszsz commented 4 years ago

cc @kliment

kliment commented 4 years ago

Possibly related: https://unix.stackexchange.com/questions/128950/udev-taking-15-seconds-to-detect-mouse

kliment commented 4 years ago

I can replicate the issue on my machine, and it appears to be only the HID device that is slow to appear. The ccid appears immediately (and so does the HID interface, but it takes 5s for the driver to claim it)

szszszsz commented 4 years ago

For comparison, Nitrokey FIDO2 device shows up immediately:

[  +3.341045] usb 3-6: new full-speed USB device number 18 using xhci_hcd
[  +0.127592] usb 3-6: New USB device found, idVendor=20a0, idProduct=42b1, bcdDevice= 1.00
[  +0.000006] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000003] usb 3-6: Product: Nitrokey FIDO2 2.0.0
[  +0.000003] usb 3-6: Manufacturer: Nitrokey
[  +0.000002] usb 3-6: SerialNumber: 20553381344B
[  +0.003741] hid-generic 0003:20A0:42B1.000E: hiddev97,hidraw5: USB HID v1.11 Device [Nitrokey Nitrokey FIDO2 2.0.0] on usb-0000:00:14.0-6/input0

Maybe it has something to do with the Keypad device?

kliment commented 4 years ago

Yes, it's being claimed as an input device (with a long delay, likely a driver-level timeout) whereas the fido2 only appears as a generic device (not claimed by the input driver). I suspect this is a descriptor-level issue (we're claiming to be something we're not, and the driver is expecting a response and not getting it). I'll set up some USB logging and investigate.

szszszsz commented 4 years ago

Indeed, I think the keypad is another idea from upstream, but disabled in our build as far as I see. Changing identifier to a generic HID device might solve the problem.

kliment commented 4 years ago

Okay, I logged the USB transaction and it takes the device 5 seconds to process a SET_IDLE command from the host. This is definitely an issue from upstream. We don't support SET_IDLE requests and should therefore return STALL. I'll see if I can find where this is in our code.

kliment commented 4 years ago

Found it, and disabled the handling of that command, and the delay is gone.