C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
I'm fixing pkcs11-helper to support RFC7512 URIs, but I'm having
difficulty testing it even before I make any changes.

I'm using a Yubikey NEO.

I'm getting this failure when testing with OpenVPN (which uses
pkcs11-helper):

Enter PIV_II (PIV Card Holder pin) token Password:

27: C_Login
2015-04-30 22:23:36.592
[in] hSession = 0x143ffb0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 00007ffcd447d0e0 / 4
    00000000  66 69 73 68                                      fish            
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:259:C_Login: C_Login(0x143ffb0, 1)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:279:C_Login: C_Login() slot->login_user 4294967295
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:288:C_Login: C_Login() userType 1
0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1414:pkcs15_login: pkcs15-login: userType 0x1, PIN length 4
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(type:0;method:1;len:)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] card.c:325:sc_lock: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:517:pcsc_lock: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:544:pcsc_lock: Yubico Yubikey NEO OTP+CCID 00 00:SCardBeginTransaction failed: 0x8010001d
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:356:sc_pkcs15_verify_pin: sc_lock() failed: -1101 (No readers found)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1528:pkcs15_login: PKCS15 verify PIN returned -1101
0x7fa848020800 22:23:36.592 [opensc-pkcs11] misc.c:61:sc_to_cryptoki_error_common: libopensc return value: -1101 (No readers found)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:290:C_Login: fLogin() rv 5
Returned:  5 CKR_GENERAL_ERROR
Thu Apr 30 22:23:36 2015 PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR'
Thu Apr 30 22:23:36 2015 OpenSSL: error:14099004:SSL routines:SSL3_SEND_CLIENT_VERIFY:RSA lib

Full output at http://david.woodhou.se/openvpn-failing.txt and pcsc-spy
log at http://david.woodhou.se/pcsc-spy.txt 


--
dwmw2


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Ludovic Rousseau
2015-05-01 0:10 GMT+02:00 David Woodhouse <[hidden email]>:

> I'm fixing pkcs11-helper to support RFC7512 URIs, but I'm having
> difficulty testing it even before I make any changes.
>
> I'm using a Yubikey NEO.
>
> I'm getting this failure when testing with OpenVPN (which uses
> pkcs11-helper):
>
> Enter PIV_II (PIV Card Holder pin) token Password:
>
> 27: C_Login
> 2015-04-30 22:23:36.592
> [in] hSession = 0x143ffb0
> [in] userType = CKU_USER
> [in] pPin[ulPinLen] 00007ffcd447d0e0 / 4
>     00000000  66 69 73 68                                      fish
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:259:C_Login: C_Login(0x143ffb0, 1)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:279:C_Login: C_Login() slot->login_user 4294967295
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:288:C_Login: C_Login() userType 1
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1414:pkcs15_login: pkcs15-login: userType 0x1, PIN length 4
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(type:0;method:1;len:)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] card.c:325:sc_lock: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:517:pcsc_lock: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:544:pcsc_lock: Yubico Yubikey NEO OTP+CCID 00 00:SCardBeginTransaction failed: 0x8010001d
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:356:sc_pkcs15_verify_pin: sc_lock() failed: -1101 (No readers found)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1528:pkcs15_login: PKCS15 verify PIN returned -1101
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] misc.c:61:sc_to_cryptoki_error_common: libopensc return value: -1101 (No readers found)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:290:C_Login: fLogin() rv 5
> Returned:  5 CKR_GENERAL_ERROR
> Thu Apr 30 22:23:36 2015 PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR'
> Thu Apr 30 22:23:36 2015 OpenSSL: error:14099004:SSL routines:SSL3_SEND_CLIENT_VERIFY:RSA lib
>
> Full output at http://david.woodhou.se/openvpn-failing.txt and pcsc-spy
> log at http://david.woodhou.se/pcsc-spy.txt

