Issue 433127 in chromium: gnubby : with usb autosuspend enabled for security key devices, initial login to Chrome OS is sometimes flaky

[chro...@googlecode.com]

Status: Available
Owner: ----
CC: mschil...@chromium.org, ble...@chromium.org, sna...@chromium.org
Labels: Type-Bug Pri-2 OS-Chrome Cr-OS-Kernel Cr-OS-Kernel-Power Cr-Security

New issue 433127 by ble...@chromium.org: gnubby : with usb autosuspend
enabled for security key devices, initial login to Chrome OS is sometimes
flaky
https://code.google.com/p/chromium/issues/detail?id=433127

So, I've convinced myself that the kernel change I posted is sane, but
I'm still running into some corner cases around the 2-step
verification dialogs in the Chrome OS login screen.

Here's how I've gotten it to fail :

1. log in as a user that requires 2-step verification via security key
2. attach the security key when prompted, tap it, log in sucessfully
3. leave the key attached
4. log out.
5. Delete the user.
6. Log in again.

This time, the key never lights up. If I unplug the key, i get 'an
unexpected error has occurred'.

This is 100% reproducible.

Removing the security key and reattaching it and allowing the dialog to
retry works.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Issue 433127: gnubby : with usb autosuspend enabled for security key

devices, initial login to Chrome OS is sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

This issue is now blocking issue chrome-os-partner:32752.
See https://code.google.com/p/chrome-os-partner/issues/detail?id=32752

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #2 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

Note, you'll need my patch is issue 431886, which as of right now hasn't
landed, to repro using a hid firmware gnubby.

[chro...@googlecode.com]

Updates:
Cc: puneets...@chromium.org

Comment #3 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Status: Started
Owner: ble...@chromium.org
Cc: juanl...@chromium.org arn...@chromium.org

Comment #4 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

+arnarb@ and +juanlang@

Marius recommended that you should be added to this issue.

I can double check what is going on at the kernel level, but there may be
some behavior that's happening that's different from when logged in.

[chro...@googlecode.com]

Updates:
Cc: ble...@google.com

Comment #5 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #6 on issue 433127 by juanl...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

When you attempt to log in the second time, does the key light up when
tapped? It should toggle the LED solid green with a tap, and off again, if
it's getting power and is enumerated by the host. If it's not doing that,
then the issue is at a lower layer. If it is, then Chrome's USB stack or
the cryptotoken extension are to blame.

[chro...@googlecode.com]

Comment #9 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

I've updated the hid firmware on my security key to version 0.9.7. The
failure occurs just as before.

[chro...@googlecode.com]

Comment #10 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

I see this in ui.LATEST :

[21232:21232:1125/161101:ERROR:logging.h(777)] Failed to call method:
org.chromium.PermissionBroker.RequestPathAccess: object_path=
/org/chromium/PermissionBroker: org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.

[chro...@googlecode.com]

Updates:
Cc: reil...@chromium.org

Comment #11 on issue 433127 by ble...@chromium.org: gnubby : with usb

autosuspend enabled for security key devices, initial login to Chrome OS is
sometimes flaky
https://code.google.com/p/chromium/issues/detail?id=433127

+reillyg@