Bug 265528 - webauth u2f doesn't seem to work when hw.usb.usbhid.enable=1 is set (no uhid dev entries)
Summary: webauth u2f doesn't seem to work when hw.usb.usbhid.enable=1 is set (no uhid ...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 13.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Vladimir Kondratyev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-31 06:33 UTC by Trenton Schulz
Modified: 2024-05-04 22:34 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trenton Schulz 2022-07-31 06:33:28 UTC
There seems to be an issue when running a YubiKey with hw.usb.usbhid.enable set in /boot/loader.conf

The browser presents the prompt for pressing the YubiKey, but the press is never registered in the browser.

Steps to reproduce:

0. Have access to a YubiKey
1. Boot 13.1-RELEASE with hw.usb.usbhid.enable=1 in /boot/loader.conf
2. Install www/firefox and sysutils/u2f-devd
2a. Ensure the user is in the u2f group and restart devd for the key to get proper permissions
3. Go to https://demo.yubico.com/webauthn-technical/registration and click next.
4. You will get a prompt to press the YubiKey, but the press will never register, and the only way out is to cancel.

Booting without hw.usb.usbhid.enable=0 (or not set) does work. The only difference I can see in /dev between the two boots is that there are entries for uhid* when hw.usb.usbhid.enable=0, but none when enable=1. From looking at u2f-devd, web browsers use uhid for webauth.
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2022-07-31 15:47:29 UTC
This is a known issue. UGEN had a patch to not do read-ahead, and usbhid.enable=1 needs the same. Adding wulf@

--HPS
Comment 3 Trenton Schulz 2022-07-31 16:45:33 UTC
(In reply to Hans Petter Selasky from comment #2)

OK. Thanks for the info. I guess I can do a stable build and see if that works. Unless, was the one commit in comment #2 only part of the fix?
Comment 4 Hans Petter Selasky freebsd_committer freebsd_triage 2022-07-31 17:45:54 UTC
This change is already merged to 13/stable, but only for /dev/uhidN access!

https://cgit.freebsd.org/src/commit/?id=20d32249196ea6122b481bd61841337a67855337

--HPS
Comment 5 Trenton Schulz 2022-08-02 18:18:26 UTC
(In reply to Hans Petter Selasky from comment #4)

OK, Hans Petter, I understand. This fix is in 13-STABLE for uhid, but not for the newer usbhid (hence why there are no *hid entries in /dev when hw.usb.usbhid.enable=1 on 13.1-RELEASE and 13-STABLE)

For the time being, running with hw.usb.usbhid.enable=0 (the default) is fine. I was more trying the newer drivers just to see how they worked. I will be happy to test things out when a patch is ready.
Comment 6 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-08-02 19:07:09 UTC
(In reply to Trenton Schulz from comment #5)
Hi Trenton,

I have some WIP patches in my local repo to disable read-ahead for YubiKey with usbhid. But they require some additional work. I hope to continue work on them in couple of weeks.
Unfortunately usbhid(4) read-ahead can not be disabled with one-line patch like uhid(4) did.
Comment 7 Tomasz "CeDeROM" CEDRO 2022-08-02 20:39:09 UTC
+1 I also use YubiKey and could make use of that patch please let me know when its ready for testing I have 13-STABLE :-)
Comment 8 Vladimir Kondratyev freebsd_committer freebsd_triage 2022-12-25 11:30:33 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #7)

> let me know
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263995
It requires some tweaking for STABLE13
Comment 9 Trenton Schulz 2022-12-28 10:17:47 UTC
I tried out the -stable patch from #263995, and it seems to work well with the webauth demos I reported here.

So, for this bug, I would say that it seems to work. Thanks.