from pcsc-spy.txt:
SCardStatus
 i hCard: 0x6FCFAD34
 i pcchReaderLen 0x00000000 (0)
 i pcbAtrLen 0x00000021 (33)
 o cchReaderLen 0x00000000 (0)
 o mszReaderName NULL
 o dwState 0x00000000 (0)
 o dwProtocol 0x00000000 (0)
 o bAtrLen 0x00000000 (0)
 o bAtr
 => RPC transport error. (SCARD_F_COMM_ERROR [0x80100013])  [0.000000097]
SCardGetStatusChange
 i hContext: 0x647ADCA1
 i dwTimeout: 0x00000000 (0)
 i cReaders: 1
 i szReader: Yubico Yubikey NEO OTP+CCID 00 00
 i  dwCurrentState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 i  dwEventState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 i  Atr length: 0x00000014 (20)
 i  Atr: 3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
 o szReader: Yubico Yubikey NEO OTP+CCID 00 00
 o  dwCurrentState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 o  dwEventState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 o  Atr length: 0x00000014 (20)
 o  Atr: 3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
 => Service not available. (SCARD_E_NO_SERVICE [0x8010001D])  [0.000000046]

It looks like pcscd has crashed and is no more responding.

Can you also generate pcscd log as described in
https://pcsclite.alioth.debian.org/ccid.html#support

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
>
> It looks like pcscd has crashed and is no more responding.

It hasn't. It's working fine and continues to happily service
requests, for example the immediately subsequent run of OpenConnect
(built with OpenSSL+libp11) which works fine:
 http://david.woodhou.se/openconnect-working.txt


> Can you also generate pcscd log as described in
> https://pcsclite.alioth.debian.org/ccid.html#support

http://david.woodhou.se/pcsc-debug.txt along with newly-generated
http://david.woodhou.se/openvpn-fail-2.txt

--
dwmw2

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Fri, 2015-05-01 at 13:47 +0100, David Woodhouse wrote:

> On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
> >
> > It looks like pcscd has crashed and is no more responding.
>
> It hasn't. It's working fine and continues to happily service
> requests, for example the immediately subsequent run of OpenConnect
> (built with OpenSSL+libp11) which works fine:
>  http://david.woodhou.se/openconnect-working.txt
>
>
> > Can you also generate pcscd log as described in
> > https://pcsclite.alioth.debian.org/ccid.html#support
>
> http://david.woodhou.se/pcsc-debug.txt along with newly-generated
> http://david.woodhou.se/openvpn-fail-2.txt
I note pcscd thinks there are two clients. I wonder if this is related
to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
circumstances:
 https://bugzilla.redhat.com/show_bug.cgi?id=1135932


--
dwmw2

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Ludovic Rousseau
2015-05-01 15:00 GMT+02:00 David Woodhouse <[hidden email]>:

> On Fri, 2015-05-01 at 13:47 +0100, David Woodhouse wrote:
>> On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
>> >
>> > It looks like pcscd has crashed and is no more responding.
>>
>> It hasn't. It's working fine and continues to happily service
>> requests, for example the immediately subsequent run of OpenConnect
>> (built with OpenSSL+libp11) which works fine:
>>  http://david.woodhou.se/openconnect-working.txt
>>
>>
>> > Can you also generate pcscd log as described in
>> > https://pcsclite.alioth.debian.org/ccid.html#support
>>
>> http://david.woodhou.se/pcsc-debug.txt along with newly-generated
>> http://david.woodhou.se/openvpn-fail-2.txt
>
> I note pcscd thinks there are two clients. I wonder if this is related
> to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
> circumstances:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1135932

That may be the problem.

>From the pcscd log file:
00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Fri, 2015-05-01 at 18:58 +0200, Ludovic Rousseau wrote:

>
> > I note pcscd thinks there are two clients. I wonder if this is related
> > to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
> > circumstances:
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1135932
>
> That may be the problem.
>
> From the pcscd log file:
> 00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle
So... where does the bug lie?

On fork, the pkcs11-helper library will call C_Initialize() in the
child for each provider module which was already active in the parent.

