Apparently the new Gemplus driver for GemPC410 atleast does not work
as expected.
I have done quite a bit of debugging on the problem but have been
unable to locate the real culprit. It would seem to be in the driver,
but might be in the pcscd side.
The problem is that the pcscd dies from a segmentation fault every
time a card is inserted.
I will put here a transcript outputted by the gemcore driver:
---------------------------------------------------------------------------
IFD_Handler: IO_Create_Channel called, iPort=2
Opening Device /dev/ttyS1, handle=1
G_SerPortOpenCalled
G_SerPortOpenCalled-checked resp
Come after G_GBPOpen
Actual Cmd : 0x42 0x0 0x5 0x22 0x5 0x3f 0xe0 0xd 0xb2
In Or3 Comm Opn: resp=-201
Actual Cmd : 0x42 0x40 0x5 0x22 0x5 0x3f 0xe0 0xd 0xf2
GBP Resp=0: 0x24 0x82 0x0 0xa6
Actual Cmd : 0x42 0x0 0x5 0x22 0x5 0x3f 0xe0 0xd 0xb2
GBP Resp=0: 0x24 0x0 0xe 0x0 0x47 0x65 0x6d 0x43 0x6f 0x72 0x65 0x2d 0x52 0x31 0x2e
0x32 0x31 0x3d
In Or3 Comm Opn: resp=0
Actual Cmd : 0x42 0x40 0x5 0x22 0x5 0x3f 0xe0 0x10 0xef
GBP Resp=0: 0x24 0x40 0x11 0x0 0x47 0x65 0x6d 0x43 0x6f 0x72 0x65 0x2d 0x52 0x31 0x2e
0x32 0x31 0x2d 0x47 0x4d 0x45
OS String : GemCore-R1.21-GM}
Actual Cmd : 0x42 0x0 0x3 0x1 0x0 0x0 0x40
GBP Resp=0: 0x24 0x0 0x1 0x1 0x24
Vendor Name = Gemplus
IFD Type = Gemcore Based Reader
IFD Version = 0x2000001
IFD Serial = Gemcore Serial No. Not used
IFD Channel ID = 0x%04
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x40 0x1 0x17 0x14
GBP Resp=0: 0x24 0x40 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x65
IFD_Get_Capablities
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x0 0x1 0x17 0x54
GBP Resp=0: 0x24 0x0 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x25
IFD_Handler: Returning ATR=0
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x40 0x1 0x17 0x14
GBP Resp=0: 0x24 0x40 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x65
IFD_Get_Capablities
IFD_Get_Capablities
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x0 0x1 0x17 0x54
GBP Resp=0: 0x24 0x0 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x25
IFD_Handler: Returning ATR=0
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x40 0x1 0x17 0x14
GBP Resp=0: 0x24 0x40 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x65
IFD_Get_Capablities
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x0 0x1 0x17 0x54
GBP Resp=0: 0x24 0x0 0x7 0x0 0x4 0x2 0x0 0x0 0x0 0x0 0x25
IFD_Handler: Returning ATR=0
IFD_Power_ICC: IFD_PowerUP_ICC.
Actual Cmd : 0x42 0x40 0x1 0x11 0x12
GBP Resp=0: 0x24 0x40 0x1 0x0 0x65
Actual Cmd : 0x42 0x0 0x2 0x12 0x13 0x41
GBP Resp=0: 0x24 0x0 0x13 0x0 0x3b 0x1f 0x11 0x80 0x6a 0x20 0x36 0x46 0x49 0x53 0x45
0x12 0x8c 0x2 0xff 0x7 0x90 0x0 0x13
IFD_Is_ICC_Present running
Actual Cmd : 0x42 0x40 0x1 0x17 0x14
GBP Resp=0: 0x24 0x40 0x7 0x0 0x6 0x2 0x11 0x0 0xa 0x0 0x7c
---------------------------------------------------------------------------
When it detects the card, it powers up the ICC, and upon return it
crashes. Actually, when looking at the backtraces, The
IFD_Is_ICC_Present function works fine, returns that the ICC is
powered on and present, but when it returns from the gemcore driver,
the return address is out of addressable space.
So, the backtrace from gdb when a card is not yet inserted and
IFD_Is_ICC_Present is called (just for reference):
---------------------------------------------------------------------------
(gdb) bt
#0 IFD_Is_ICC_Present () at ifdhandler.c:1189
#1 0x0804d703 in IFDStatusICC (rContext=0x8057db8, pdwStatus=0xbf7ffb2c,
pdwProtocol=0xbf7ffb30, pucAtr=0x8057f68 "ate /tmp/pcsc: File exists\n",
pdwAtrLen=0x8057f8c) at ifdwrapper.c:463
#2 0x08052733 in EHStatusHandlerThread (rContext=0x8057db8)
at eventhandler.c:254
#3 0x4002be85 in pthread_start_thread () from /lib/libpthread.so.0
---------------------------------------------------------------------------
Then by stepping I went to just before calling IFD_Power_ICC:
---------------------------------------------------------------------------
(gdb) bt
#0 IFDPowerICC (rContext=0x8057db8, dwAction=500, pucAtr=0x8057f68 "",
pdwAtrLen=0x8057f8c) at ifdwrapper.c:374
#1 0x080528f8 in EHStatusHandlerThread (rContext=0x8057db8)
at eventhandler.c:346
#2 0x4002be85 in pthread_start_thread () from /lib/libpthread.so.0
---------------------------------------------------------------------------
Then there's the setting of the IFD_power_icc variable:
---------------------------------------------------------------------------
365 IFD_power_icc = (RESPONSECODE(*)(DWORD)) vFunction;
(gdb) print IFD_power_icc
$1 = (RESPONSECODE (*)()) 0x40167f88 <IFD_Power_ICC>
---------------------------------------------------------------------------
And then a longer transcript about the actual commands:
---------------------------------------------------------------------------
(gdb)
381 rv = (*IFD_power_icc)(dwAction);
(gdb) bt
#0 IFDPowerICC (rContext=0x8057db8, dwAction=500, pucAtr=0x8057f68 "",
pdwAtrLen=0x8057f8c) at ifdwrapper.c:381
#1 0x080528f8 in EHStatusHandlerThread (rContext=0x8057db8)
at eventhandler.c:346
#2 0x4002be85 in pthread_start_thread () from /lib/libpthread.so.0
(gdb) n
Breakpoint 1, IFD_Is_ICC_Present () at ifdhandler.c:1189
1189 WORD8 cmd[2] = { HOR3GLL_IFD_CMD_ICC_STATUS };
(gdb) bt
#0 IFD_Is_ICC_Present () at ifdhandler.c:1189
#1 0x40168142 in IFD_Power_ICC (ActionRequested=2953315541)
at ifdhandler.c:768
#2 0x05000000 in ?? ()
Cannot access memory at address 0x2108057f
---------------------------------------------------------------------------
So, to say it in words, when it calls the IFD_Power_ICC, the function
return pointer in the stack is incorrect. And it baffles me why.
I tested this with 0.9.3 and 1.0.0B.
[Time passes]
Actually, it breaks in IFD_Power_ICC - the first G_Oros3IccPowerDown
call fucks up the stack. So it definitely would seem to be in the driver.
Anyway, if anyone knows what's going on, I'd be delighted to hear.
-- Naked
***************************************************************
Unix Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/
To unsubscribe send an email to [EMAIL PROTECTED] with
unsubscribe sclinux
***************************************************************
