[Pcsclite-muscle] CCID handling of multiple devices

Maksim Ivanov emaxx
Wed Apr 20 09:57:49 PDT 2016


Hello,

Looking at the CCID source code, it seems that there may be some
problems with working with multiple readers simultaneously.

The CCID reader polling code (or, to be precise, its libusb-based
version) is based on the libusb_handle_events function:
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/CCID.git;a=blob;f=src/ccid_usb.c;h=6a097eadb821ebed39eefac6c4b39b3f8f135001#l1252

The problem with this function is that, as it's documented in libusb
docs, it's prone to race conditions:
http://libusb.sourceforge.net/api-1.0/mtasync.html#Using

Seems that the races are pretty likely to occur when there are two or
more readers operated simultaneously. For each of them, a thread with
a polling transfer is created by the CCID driver; each thread is
blocked on libusb_handle_events most of its time. The first type of
race may happen between checking the "completed" variable and calling
the libusb_handle_events function: another thread with the running
libusb_handle_events function may finish this transfer during this
period of time. The second type of race roots from the fact that there
is no guarantee which thread's libusb_handle_event will catch the
events, so it may be that one polling thread misses the transfer
completion it's waiting for.

Even though the races, when they occur, result in just 60 seconds
delay, it would be great if they would be omitted completely.
The fix shouldn't be difficult, based on the handy function
libusb_handle_events_completed, which appears to be solving exactly
this problem:
http://libusb.sourceforge.net/api-1.0/group__poll.html#ga0bc99f39e4cf5ad393cd5936c36037d1


Thanks,
Maksim




More information about the pcsclite-muscle mailing list