Is that expected to work? It doesn't seem to — it causes this issue
with the OpenSC PKCS#11 module, and it causes p11-kit-proxy.so to
deadlock¹.

The cheap solution for now might be to avoid the whole question and
use vfork() instead of fork() in OpenVPN for these cases. It's only
fork-and-exec anyway. But it does want to be fixed properly, whatever
the 'fix' should be.

--
dwmw2
¹ https://www.mail-archive.com/p11-glue@.../msg00126.html
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Fri, 2015-05-01 at 18:54 +0100, David Woodhouse wrote:

> On Fri, 2015-05-01 at 18:58 +0200, Ludovic Rousseau wrote:
> >
> > > I note pcscd thinks there are two clients. I wonder if this is related
> > > to the pkcs11_helper behaviour at fork() that causes OpenVPN to
> > > deadlock in a number of other circumstances:
> > >  https://bugzilla.redhat.com/show_bug.cgi?id=1135932
> >
> > That may be the problem.
> >
> > From the pcscd log file:
> > 00000007 winscard_svc.c:944:MSGCheckHandleAssociation()
> > Invalidated handle
>
> So... where does the bug lie?
>
> On fork, the pkcs11-helper library will call C_Initialize() in the
> child for each provider module which was already active in the
> parent.
>
> Is that expected to work? It doesn't seem to — it causes this issue
> with the OpenSC PKCS#11 module, and it causes p11-kit-proxy.so to
> deadlock¹.
>
> The cheap solution for now might be to avoid the whole question and
> use vfork() instead of fork() in OpenVPN for these cases. It's only
> fork-and-exec anyway. But it does want to be fixed properly, whatever
> the 'fix' should be.
FWIW this *is* valid behaviour from pkcs11-helper. It's recommended by
the PKCS#11 specification. See §2.5.2 of the Usage Guide¹ at
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406759987
and in particular the part which says:

"In the scenario specified above, C should actually call C_Initialize
whether or not it needs to use Cryptoki if it has no need to use
Cryptoki, it should then call C_Finalize immediately thereafter.  This
(having the child immediately call C_Initialize and then call
C_Finalize if the parent is using Cryptoki) is considered to be good
Cryptoki programming practice, since it can prevent the existence of
dangling duplicate resources that were created at the time of the
fork() call; however, it is not required by Cryptoki."

So the problem here is either in OpenSC or PC/SC. Probably the former
— perhaps OpenSC should be discarding (closing?) any existing file handles on getting the new C_Initialize()
call?

--
dwmw2

¹ Thanks to Alon for pointing me at that.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Sat, 2015-05-02 at 00:51 +0100, David Woodhouse wrote:
> So the problem here is either in OpenSC or PC/SC. Probably the former
> — perhaps OpenSC should be discarding (closing?) any existing file
> handles on getting the new C_Initialize() call?

Here's a test case. I've verified that it fails with OpenSC with both
a PIV device (Yubikey NEO) and a Feitian ePass PKI token:

$   PKCS11SPY=/usr/lib64/pkcs11/opensc-pkcs11.so ./p11fork


*************** OpenSC PKCS#11 spy *****************
Loaded: "/usr/lib64/pkcs11/opensc-pkcs11.so"

0: C_GetFunctionList
2015-05-05 23:12:52.608
Returned:  0 CKR_OK

1: C_Initialize
2015-05-05 23:12:52.609
[in] pInitArgs = (nil)
Returned:  0 CKR_OK

2: C_GetSlotList
2015-05-05 23:12:53.134
[in] tokenPresent = 0x0
[out] pSlotList:
Slot 0
Slot 1
[out] *pulCount = 0x2
Returned:  0 CKR_OK

3: C_GetSlotInfo
2015-05-05 23:12:54.723
[in] slotID = 0x0
[out] pInfo:
      slotDescription:        'Virtual hotplug slot            '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   6
        CKF_REMOVABLE_DEVICE            
        CKF_HW_SLOT                      
Returned:  0 CKR_OK
Slot 0: 'Virtual hotplug slot                                            ' 'OpenSC (www.opensc-project.org) '

4: C_GetSlotInfo
2015-05-05 23:12:54.723
[in] slotID = 0x1
[out] pInfo:
      slotDescription:        'Feitian SCR301 00 00            '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE            
        CKF_HW_SLOT                      
Returned:  0 CKR_OK
Slot 1: 'Feitian SCR301 00 00                                            ' 'OpenSC (www.opensc-project.org) '

5: C_Initialize
2015-05-05 23:12:54.724
[in] pInitArgs = (nil)
Returned:  0 CKR_OK
Child done. 0

5: C_OpenSession
2015-05-05 23:12:54.845
[in] slotID = 0x1
[in] flags = 0x4
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x21dada0
Returned:  0 CKR_OK

6: C_Login
2015-05-05 23:12:54.845
[in] hSession = 0x21dada0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 0000000000400b5d / 4
    00000000  30 30 30 30                                      0000            
Returned:  5 CKR_GENERAL_ERROR
C_Login failed 5

--
dwmw2


/*
  gcc -I/usr/include/p11-kit-1 /usr/lib64/pkcs11-spy.so -o p11fork p11fork.c
  PKCS11SPY=/usr/lib64/pkcs11/opensc-pkcs11.so ./p11fork
*/
#include <p11-kit/pkcs11.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
        CK_RV rv;
        CK_FUNCTION_LIST_PTR funcs;
        pid_t pid;
        int st;
        CK_SLOT_ID slots[100];
        CK_ULONG nslots;
        CK_SESSION_HANDLE sess;
        int i;

        rv = C_GetFunctionList(&funcs);
        if (rv != CKR_OK) {
                printf("Failed to get PKCS#11 function list\n");
                exit(1);
        }

        rv = funcs->C_Initialize(NULL);
        if (rv != CKR_OK) {
                printf("Failed to initialize module\n");
                exit(1);
        }
        rv = funcs->C_GetSlotList(FALSE, slots, &nslots);
        for (i=0; i < nslots; i++) {
                CK_SLOT_INFO info;
                funcs->C_GetSlotInfo(slots[i], &info);
                printf("Slot %d: '%64.64s' '%32.32s'\n", i, info.slotDescription, info.manufacturerID);
        }
        pid = fork();
        if (!pid) {
                /* See §2.5.2 of the PKCS#11 Usage Guide:
                 * http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406759987
                 * Calling C_Initialize() in the child after fork is "considered to
                 * be good Cryptoki programming practice, since it can prevent the
                 * existence of dangling duplicate resources that were created at
                 * the time of the fork() call". */
                if (1) {
                        rv = funcs->C_Initialize(NULL);
                        if (rv != CKR_OK) {
                                printf("Failed to re-initialize module in child\n");
                                exit(1);
                        }
                }
                exit(0);
        } else if (pid < 0) {
                perror("Fork failed");
                exit(1);
        }
        waitpid(pid, &st, 0);

        printf("Child done. %d\n", st);

        rv = funcs->C_OpenSession(1, CKF_SERIAL_SESSION, NULL, NULL, &sess);
        if (rv != CKR_OK) {
                printf("C_OpenSession failed %d\n", rv);
                exit(1);
        }
        rv = funcs->C_Login(sess, CKU_USER, "0000", 4);
        if (rv != CKR_OK) {
                printf("C_Login failed %d\n", rv);
                exit(1);
        }
        return st;
}

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

David Woodhouse
On Tue, 2015-05-05 at 23:15 +0100, David Woodhouse wrote:
>
> Here's a test case. I've verified that it fails with OpenSC with both
> a PIV device (Yubikey NEO) and a Feitian ePass PKI token:

And this "fixes" it, although obviously it's more of a proof of
concept than something we could apply as-is:

Are our file descriptors all opened with O_CLOEXEC, btw?

diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
index aa50758..c304825 100644
--- a/src/pkcs11/pkcs11-global.c
+++ b/src/pkcs11/pkcs11-global.c
@@ -204,8 +204,29 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
 
        /* Handle fork() exception */
 #if !defined(_WIN32)
-       if (current_pid != initialized_pid) {
-               C_Finalize(NULL_PTR);
+       if (context != NULL && current_pid != initialized_pid) {
+               void *p;
+               sc_pkcs11_slot_t *slot;
+
+               rv = sc_pkcs11_lock();
+               if (rv != CKR_OK)
+                       return rv;
+
+               /* We cannot touch the PC/SC context since it
+                * belongs to the parent process. FIXME: For now
+                * just leak it */
+               context = NULL;
+
+               while ((p = list_fetch(&sessions)))
+                       free(p);
+               list_destroy(&sessions);
+
+               while ((slot = list_fetch(&virtual_slots))) {
+                       list_destroy(&slot->objects);
+                       free(slot);
+               }
+               list_destroy(&virtual_slots);
+               sc_pkcs11_free_lock();
        }
        initialized_pid = current_pid;
        in_finalize = 0;

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Nikos Mavrogiannopoulos-2
On Wed, May 6, 2015 at 1:37 AM, David Woodhouse <[hidden email]> wrote:
>> Here's a test case. I've verified that it fails with OpenSC with both
>> a PIV device (Yubikey NEO) and a Feitian ePass PKI token:
> And this "fixes" it, although obviously it's more of a proof of
> concept than something we could apply as-is:

The issue is quite complex because shared resources are not
distinguished to per-process resources. I've attempted to solve it at
the C_Finalize() function with the following pull request:
https://github.com/OpenSC/OpenSC/pull/493

regards,
Nikos

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Frank Morgner
I think we have two problems here:

1. The only thing we should do is freeing the memory which gets copied
   into the child's address space. And that's where I think we have a
   problem in pcsc-lite:

   I don't know the inner workings of pcsc-lite but I suppose when
   calling SCardEstablishContext there will be some memory that can only
   be free'd by calling SCardReleaseContext. This memory will exist in
   the parent's and in the child's address space. But with David's log
   it looks like pcsc-lite has a sanity check that disallows freeing the
   same handle twice in SCardReleaseContext.

2. We should not perform any "terminating" actions on the card when
   detecting a fork. This card belongs to the parent process and we
   should not touch it. That means that calling C_Finalize from
   C_Initialize as currently implemented is not correct.

   In that regard your changes, Nikos, look good, though I'd prefer
   something like `sc_terminate_context` instead of
   `sc_release_context_after_fork`. This would put the focus on the
   desired action (destroy the memory NOW instead of doing some
   additional magic) instead of the circumstances (being called after
   fork). This would raise readability/maintainability, I think.
   However, your current patch still leaks gpriv in reader-pcsc.c
   (because finish is not called).

Right?

Am Freitag, dem 03. Juli, um 10:10 Uhr schrieb Nikos Mavrogiannopoulos:

> On Wed, May 6, 2015 at 1:37 AM, David Woodhouse <[hidden email]> wrote:
> >> Here's a test case. I've verified that it fails with OpenSC with both
> >> a PIV device (Yubikey NEO) and a Feitian ePass PKI token:
> > And this "fixes" it, although obviously it's more of a proof of
> > concept than something we could apply as-is:
>
> The issue is quite complex because shared resources are not
> distinguished to per-process resources. I've attempted to solve it at
> the C_Finalize() function with the following pull request:
> https://github.com/OpenSC/OpenSC/pull/493
>
> regards,
> Nikos
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Ludovic Rousseau
2015-07-06 2:07 GMT+02:00 Frank Morgner <[hidden email]>:

> I think we have two problems here:
>
> 1. The only thing we should do is freeing the memory which gets copied
>    into the child's address space. And that's where I think we have a
>    problem in pcsc-lite:
>
>    I don't know the inner workings of pcsc-lite but I suppose when
>    calling SCardEstablishContext there will be some memory that can only
>    be free'd by calling SCardReleaseContext. This memory will exist in
>    the parent's and in the child's address space. But with David's log
>    it looks like pcsc-lite has a sanity check that disallows freeing the
>    same handle twice in SCardReleaseContext.

You are right.
pcsc-lite allocates some memory on the client side and also on the server side.
After a fork the memory on the client side is duplicated, but nothing
changes on the server side.

Calling SCardReleaseContext will release the memory on 1 client and on
the server.
A second call to SCardReleaseContext will try to free resources on the
server side but the server will then return an error (resources
already freed). The memory on the client side will then NOT be freed.

I can change the pcsc-lite code to free memory on the client side
first before asking the server to free its memory. With this change a
second call to SCardReleaseContext would still return an error but the
memory on the client would be freed.

That would solve a memory leak when fork() is used.
I created a ticket
https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Frank Morgner


Yes, this would at least resolve the memory handling. However, the second copy of the handle would still be useless though release has never been called by the second client.

Do you know how this is solved in Apple's implementation?

Am 6. Juli 2015 09:27:09 MESZ, schrieb Ludovic Rousseau <[hidden email]>:

>2015-07-06 2:07 GMT+02:00 Frank Morgner
><[hidden email]>:
>> I think we have two problems here:
>>
>> 1. The only thing we should do is freeing the memory which gets
>copied
>>    into the child's address space. And that's where I think we have a
>>    problem in pcsc-lite:
>>
>>    I don't know the inner workings of pcsc-lite but I suppose when
>>    calling SCardEstablishContext there will be some memory that can
>only
>>    be free'd by calling SCardReleaseContext. This memory will exist
>in
>>    the parent's and in the child's address space. But with David's
>log
>>    it looks like pcsc-lite has a sanity check that disallows freeing
>the
>>    same handle twice in SCardReleaseContext.
>
>You are right.
>pcsc-lite allocates some memory on the client side and also on the
>server side.
>After a fork the memory on the client side is duplicated, but nothing
>changes on the server side.
>
>Calling SCardReleaseContext will release the memory on 1 client and on
>the server.
>A second call to SCardReleaseContext will try to free resources on the
>server side but the server will then return an error (resources
>already freed). The memory on the client side will then NOT be freed.
>
>I can change the pcsc-lite code to free memory on the client side
>first before asking the server to free its memory. With this change a
>second call to SCardReleaseContext would still return an error but the
>memory on the client would be freed.
>
>That would solve a memory leak when fork() is used.
>I created a ticket
>https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085
>
>Bye
>
>--
> Dr. Ludovic Rousseau
>
>------------------------------------------------------------------------------
>Don't Limit Your Business. Reach for the Cloud.
>GigeNET's Cloud Solutions provide you with the tools and support that
>you need to offload your IT needs and focus on growing your business.
>Configured For All Businesses. Start Your Cloud Today.
>https://www.gigenetcloud.com/
>_______________________________________________
>Opensc-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/opensc-devel

--
Frank Morgner
--
Frank Morgner

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Frank Morgner
Has anybody looked at the problem on OS x 10.10 or later?

Am 6. Juli 2015 11:25:58 MESZ, schrieb Frank Morgner <[hidden email]>:


Yes, this would at least resolve the memory handling. However, the second copy of the handle would still be useless though release has never been called by the second client.

Do you know how this is solved in Apple's implementation?

Am 6. Juli 2015 09:27:09 MESZ, schrieb Ludovic Rousseau <[hidden email]>:
2015-07-06 2:07 GMT+02:00 Frank Morgner
<[hidden email]>:
I think we have two problems here:

1. The only thing we should do is freeing the memory which gets
copied
into the child! 's address space. And that's where I think we have a
problem in pcsc-lite:

I don't know the inner workings of pcsc-lite but I suppose when
calling SCardEstablishContext there will be some memory that can
only
be free'd by calling SCardReleaseContext. This memory will exist
in
the parent's and in the child's address space. But with David's
log
it looks like pcsc-lite has a sanity check that disallows freeing
the
same handle twice in SCardReleaseContext.

You are right.
pcsc-lite allocates some memory on the client side and also on the
server side.
After a fork the memory on the client side is duplicated, but nothing
changes on the server side.

Calling SCardReleaseContext will release the memory on 1 client and on
the server.
A second call to SCardReleaseContext will try to free resources on the
server side but the server will then return an error (resources
already freed). The memory on the client side will then NOT be freed.

I can change the pcsc-lite code to free memory on the client side
first before asking the server to free its memory. With this change a
second call to SCardReleaseContext would still return an error but the
memory on the client would be freed.

That would solve a memory leak when fork() is used.
I created a tickethttps://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085

Bye

--
Dr. Ludovic Rousseau



Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/


Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

--
Frank Morgner
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Nikos Mavrogiannopoulos-2
In reply to this post by Frank Morgner
On Mon, Jul 6, 2015 at 2:07 AM, Frank Morgner
<[hidden email]> wrote:

> 2. We should not perform any "terminating" actions on the card when
>    detecting a fork. This card belongs to the parent process and we
>    should not touch it. That means that calling C_Finalize from
>    C_Initialize as currently implemented is not correct.
>
>    In that regard your changes, Nikos, look good, though I'd prefer
>    something like `sc_terminate_context` instead of
>    `sc_release_context_after_fork`. This would put the focus on the
>    desired action (destroy the memory NOW instead of doing some
>    additional magic) instead of the circumstances (being called after
>    fork). This would raise readability/maintainability, I think.

I've updated the patch for that.

>    However, your current patch still leaks gpriv in reader-pcsc.c
>    (because finish is not called).

That was intentional. Calling finish after fork disables the card for
the parent. I've committed an additional patch to eliminate that leak.

regards,
Nikos

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Nikos Mavrogiannopoulos-2
On Wed, Jul 8, 2015 at 10:58 AM, Nikos Mavrogiannopoulos
<[hidden email]> wrote:
>>    In that regard your changes, Nikos, look good, though I'd prefer
>>    something like `sc_terminate_context` instead of
>>    `sc_release_context_after_fork`. This would put the focus on the
>>    desired action (destroy the memory NOW instead of doing some
>>    additional magic) instead of the circumstances (being called after
>>    fork). This would raise readability/maintainability, I think.
> I've updated the patch for that.

Hello,
 Any other comments related to that issue? Anything that blocks it
from being merged?

regards,
Nikos

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Ludovic Rousseau
In reply to this post by Ludovic Rousseau
2015-07-06 9:27 GMT+02:00 Ludovic Rousseau <[hidden email]>:

> 2015-07-06 2:07 GMT+02:00 Frank Morgner <[hidden email]>:
>> I think we have two problems here:
>>
>> 1. The only thing we should do is freeing the memory which gets copied
>>    into the child's address space. And that's where I think we have a
>>    problem in pcsc-lite:
>>
>>    I don't know the inner workings of pcsc-lite but I suppose when
>>    calling SCardEstablishContext there will be some memory that can only
>>    be free'd by calling SCardReleaseContext. This memory will exist in
>>    the parent's and in the child's address space. But with David's log
>>    it looks like pcsc-lite has a sanity check that disallows freeing the
>>    same handle twice in SCardReleaseContext.
>
> You are right.
> pcsc-lite allocates some memory on the client side and also on the server side.
> After a fork the memory on the client side is duplicated, but nothing
> changes on the server side.
>
> Calling SCardReleaseContext will release the memory on 1 client and on
> the server.
> A second call to SCardReleaseContext will try to free resources on the
> server side but the server will then return an error (resources
> already freed). The memory on the client side will then NOT be freed.
>
> I can change the pcsc-lite code to free memory on the client side
> first before asking the server to free its memory. With this change a
> second call to SCardReleaseContext would still return an error but the
> memory on the client would be freed.
>
> That would solve a memory leak when fork() is used.
> I created a ticket
> https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085

In fact I was wrong in my interpretation.

pcsc-lite will NOT fail to free the memory on the client side. The
second time SCardReleaseContext() is called it will return
SCARD_E_INVALID_VALUE but the client side memory is _also_ released.

pcsc-lite will not leak memory in this case.

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Frank Morgner
Hi!

> > pcsc-lite allocates some memory on the client side and also on the server side.
> > After a fork the memory on the client side is duplicated, but nothing
> > changes on the server side.
> >
> > Calling SCardReleaseContext will release the memory on 1 client and on
> > the server.
> > A second call to SCardReleaseContext will try to free resources on the
> > server side but the server will then return an error (resources
> > already freed). The memory on the client side will then NOT be freed.
> >
> > I can change the pcsc-lite code to free memory on the client side
> > first before asking the server to free its memory. With this change a
> > second call to SCardReleaseContext would still return an error but the
> > memory on the client would be freed.
> >
> > That would solve a memory leak when fork() is used.
> > I created a ticket
> > https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085
>
> In fact I was wrong in my interpretation.
>
> pcsc-lite will NOT fail to free the memory on the client side. The
> second time SCardReleaseContext() is called it will return
> SCARD_E_INVALID_VALUE but the client side memory is _also_ released.
>
> pcsc-lite will not leak memory in this case.
That's nice. However, it doesn't solve the problem: Since the process
which frees the handle first is the process that doesn't need the
handle. For the process that may still use its copy of the handle, the
server side is not available anymore.

When looking at file descriptors (within a process) and file
descriptions (within the kernel) the problem has been solved by not
having any additional memory in the client. A file descriptor is simply
an integer that does not need to be deallocated. Would that be an option
for PCSC-Lite?

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

Ludovic Rousseau
2015-07-28 17:20 GMT+02:00 Frank Morgner <[hidden email]>:

> Hi!
>
>> > pcsc-lite allocates some memory on the client side and also on the server side.
>> > After a fork the memory on the client side is duplicated, but nothing
>> > changes on the server side.
>> >
>> > Calling SCardReleaseContext will release the memory on 1 client and on
>> > the server.
>> > A second call to SCardReleaseContext will try to free resources on the
>> > server side but the server will then return an error (resources
>> > already freed). The memory on the client side will then NOT be freed.
>> >
>> > I can change the pcsc-lite code to free memory on the client side
>> > first before asking the server to free its memory. With this change a
>> > second call to SCardReleaseContext would still return an error but the
>> > memory on the client would be freed.
>> >
>> > That would solve a memory leak when fork() is used.
>> > I created a ticket
>> > https://alioth.debian.org/tracker/index.php?func=detail&aid=315106&group_id=30105&atid=410085
>>
>> In fact I was wrong in my interpretation.
>>
>> pcsc-lite will NOT fail to free the memory on the client side. The
>> second time SCardReleaseContext() is called it will return
>> SCARD_E_INVALID_VALUE but the client side memory is _also_ released.
>>
>> pcsc-lite will not leak memory in this case.
>
> That's nice. However, it doesn't solve the problem: Since the process
> which frees the handle first is the process that doesn't need the
> handle. For the process that may still use its copy of the handle, the
> server side is not available anymore.
>
> When looking at file descriptors (within a process) and file
> descriptions (within the kernel) the problem has been solved by not
> having any additional memory in the client. A file descriptor is simply
> an integer that does not need to be deallocated. Would that be an option
> for PCSC-Lite?

pcscd is not aware that the client process has forked.
I am not sure to know what to do with PC/SC handles in a forked
process. It is the responsibility of the PC/SC application to not do
unspecified things.

Even a file descriptor is not a solution:
- A program opens a file then fork.
- Father and son can now write to the same file.
Strange things will happen if father and son do not work collaboratively.

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel