Menu
▾
▴
opensc-devel
|
From: David W. <dw...@in...> - 2015-04-30 22:10:31
Attachments:
smime.p7s
|
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
|
|
From: Ludovic R. <lud...@gm...> - 2015-04-30 22:50:25
|
2015-05-01 0:10 GMT+02:00 David Woodhouse <dw...@in...>: > 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 |
|
From: David W. <dw...@in...> - 2015-05-01 12:47:31
Attachments:
smime.p7s
|
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 |
|
From: David W. <dw...@in...> - 2015-05-01 13:00:40
Attachments:
smime.p7s
|
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 |
|
From: Ludovic R. <lud...@gm...> - 2015-07-28 13:26:36
|
2015-07-06 9:27 GMT+02:00 Ludovic Rousseau <lud...@gm...>: > 2015-07-06 2:07 GMT+02:00 Frank Morgner <mo...@in...>: >> 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 |
|
From: Frank M. <mo...@in...> - 2015-07-28 15:20:59
|
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 |
|
From: Ludovic R. <lud...@gm...> - 2015-07-28 16:03:00
|
2015-07-28 17:20 GMT+02:00 Frank Morgner <mo...@in...>: > 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 |
|
From: Ludovic R. <lud...@gm...> - 2015-05-01 16:58:57
|
2015-05-01 15:00 GMT+02:00 David Woodhouse <dw...@in...>: > 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 |
|
From: David W. <dw...@in...> - 2015-05-01 17:54:40
Attachments:
smime.p7s
|
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...@li.../msg00126.html |
|
From: David W. <dw...@in...> - 2015-05-01 23:51:47
Attachments:
smime.p7s
|
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. |
|
From: David W. <dw...@in...> - 2015-05-05 22:15:18
|
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
|
|
From: David W. <dw...@in...> - 2015-05-05 23:38:00
Attachments:
smime.p7s
|
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
Dav...@in... Intel Corporation
|
|
From: Nikos M. <n.m...@gm...> - 2015-07-03 08:10:59
|
On Wed, May 6, 2015 at 1:37 AM, David Woodhouse <dw...@in...> 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 |
|
From: Frank M. <mo...@in...> - 2015-07-06 00:10:51
|
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 <dw...@in...> 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 > Ope...@li... > 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 |
|
From: Ludovic R. <lud...@gm...> - 2015-07-06 07:33:15
|
2015-07-06 2:07 GMT+02:00 Frank Morgner <mo...@in...>: > 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 |
|
From: Nikos M. <n.m...@gm...> - 2015-07-08 08:58:40
|
On Mon, Jul 6, 2015 at 2:07 AM, Frank Morgner <mo...@in...> 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 |
|
From: Nikos M. <n.m...@gm...> - 2015-07-14 08:50:42
|
On Wed, Jul 8, 2015 at 10:58 AM, Nikos Mavrogiannopoulos <n.m...@gm...> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X