Re: Question about multiple applications

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  <[email protected]>