Although on-card software should be designed so that it always restarts
cleanly if a card is closed down by removing power (i.e. restarts with a
cold reset), using warm reset (telling the card reader to just take the
card reset line low and then high again) from the situation where a card
is running an application program is not a good idea. Some years ago I
had someone analyse ISO/IEC 7816 to tease out the state diagram around
both cold and warm reset, and he discovered that the state diagram was
not closed when a warm reset occurs with the card running application
code - i.e. the resulting state of the card after the reset line goes
high again was not defined in 7816. If you do a reset across the contact
interface, it ought to be a cold reset (i.e. completely close down the
card) - but that could take quite a long time. As for contactless, I
don't think that 14443 is explicit here, simply assuming that a 'reset'
must be a cold reset (turning off the power field coming out of the
reader) - but beware of a conflict when there is more than one card in
the field and anti-collision has put all but the one that you want to
use in the suspended state.
Peter
Timothy J. Miller wrote:
Attached is a proposed fix against 1.1.5 to the problem of closing
sessions after logout.
The key of the problem is that when a token doesn't support
MSCLogoutAll() (like the CAC), the card is reset instead. When closing
the session, closeSessionLocked() calls slot_TokenChanged() which sees
the reset and calls slot_Disconnect(), which calls slot_FreeSession(),
which deletes the session. slot_TokenChanged returns 0, since it
succeeded, but then closeSessionLocked() calls session_FreeSession()
again. The bug is that the first session_FreeSession() already called
free() on the session pointer held by closeSessionLocked(), so we segfault.
What I did was to insert an extra condition before the second
session_FreeSession() call. This condition looks for a token change,
and skips session_FreeSession() if it sees one. The logic here is that
if the token has reset or moved, then the sessions have already been
closed so there's no need to do so again.
Would someone please sanity-check this for me? Also, is there an
official channel for submitting patches?
This works for the particular error I was first seeing. However, I'm
now seeing the same error occur through another pathway. I've another
piece of code that calls C_GetSlotList() after C_Logout(), and it
crashes during session_FreeSession(). This bit o' code is Java,
however, so I've not fully debugged it, and I think the problem here is
that he shouldn't be logging out of the card at that point.
However, I do think that there is generally inadequate handling of a
reset result of a logout event. Anyone have any input?
-- Tim
------------------------------------------------------------------------
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
