[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensc-devel
Subject:    Re: [Opensc-devel] Question about multiple applications
From:       Douglas E Engert <deengert () gmail ! com>
Date:       2018-12-30 13:04:22
Message-ID: a384a2fa-05d5-565d-3c11-aa27f8d47652 () gmail ! com
[Download RAW message or body]

My interpretation was A initialized the card, but B did not realize that happened.
so A needs to force a reset when the initializing is complete.

As you point out B could have interfered with the initialization if A did not hold
the lock while doing all the initialization steps to keep B from interfering.

With out some logs (and it sounds like he is writing a new diver) it is hard to say.


On 12/29/2018 6:35 PM, Frank Morgner wrote:
> We don't need to share a mutex across processes, because we don't share
> contexts across the process boundaries. Consequently, when initializing
> the card in process A with a PIN, that PIN doesn't show up in the
> sc_pkcs15_card_t object of process B if the card was already visible for
> B. You should never be able to use the newly initialized card in B
> (without calling C_Finalize()/C_Initialize()).
> 
> However, calling C_WaitForSlotEvent() and C_GetTokenInfo() from B should
> not interfere with A initializing the card. This may be a bug within
> OpenSC.  You should check in the logs which APDUs B actually sends while
> A is initializing.
> 
> In general, locking in PC/SC should be done based on the command that's
> issued to avoid interference (sc_lock()/sc_unlock()), which is why A
> should not be interrupted during pkcs15_initialize() or
> pkcs15_init_pin().  Whether or not unpowering the card is useful or
> harming, depends on the card.
> 
> If you want to get more details, send the logs and show your code.
> 

-- 

  Douglas E. Engert  <DEEngert@gmail.com>



_______________________________________________
Opensc-devel mailing list
Opensc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensc-devel
[prev in list] [next in list] [prev in thread] [next in thread]