[Pcsclite-muscle] Race condition during readerstate update

[Ludovic Rousseau]

Le ven. 28 août 2020 à 13:41, Marc Kewitz
<Marc.Kewitz.ext at rohde-schwarz.com> a écrit :
>
> Hi,

Hello Marc,

> I need your advice/help on an issue. I will try to explain the general setup first and then the issue.
>
> We have a SOC running linux. This SOC is connected to another processor via usb. This processor is handling the smartcard ( and also other things ). Our software is running on the SOC using the pcsc-lite lib to communicate with the pcscd which communicates with the processor/smartcard. They are communicating via the ccid T1 protocol using the CCID driver lib on the SOC. We have 2 slots for this smartcard reader.
>
> Now to the issue. We are regularly sending requests ( PC_to_RDR_XfrBlock ) to the smartcard to get random data. If someone pulls the smartcard during those requests, the request obviously fails. If that happens, the processor checks if the smartcard is still available ( in this case not ) and sends RDR_to_PC_NotifySlotChange via the interrupt channel back to the pcscd. After that the processor sends the answer RDR_to_PC_DataBlock with an error code.
> This all works fine and we receive the notifyslotchange as well as the datablock answer.
> As soon as our software on the SOC realizes that the request failed, it sends an SCardStatus request to the pcscd to check if the card is still available. Now the issue is that the readerStates that the pcscd receives in getReaderStates ( ) have not been updated yet and we see that smartcard as available although it is not.
>
> It seems like the handling of interrupts in the ccid driver, Multi_PollingProc and Multi_InterruptRead, is too slow as I can see the reception of the RDR_to_PC_DataBlock answer and the following SCardStatus request before I see the InterruptRead return in the pcscd. The readerState update in EHStatusHandlerThread is consequently only happening after the SCardStatus request.
>
> Did anyone ever come across this issue? I really want to avoid touching pcscd-lite. My first idea was to get the smartcard status via IFDStatusICC ( )/GetSlotStatus in SCardStatus. This also works and solves the problem, but I'd like to not mess with the pcsc-lite code. I also don't see delaying the SCardStatus call in the software running on the SOC as a viable solution as a sleep or similar is only concealing the actual problem.

Can you send a pcscd log as documented at https://pcsclite.apdu.fr/#support

Thanks

-- 
 Dr. Ludovic Rousseau