Never-ending initialization for composite readers like Rocketek #849
Assignees
Labels
Comments
This was referenced Jul 25, 2023
emaxx-google
added a commit
that referenced
this issue
Jul 26, 2023
Add a basic unit test for our libusb_get_active_config_descriptor() implementation (a.k.a LibusbJsProxy::LibusbGetActiveConfigDescriptor()). The input parameters for the test are taken from an arbitrary real-world reader (SCM SCR 3310). This commit is preparation for regression testing of #849.
emaxx-google
added a commit
that referenced
this issue
Jul 26, 2023
Only let the PC/SC see those USB device interfaces that have suitable
properties. The exact criteria is replicated from what the CCID
driver does internally: either the interface class should be "11"
("Smart Card") or both it should be "255" ("Vendor Specific") and the
extra data length should be "54" (which is the standard length of the
CCID descriptor).
The primary goal is to workaround issues with specific composite devices
on modern ChromeOS versions. Before this commit, PC/SC would see all
interfaces and attempt to connect via each of them. This used to cause
no harm, except spurious errors (which we suppressed heuristically).
However, ChromeOS version 105 introduced behavior change, not allowing
to connect to such composite devices more than once. In combination with
our previously built heuristic "if connection fails, simulate that the
whole device reappears under a different bus number" this results in
some devices not being able to initialize at all. This commit fixes such
issues (we're still discussing if ChromeOS permission_broker could
behave better in this case). As a bonus, we reduce log spam for all
composite devices.
This fixes #849. More context in https://b.corp.google.com/issues/291810618.
|
It looks like we also need to patch the CCID Driver accordingly, because apparently it's doing null dereferences in some cases (which sometimes happen to work, but sometimes cause crashes). |
emaxx-google
added a commit
that referenced
this issue
Jul 26, 2023
Cherry-pick the "Check num_altsetting before dereffing altsetting" commit in the CCID Driver repository. This is supposed to fix the occasional crashes we observe after applying the mitigation from #849.
emaxx-google
added a commit
that referenced
this issue
Jul 26, 2023
Cherry-pick the "Check num_altsetting before dereffing altsetting" commit in the CCID Driver repository. This is supposed to fix the occasional crashes we observe after applying the mitigation from #849.
This was referenced Jul 26, 2023
emaxx-google
added a commit
that referenced
this issue
Jul 27, 2023
Cherry-pick the "Check num_altsetting before dereffing altsetting" commit in the CCID Driver repository. This is supposed to fix the occasional crashes we observe after applying the mitigation from #849.
emaxx-google
added a commit
that referenced
this issue
Jul 27, 2023
Cherry-pick the "Check num_altsetting before dereffing altsetting" commit in the CCID Driver repository. This is supposed to fix the occasional crashes we observe after applying the mitigation from #849.
emaxx-google
added a commit
that referenced
this issue
Jul 27, 2023
Add a new test for the Smart Card Connector's PC/SC implementation that's parameterized by the simulated reader type. This lets us test some basic scenarios work correctly for a range of different devices. This is a regression test for #849, because one of the simulated devices used by the new test has the smart card interface number greater than zero.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We received a bug report about broken support of a Rocketek reader:
The investigation showed it's because of behavior change in ChromeOS 105, in which permission_broker started disallowing
openDevicecalls for already-claimed composite devices. In combination with our heuristic "if opening fails, simulate that the device reappears under a different bus number later", we essentially enter a never-ending loop: "initialize smart card USB interface => try opening the device again for another interface => react to the error by aborting opened connections => back to the initial step".More details at https://b.corp.google.com/issues/291810618.
The text was updated successfully, but these errors were encountered: