[Pcsclite-muscle] About SHARED/EXCLUSIVE and starvation Was: Portable way to detect when a smart card is inserted

[Sebastien Lorquet]

Hello,

The evil process might block access to the reader, but in that case, the
legitimate process will likely timeout while waiting for the card, and this can
be the occasion to ask the user to "remove and reinsert" the card, which may
help the legitimate process to gain access to the card.

The evil process can still try transactions in a loop, so my idea does not
guarantee that the legitimate process will access the card in presence of an
attacker.

However common situations do not involve really "evil" processes, but rather
daemons that forget to release the card, so the "remove/reinsert" trick does help.

S?bastien Lorquet

Le 17/09/2014 14:23, Ludovic Rousseau a ?crit :
> 2014-09-17 11:58 GMT+02:00 helpcrypto helpcrypto <helpcrypto at gmail.com>:
>> On Mon, Sep 15, 2014 at 6:43 PM, Ludovic Rousseau
>> <ludovic.rousseau at gmail.com> wrote:
>>>
>>>
>>> Please, please do NOT use a loop of proposed by Bruno Jesus.
>>> I invested a lot of time in removing all polling loops in pcsc-lite
>>> and the CCID driver. So please do not add a polling loop in your
>>> application when you can do without one.
>>
>>
>> Talking about this, Ludovic, I'll like to ask you:
>>
>> IIUC, using SHARED + BeginTransaction/EndTransaction could lead to
>> starvation:
>>
>> Process A opens a shared connection and invokes beginTransaction
>> Process B opens a shared connection and invokes beginTransaction (blocked)
>> If evil process A never releases transaction, B will starve
> 
> Yes. This is the expected behaviour.
> 
>> A "complex" father-child process will be needed to detect if process B is
>> being blocked to be able to resume, right?
> 
> To resume what?
> 
>> Using EXCLUSIVE with retry-loop seems to be better:
>> Process A opens an exclusive connection
>> Process B try to open an exclusive connection and fails (now it is aware of
>> other process using SC)
>>     process B could retry a few times, or even detect if its a deadlock
>> (process A died before releasing the connection)
>> Am I right?
> 
> No.
> If A dies then the lock will be released automatically. If that does
> not occur then it is a bug in pcsc-lite and you should report it.
> 
>> Said so: are exclusive connections better in a non-controlled/evil
>> applications environment?
> 
> It is the application choice to share or not the reader.
> 
> Once application A (evil or not) has an exclusive access to the reader
> then application B can just wait.
> 
> PC/SC has not been designed to give a fair access to the smart card to
> all the running applications.
> 
> Bye
>