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

[helpcrypto helpcrypto]

On Wed, Sep 17, 2014 at 2:34 PM, Sebastien Lorquet <sebastien at lorquet.fr>
wrote:

> 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

Not true if timeout = INFINITE


> , 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.
>
I have seen
    while(1){
        SCardConnect(exclusive)...
    }
in some smartcard applications. Thats EVIL! xD


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?
> >
>
To let application B know someone else is using the resource, and even
query the system if the resource is abandonded or still in use.



> >> 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.
>
What locking system are you using? Flock? Mutex?
Can you link any source where using it? I'm very interested in this!



> >> 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.
>
Sure!


I just wanted just to know your opinion about this.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20140917/68969dab/attachment-0001.html>